Is the Most Productive Employee Really the Most Productive?

I’ve discussed this situation with several managers recently. The manager says, “I have a wonderful developer, who can code circles around everyone else. If he doesn’t like someone else’s code, he rewrites it over the weekend. If he sees a hole, he writes a ton of code over the weekend He starts work early and works late. But, I have a tiny little problem. I can’t keep people who might be just as good. I can keep people who are not as talented, but can’t retain people who are not quite as good. But that’s ok, isn’t it? After all, don’t I have the most productive employee?”

Let’s review what productive means for software. It means the most number of features per unit time per team. Personal productivity is meaningless. Keeping everyone busy is meaningless. But having one employee who is a bottleneck, or one employee who prevents a team from increasing their overall capacity (running tested features per unit time), that’s a problem.

One manager who had this problem has a bottleneck employee, one who prevents other people from doing their work, by interrupting others from finishing their work. (See Retrain Your Code Czar for an article I wrote about this a number of years ago.) Bottleneck employees are frustrating to the rest of the team and prevent everyone from accomplishing work–except the work they want to accomplish.

Another manager has the problem of one person bringing down the expertise of the entire group by being an indispensable employee. Indispensable employees prevent other people from learning because they take care of things for other people. Other smart people don’t want to work with the indispensable employee because they don’t get the challenge of solving the problem themselves.  Indispensable employees are quite dangerous to the longterm health and success of your group.

If you are faced with one really productive employee and some not-so-hot folks, reexamine your situation. Do you have a bottleneck or an indispensable employee? If so, fix the situation. They are not helping you.

17 Replies to “Is the Most Productive Employee Really the Most Productive?”

  1. This is what “Rands” refers to as a “Free Electron”, someone who just gets stuff done.

    This is also where non-technical management lose out. I’ve seen several teams which are in thrall to the local “genius”, who turns out just to have more attitude than the rest of the team and makes everything look difficult. From the outside, it’s hard to tell the difference between someone really good working on hard problems, and someone massively confident at the limits of their abilities. The former is worth working around, the latter should be reallocated as soon as possible.

    Finally, it’s worth asking why your developer feels the need to work all hours. Maybe they need the adrenalin kick, or maybe they’re right about the rest of the team–or both.

  2. A variation of this is “fire all ESSENTIAL employees.” People fail – that is the nature of us. The ESSENTIAL employee that you describe will fail one day and the entire organization will fail with him.

  3. The “rewriting other people’s code over a weekend” is a huge red flag here. It’s not about good, it’s about trust and respect, and this developer looks to be showing little of it. And shame on the manager for not seeing that. By labeling the cowboy a “wonderful developer”, the manager is complicit in the dysfunction. No wonder other developers are leaving. Who dares challenge the manager’s pet? It’s easier to move on.

    This is as much about the manager as it is about the employee.

  4. Hello,
    I agree with you,
    In addition, to focus the indispensable employee to share their knowledge and then invite them to continue growing in their expertise enables their individual and team growth.

  5. Pingback: INNORO BLOG » Blog Archive » Is the Most Productive Employee Really the Most Productive?
  6. You said –“It means the most number of features per unit time per team.”

    You meant – “It means the most number of tested and working features per unit time per team.”

  7. I sgree with Dave Smith’s comment above. The big red flag is the weekend (or overnight) re-write. This is not co-operative to the team. And the reason it continues is the fault of the manager, for mistaking the cowboy for a great developer.

    It’s fairly simple to have rules like, “no rewrites without team permission” and other ways to handle the cowboys. Good developers make their whole team they are in look good.

  8. It’s important to remember that the ‘genius’ coder who is so productive may be introducing many more errors to the code base than he does producing working and maintainable code. Ask yourself how much time does he or the team spend fixing code that he worked on? Is the code completed FAST AND working RELIABLY? Food for thought…

  9. Johanna,

    This post has been bouncing around in my brain the last 2 weeks, not sure what to do with it. But then I’m finishing up my latest blog, which looks at research into errors in aviation and hospitals and they found that errors tend to occur most often when the senior person is operating or flying and I’m thinking… maybe it’s all related?

    I can’t figure out how to get link backs working? But I linked back to here with the question of whether the same might be true in software development: http://www.thehackerchickblog.com/2009/05/plane-crashes-software-failures-and.html

  10. I believe that many people were on a project where were a few really productive developers – they did much more than others (really did – quality didn’t suffer). And it didn’t threaten overall performance – quite the opposite. These highly productive people may even have helped other developers to set higher internal goals. And total impact on performance was really positive – personal high productivity + increased productivity of other members.
    Team which consists of unproductive members is unlikely to be productive as a whole. It’s a smart move to create team from productive members (of course, don’t forget about team dynamics and interaction) and make it a productive team.
    It makes sense to analyze what consequences are in every specific case. And if you’ve discovered that a team member who seems very productive in fact is a bottleneck or negatively impacts overall performance – take immediate measures.

Leave a Reply