Developer productivity: what's all the fuss about?

The controversy about developer productivity

There’s been a lot of controversy recently about developer productivity. Some very big consultancies claimed you could and should measure it, while some software product development legends are of a different opinion. The legends are making fun of the consultancies, which are in turn accusing the legends of wanting to dodge accountability for their work.

So who’s right? Who’s wrong? And why? To answer that we’ll have to think a bit deeper.

A framework to think about developer productivity

In order to reason about developer productivity, we should first ask ourselves a few questions.

1. What is developer productivity? What’s its operational definition?
2. Is the productivity of a software developer intrinsic to the person? Or does it depend mostly on other factors?
3. Assuming you could measure the productivity of a software product developer, would this be useful? To who? How?

As always, we start with why.

Imagine you could measure it

Let’s assume you could come up with an accurate productivity score for a developer, on a comforting 0-100 scale. Now, what would you do with this information? Well, it really depends on what your role within the company is.

• If you’re a developer, and somehow knew this score, you could use it as an indicator, to experiment with different things and see what improves it.
• As a manager, you could use this score to understand the consequences of your actions, and determine who needs coaching and attention.
• As a CTO or head of department, you could keep an eye on the average score across the teams, to get feedback on your hiring policies and training efforts.

There’s nothing intrinsically wrong with metrics, but they can easily be abused.

• As a developer, you could use your higher score to feel entitled to special treatment. To expect that your opinion carried more weight, compared to the ideas of others with a lower score.
• If you’re a manager, you could use this score blindly to promote and fire, without looking into why it might differ across people, and without asking yourself whether the person might enjoy or even do well in the new role.
• As a CTO, you could use this score to second guess your direct reports about their own employees’ performance. Or you could assign a target average score as a goal to a manager for their area or team.

Is the productivity of a developer an intrinsic trait?

Let’s assume you accurately measure developer productivity on a 0-100 scale. Now, what would this depend on? Some people immediately associate the productivity of an employee to the merits or defects of that employee. Like if it was an intrinsic trait, something they come with.

But does productivity really belong to the employee? Or is it largely influenced by the environment: by the team, the ways of working, the salary and benefits, the technologies, the state of the codebase, the processes, the manager, and the company?

It should hopefully be obvious that these factors largely influence the productivity of a developer. So if the same person changes team, company, processes, manager, or ways of working, their productivity will also likely change, sometimes dramatically.

Developer productivity: what does it even mean?

Why are we even talking about individual developer productivity anyway? After all software product development it’s collaborative knowledge work.

First of all, developers are service providers and knowledge workers. They do not produce anything. Their effectiveness is never measurable as stuff over time. Sounds crazy? Are you thinking that, as a developer myself, I’m simply trying to avoid accountability?

Software developers are not the only kind of knowledge workers, so this shouldn’t feel like a new concept. What about lawyers, judges, scientists, city planners, advisors, doctors, teachers, and psychologists? How do you define or measure their productivity?

About scientists, would you go with number of publications a year? Number of whiteboards filled? How about judges? How quickly they judge somebody?

There’s this idea that each employee produces an amount of stuff over a unit of time, that stuff adds up to outcomes and impact, and that you can thus infer how much an individual contributes to the baseline based on how much stuff they produce over time. Well, in software product development this is ridiculous and absurd.

Also, software development is a collaborative job. In a collaborative activity, the determining factor for performance is how people interact, rather than how they act individually.

Think about a team of mechanics that services a Formula 1 car at a pit stop: their alignment and coordination trumps how well they perform in isolation. A well-coordinated team of less skilled mechanics would easily be more effective than the other way around. What about a football team? Or an army squad? Well, you should think about software product developers the same way.

And you know what else is true about every collaborative activity? That effectiveness is improved by teaming together people with different strengths. Teams made of specialists that excel at different things routinely outperform homogeneous teams of all-rounders. So you cannot even compare the performance of people, because everybody is different. There’s not merely 1 dimension to this problem, but many. Even within the same role and area of strength, the same person can work out wildly differently across 2 different teams, because of the strength of the interactions with the other team members.

What should we do about performance then?

This controversy is the result of a different world view. On one side you have Theory X people, with their internal competition model, claiming you cannot manage what you cannot measure. On the opposite side, you have Theory Y people, talking about teams, systems, and culture.

For managers who subscribe to Theory X, the only explanation for any undesired condition is that some of their employees must be incompetent or a slacker. It’s always somebody else. They see their job as identifying, removing, and replacing people. “If each of the 5 team members produces 3, I have a productivity of 15, so if I fired a 3 and hired a 4 I’d bring it to 16 and improve productivity. These damn 3s are holding me down!”

Theory Y isn’t that comforting.

As a Theory Y manager, the only person you can blame for any undesired condition with your team is yourself. “They’re not giving it all, I failed to motivate them”. “They’re not competent, I failed at both hiring and training”. “We got a lot of bugs and rework, I failed at structuring effective processes and at giving the right incentives”.

Theory Y puts performance issues squarely in the management’s lap. Like a professional sports coach, you might occasionally replace somebody, but your main focus should be directed at improving performance, rather than obsessing over measurements. Even if people decide to measure something, the metrics should be indicators, never targets. What matters the most is continuous improvement, fostered by vigorous training, to ensure that you work effectively together.

Unfortunately subscribing to Theory Y is very hard for a manager, because it shifts the accountability Theory X people love talking about from the employees to themselves. And if your job is about improving the effectiveness of your team, rather than measuring, blaming, and firing, then it follows that, in order to do your job, you should know the work intimately.

And these 2 points, ladies and gentlemen, are at the core of this controversy, which has nothing to do with developer productivity, and everything to do with Theory X and Theory Y. And that’s why those “managers” that know nothing about the work of the people they’re supposed to manage cling so much to measurements, scores, and KPIs: because what else do they have? It’d become evident that they’re good for nothing, should Theory Y management practices ever be introduced in their companies.