I am a lead programmer on a small development team. Normally, I give my other subordinates less critical things to program and my 'second in command' has brought it to my attention that they feel alienated from development as a result. It's not that I want to alienate them, but I feel that they are not on the same level as expertise and skill evidenced by their passive nature when I assign them tasks and from the unreliability of their code. I don't want to seem condescending but some of their mistakes/performance issues in their code seem easily avoidable and fixable to me purely through experience.

One of the other reasons for concern of team relations is that my 'second in command' is a 'control freak', and is always attempting to gain much higher authority positions than he is able to effectively handle, and can be very arrogant at times. A lot of times he will try to non-constructively pick at every thing he can and make recommendations on things he has little to no understanding in (He once told the engineering team that shorter wires would have a 'faster' connection when electronics move at the speed of light). I know that he desperately wants to show his superiority over all and I am suspicious that he is promising the younger subordinates that he would allow them to take critical processes just so he can get a good rep with them and eventually try to contest my position.

How can keep good relations with my team-mates? Is giving them responsibilities to critical processes and potentially affecting development output the answer? I usually try to mentor them in down time and more relaxed times b/c I want them to be able to eventually support me with critical processes in the future, but they are just not ready to output the standard of quality I need.

  • 14
    "I don't want to seem condescending but some of their mistakes/performance issues in their code seem easily avoidable and fixable to me purely through experience." If you give them neither training nor experience, when and how are they going to learn? – Vietnhi Phuvan Dec 21 '14 at 21:32
  • If your position is elected by your staff, then you have something to worry about. If your position is selected by your superiors based on skills and experience, you don't. – HorusKol Dec 21 '14 at 22:41
  • 5
    @kiro Your question lacks focus, please consider editing it. There seem to be 2 questions actually, one about the relationship with your second-in-command, and one about your relation with the rest of the team. As for the first relation, you're losing yourself in speculation ("I'm suspicious..."), and you can't expect anyone to answer on suspicions; facts would be better. – user8036 Dec 21 '14 at 22:46
  • This is one of the key problems with a "technical lead" position. You don't get the time-budget you need to have the appropriate one-on-one time to manage them effectively, but the managers above simply assume it's taken care of because they have a direct lead. In my experience, the technical lead model creates more problems than it solves by not having actual managers over these people. – corsiKa Dec 22 '14 at 0:17
  • 2
    The question reeks of this. – Bmo Dec 22 '14 at 14:08

Well, as a video engineer, I can assure you that signals do not travel on wire at the speed of light. Propagation delay is a spec any signal cable manufacturer provides. Aside from phase-matching high-frequency signals in analog switching environments (Something we haven't had to do in video in over a decade since we moved to digital signal processing), it doesn't come up often. I'd be very surprised if, as a software developer, you were in an environment where it's critical.

Also, I'm surprised that you're unaware of this issue, if you're having the usual one-on-one conversations with your team members that you should be having.

Being a "lead programmer" is difficult, though, as you have authority over the tasks, but not necessarily the staff, depending on your organization, so you're in a bit of a jam.

First, you say their quality isn't up to snuff? Can you measure that objectively? Do you have code analysis tools and performance testing tools that can show them the difference? As long as you can give them objective information, and keep the emotional component out of the conversation, it should be a fairly straightforward task to develop their skills.

Second, do you track it? Nothing speaks to programmers more than measurable results. Do you show them their code quality metrics over time? Can you give them more critical/rewarding work as their quality improves? Instilling senses of accomplishment and subsequent reward should be fairly straightforward if you do.

Finally, do you have the authority to demote your "second in command?" Have you talked with your manager about this? If he is being truly disruptive, then you have an issue that requires his attention.

| improve this answer | |
  • 1
    For that matter, the speed of light is finite (very fast, but finite): even if they did travel at the speed of light, that imposes a delay. With, e.g., satellite communication, the speed-of-light delay can be noticeable (you're around a quarter-second just going from the ground to geostationary orbit altitude and back). – cpast Dec 22 '14 at 4:57
  • Inside a high-end processor, speed of light is very noticeable. At 3GHz clock speed, speed of light is just 10cm. And as was said, electrical signals in a wire don't move at speed of light. – gnasher729 Dec 22 '14 at 14:13
  • 2
    +1 just for calling "BS" on the propagation delay alone. – Joel Etherton Dec 22 '14 at 14:50
  • @cpast - You're absolutely correct. Our "rule of thumb" is 1/3 sec, as you have to put frame sync's inline on the downlink. Of course, now that everything's got some version of compression on it, the satellite delay is the least of the issue. :) – Wesley Long Dec 22 '14 at 15:44

Yours is a common behavior for technical 'leads'.

Here's the deal. Yes someone with less experience will run into issues and problems that someone who has more experience will avoid. Why is this? Well because the person who has more experience has more experience with these issues and problems. So how can the less experienced person learn how to handle those issues and problems? By experiencing them.

Frankly, given your description of your team, I'm not surprised that the coders under you are lackadaisical when it comes to doing projects. You take the interesting and hard projects for yourself and you don't sound like you are above 'swooping in' on anything they're working on to 'fix it for them'. You don't trust them and from your description here it sounds like you don't respect them either. Why would they try hard in that circumstance? You aren't treating them like a team of peers who have less experience than you, you're treating them like a band of minions who should do your menial and boring tasks.

The goal of a lead developer on a team of developers should be multi-fold.

1) You should drive the overall vision for the code developed by the team including both architecture and general, high level implementation.

2) You should be available for mentorship with the goal of raising up the level of expertise of every member on your team. Being the 'lead' isn't about being a lead guitarist rockstar in a band, it's about being the coach of the team. You are not successful if the rest of your team is unsuccessful. As a lead, the description of the current state of your team shows that you are failing in that role.

