My last post touched on developer productivity, and while we’re in that space we really should address the elephant in the room. It’s easy to take a micro economic view of productivity and pick away at individual issues, like I did in the previous post. The hope is that as you eliminate each problem the sum of your efforts will build up and eventually you’ll double or triple the productivity of your team.

After all that hard work, you might be tempted to measure productivity, and this is where you might miss the elephant. The elephant I’m talking about is that it’s normal to see huge variation in individual developer productivity.

Let me say that again. It’s OK to have one developer three, five or even ten time as productive as another.

Paul Graham introduces this idea in his Great Hackers essay which is where I first came across it. Sure before then I realised that different devs have different levels of productivity, but Paul introduced the idea that orders of magnitude of difference is not only possible, but it’s usual.

The next question that springs to mind is of course is that OK? Paul talks about individual productivity, but what’s the impact on the team of this imbalance. Is it healthy for twenty percent of the team to be producing eighty percent of the output.

The first situation you might compare this to is your archetypal gang of council workers. Six guys leaning on shovels, and one guy actually digging the ditch. But to continue the analogy, the situation you really have is more like a mechanised freeway construction crew. Different workers use different tools and contribute different things, and no one metric can properly measure the scope of an individual’s contribution.

Imagine if the productivity of each member of the aforementioned construction crew was measured using e.g. volume of dirt moved. The front end loader and tipper operators would leap to the top. The grader and roller operators who more than anyone else will define the quality of the road move mere fractions of dirt.

As much as it might be tempting to try to build teams of only high performing individuals. I suspect that such a team might well implode. I’m not suggesting that you should have laggards. But having solid performers and smart but inexperienced juniors is healthy. The best work I have seen from the senior devs was when there was a young up and coming junior snapping at their heels.

And don’t discount your good solid middle of the range developers. When you have an arduous and potentially dull merge to do that must be right they are your go-to guys. The senors will probably rankle at doing such a task and ironically do a worse job. These developers are the support network that allow the high performers the freedom to pick and choose the most challenging and engaging tasks.

So choose your metrics carefully. Counting lines of code might be OK for comparing teams over time, or maybe trying to identify external issues that might be affecting a team’s productivity. But it’s not much good for individuals.

And if you mold your team around a single metric, over time you’re likely to loose the diversity that makes your team an interesting place to work. Which will drive your high performers away faster than you can say ““performance review””.