Why We Need to Stop Measuring (Developer) Productivity — Part 2

This is part two of my article on measuring developer productivity. In part one, we discussed the dangers of measuring productivity in general and why the need for productivity metrics for management and leadership is based on flawed assumptions.

While management based on productivity metrics is pointless and potentially harmful, there is still some value in metrics commonly labeled “developer productivity metrics”. That is if teams measure and use those metrics, not management.

You cannot measure developer productivity. Nor should you.

As we have seen, measuring productivity might be wrong, even in areas where it seems easy. What is usually measured is the short-term productivity ((sales made in a month x average deal size) / # of sales representatives)

This metric does not tell us how long the client will stay with the company and if that annual recurring revenue (ARR) will be recurring next year or in five years.

What does that mean for software engineering? Martin Fowler wrote about this over 20 (!) years ago, and his article is still valid today:

Productivity, of course, is something you determine by looking at the input of an activity and its output. So to measure software productivity you have to measure the output of software development - the reason we can't measure productivity is because we can't measure output.

The output in terms of business value is hard to measure. We might feel tempted to estimate that, but it replaces uncertainty with wrong certainty, which is worse. To further complicate it, there usually is a delay between the delivery of a feature and the business value it creates. We do not know how often a product is sold or how often the feature will lead to new business opportunities when we deliver it. We might also not know how much maintaining that feature or product will cost us in the future.

Thus, we cannot measure the real thing, engineering productivity, as the business wants to measure it. We can measure all kinds of proxies and use simplified models of reality for enhanced guessing. This might give us the illusion of knowing.

But do we really know?

👉 Read the full article here.

See you in 4 weeks! 👋

As this article comes out, I am already traveling to a beautiful small village in Tuscany, Italy 🇮🇹, for a two-week co-working retreat. I will use that time to recharge, reconnect, read, and relax. 😉 — I won’t publish newsletters or articles during this little late-summer break.

You can expect the next article on the 20th of October on my substack.

In the meantime, let me know if you have any topics on your mind that you would like me to write about. 💬

Let’s work together! 🤝

If you think your team could become more productive or are seeking improvement opportunities, I am here to help. Together, we can identify bottlenecks and pain points for your engineering teams and work on the factors that actually matter. Book a free 30-minute discovery call to discuss how that can look in your context.