3) Be open and nonjudgmental. At some point in your career you said some pretty stupid stuff. We all did. "Shorter cables improve performance" isn't all that stupid on the richter scale of stupidity. In fact, it is a legitimate discussion. You, who claims he is arrogant, use this as an excuse here of all places(where you are asking a question unrelated to it) to show off your own knowledge and poopoo the discussion. How did you handle it there? How will anyone on your team learn if the result of saying something is mocking derision? Why would anyone risk putting forward their own ideas or opinions in that environment? Frankly, at this point, I'm a bit surprised your team hasn't experienced a mass exodus to another team or another company.

In short your goal as the lead developer on a project should be to make your team and thus the project as awesome as possible. But right now you're hoarding the challenges in the guise of concern.

Let's be fair. There's no good training out there for being a lead. Also nothing you are doing(except being pretty arrogant yourself) is unusual or bad for a non-lead developer. Being a lead developer is a balancing act between being a developer and being a leader or mentor and programming as a field is pretty terrible at teaching folks how to be mentors in a healthy environment.

Your 'second in command' is desperately looking for ways to be relevant in the development process. Have you considered that he is nit-picking on particular topics because he feels that is the only place he can input feedback? You call him a control freak but, again, look at your actions and behaviors. You are unwilling to let go of anything you deem 'critical' OR let someone learn something from another team(why do you care if he asks what turns out to be a stupid question of another team if he learns something from it?) It's often said that to move up in a company you should find someone in the role you want and learn to do what they do. Your 'second in command' is emulating your behavior. Of course he wants to move up into your role eventually. That's the point right? That eventually he will learn so much from you that he can go be a technical lead on a team(whether this one or another one.) Why is that scary to you? Technical lead positions aren't like the Game of Thrones. There's more than enough room for every developer to be an experienced, technically proficient leader in the field without another having to die so their 'spot' opens up.

The TL;DR of this whole thing is that unless you give them a chance to both work on critical tasks AND learn from the mistakes that come up during those critical tasks your team will never be 'ready' for those critical tasks. If you are coding all of the core components of the project, you're being a rockstar and not a coach. I understand the desire to deliver the best, most perfect code. I understand the neurotic desire to have a handle on the entire project so that things come out exactly to your vision. I've lived both those things, almost all developers have. But those are things you have to start letting go of in order to effectively lead and develop your team. Some action items:

a) Are you having One-on-ones with a manager or supervisor? Personal development should not fall by the wayside just because you're more senior.

b) Have you taken part of management training? There are starting to be some excellent training seminars out there specifically for the developer turned leader.

c) Apologize to your team. Seriously. Whether you actually say it to them or whether you do it internally and apply changes. Your team is faltering and weak because you need to lead them differently. Start diivying up code. If you are the only thing driving core development on a project you are drastically screwing up your teams' bus quotient(the number of people whose, if they were hit by a bus, loss or departure would disrupt the company.) It's a sad truth but as you start being a lead, you should be coding less. Your time, especially with your team in disarray, should be devoted to getting your team up and running effectively.

d) Your team should be doing the following:

  • Regular code reviews where you should help guide the catching and resolution of issues as well as drive the implementation and design patterns of your choice.

  • Regular short meetings about their statuses.

  • Scheduled one-on-one time with a mentor developer(whether you or another 'more experienced developer'.

If any of these things aren't happening, they should be a priority.

| improve this answer | |

I think you have two possible questions here - one is about your "second-in-command", and I think there are plenty of answers out there dealing with this.

The other is the rest of your team, and how you are managing them.

You should be prepared to give them "critical" work - and you should be prepared to spend your time helping them to get that "critical" task up to your standard. If you never give them the work, they won't ever be able to meet your standard. There's a few ways to do this:

  1. Be very clear on what your standards are
  2. Be very clear on you specification for specific tasks/outcomes
  3. Make sure they know that individual tasks/outcomes need to fit in with a big project vision
  4. Let them loose for a bit - set a time limit that they know about (maybe allow a bit longer than the time you think you would need)
  5. Sit with them and review - ask them questions about why they did something the way they did, what they think it will mean
  6. Don't confuse a different solution to yours as being the wrong solution
| improve this answer | |

It is possible to make them part of the critical development without them actually writing the production code. You can work them into tasks like this in an incremental way.

  1. Have a team white board discussion.
  2. Give small tasks to each team member and allow them to evaluate each other in a code review.
  3. Offer feedback to those whose code needs to be improved and have them improve it.
  4. Finally, use any code that you think is production quality.

Unfortunately, some of their work will not get into production, but now they have some examples of what they need to do in order to improve their work. They can choose to work harder if necessary or pay more attention to their code or they may discover they're just not cut out of this type of work. Not all juniors truly become senior devs and shouldn't expect to be over a certain period of time. They're programmers and not bottles of wine.

| improve this answer | |

The inexperienced employees want to become experienced employees. If they can't do that, no wonder that they become alienated. It is in their best interest, but also in your best interest, to make them experienced.

A simple approach is to give them a task that needs a bit more experience, let them think about how to do it for a while, then discuss things and help them to improve their approach. Have a bit of code written, don't expect perfect results, then discuss how it can be improved. Repeat this for a while, and you will get experienced employees.

If code that gets delivered is buggy, the usual approach is unit testing. Which is very useful for anyone.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged .