Does your company measure developer productivity? What does it really measure?

Activity is not productivity

The first misunderstanding is treating the amount of work done as if it were value generated. A team can close many tickets, write a lot of code and complete many story points, and still not move a single needle that matters to the business or the user. Activity is easy to count. Value is hard to measure. And because of that convenience, we tend to measure what is easy and call it productivity.

The underlying problem is that software development work is not an assembly line where more units mean more output. It is knowledge work, where the best contribution is often writing less code, removing complexity, or spending a day thinking before typing. Measuring lines of code produced in that context is like measuring the quality of a book by its word count.

Goodhart's Law and why metrics get corrupted

There is a principle that everyone who measures teams should have engraved in their mind. The anthropologist Marilyn Strathern put it memorably in 1997: when a measure becomes a target, it ceases to be a good measure. This is the well-known Goodhart's Law. As soon as a figure is used to evaluate and reward, people start optimizing the figure instead of what the figure was meant to represent.

The examples in software development are almost comical if they were not so costly. If you measure by lines of code, unnecessarily long code will appear. If you measure by closed tickets, tickets will be chopped into tiny pieces and closed quickly. If you measure by story points, estimates will inflate until the team "performs" more without doing more. In every case, the metric goes up and the real value stagnates or gets worse. Worse still, measuring individuals by their individual output erodes collaboration, because helping a colleague stops being profitable on your personal account.

W. Edwards Deming, one of the fathers of quality management, warned decades ago that managing an organization solely by visible figures is one of the most costly mistakes, because the most important figures are often unknown or impossible to know. His critique of imposed numerical targets remains valid in every dashboard that confuses what is measurable with what is important.

What serious frameworks propose

The good news is that there is rigorous thinking on this, and it is worth building on it rather than improvising homemade metrics.

DORA's research, presented by Nicole Forsgren, Jez Humble and Gene Kim in Accelerate (2018), identified a set of delivery metrics that do correlate with organizational performance. They focus on flow and stability: how often you deploy, how long it takes from writing a change to it reaching production, how often a change causes a failure, and how long it takes to recover. What is relevant about these metrics is that they measure capabilities of the work system, not the output of individuals, and that they balance speed with stability, so you cannot cheat by accelerating at the cost of breaking things.

More recently, the SPACE framework, developed by Forsgren and others in 2021, took an important step by insisting that developer productivity is multidimensional and cannot be captured with a single figure. It proposes looking at satisfaction and well-being of people, system performance, activity, communication and collaboration, and flow efficiency all at once. Its central message is that any isolated metric deceives, and that measuring only activity, the easiest dimension, is precisely the worst choice if taken on its own.

Mik Kersten, in Project to Product (2018), adds another piece by shifting the focus from output to the delivery of value through the entire flow, measuring how much value crosses the system and how much time is lost to waiting and blockages. The question stops being "how much does each person produce?" and becomes "how smoothly does the organization turn an idea into delivered value?".

What we measure for, the question almost nobody asks

Before discussing which metric is better, it is worth pausing on a prior question that many organizations skip: what do we want to measure for?

Measuring to help a team understand and improve its own work is not the same as measuring to compare people and decide bonuses or layoffs. The same data changes its nature entirely depending on its purpose. Used by the team itself as a mirror for improvement, a flow metric can be extremely valuable. Used by management to rank individuals, that same metric is immediately corrupted, because it activates Goodhart's Law and destroys trust.

The practical distinction is simple to state and hard to sustain. Metrics should serve to learn, not to judge people. As soon as they become a tool for individual evaluation, they stop informing and start distorting. Mature leadership uses data to ask better questions, not to assign blame.

The AI context: the temptation to measure what AI inflates

The arrival of artificial intelligence has added a new and urgent dimension to this old debate, because it has made it trivial to inflate precisely the activity metrics that were already bad.

With AI assistants, generating large amounts of code is easier than ever. If an organization measures by lines produced or by commit volume, AI will push those numbers up without that meaning more value. On the contrary, it may mean more code to maintain, more complexity and more future debt. Measuring productivity by output in the age of AI is an amplified mistake, because the machine produces output in torrents and value still depends on the human judgement that decides what deserves to exist.

Research is beginning to temper the enthusiasm. Recent DORA reports observe that adopting AI without the right practices around it does not guarantee improvements in delivery performance, and can strain stability. The lesson connects with everything above: if we measure what is easy, AI will give us more of what is easy. The question that really matters does not change with AI, it just becomes more pressing. It is not how much code we produce, but how much value we deliver and with what health of the team and the system we do it.

Measuring developer productivity is not impossible, but it requires resisting the comfort of counting what is easy and calling it value. Activity figures are tempting because they are at hand and seem objective, and they are dangerous for the same reason: their appearance of objectivity hides the fact that they measure what does not matter and distort what they touch.

Perhaps the best test for any metric we are using is to ask ourselves honestly what behavior it provokes in the team. If it pushes us to produce more noise and less value, to compete instead of collaborate, to dress up instead of improve, then that metric is working against us no matter how good it sounds in a report. Measuring well is not measuring a lot, but measuring what, once observed, makes the team work better.

And in your company? Is developer productivity measured? And if you stop to look at it calmly, what does that thing you measure actually measure?

Bibliography

• Deming, W. E. (2000). Out of the Crisis. MIT Press.
• Doerr, J. (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
• Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of Developer Productivity. ACM Queue, 19(1).
• Google Cloud / DORA (2024). Accelerate State of DevOps Report 2024.
• Kersten, M. (2018). Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press.
• Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
• Strathern, M. (1997). 'Improving ratings': audit in the British University system. European Review, 5(3), 305-321.