Everything Wrong With Developer Productivity Metrics

Adam Berry, Staff Engineer at Netflix

Adam has worked on developer tools and infrastructure throughout his career, from Eclipse plugins to service and infrastructure work; he now focuses on developer platforms as products to empower engineers and make teams and organizations drastically more effective.

The Origins of Productivity Metrics

We can trace it back about ten years to the Accelerate book and the rise of DORA metrics. That was the origin point when people realized there are things we can measure, and yes, they correlate with teams delivering value.

The DORA Four were meant as feedback mechanisms for teams to improve, not as a way to compare performance across an entire org. Somewhere along the way, we lost that thread and started chasing “productivity metrics” instead.

Martin Fowler said it best: you can’t measure individual developer productivity. That’s a fool’s errand. And even the official DORA site emphasizes these aren’t productivity metrics, they’re software delivery performance metrics.

Can You Measure Developer Productivity?

Strictly speaking, no. Productivity has an economic definition: value produced over cost of inputs. Apply that to an individual developer, and it falls apart quickly.

What we usually call “productivity” ends up being a mashup of efficiency, effectiveness, and even hustle. And metrics often oversimplify all of that.

That obsession with measurement also accelerated during COVID, when managers, suddenly remote and insecure about visibility, wanted numbers to validate how their teams were doing.

At the core  the questions are simple:

As an organization, can we ship as effectively as we’d like?

Is life good for individual developers here?

Those are the right questions. But answering them with metrics alone is nearly impossible.

Metrics, Trust, and the Manager’s Job

It often comes down to trust. In high-trust orgs, leaders feel confident telling the story of how their teams are doing. In low-trust orgs, leaders feel pressure to “justify” everything with numbers. That’s when metrics get weaponized.

Frontline managers are especially tempted to look at individual-level metrics, like lines of code written, and misinterpret them. But we know that’s nonsense. A senior engineer’s output may be design docs, coaching, or solving complex systemic issues. Measuring just “amount of work done” is reductive, like Bill Gates’ old joke about measuring airplanes by weight.

At the end of the day, interpreting impact is a manager’s job. If it were easy, anyone could do it. Data should support the story, but never replace it.

The Metrics Industrial Complex

There’s definitely an industry now. Tools that plug into your repos and issue trackers and spit out dashboards of 40+ metrics. Some of these are useful. Others are actively harmful by design.

The problem is, code is a lossy representation of the real work. Writing code is often less than half of what engineers actually do. Problem solving, exploring tradeoffs, and system design aren’t captured in a commit log.

Folks like Kent Beck and Rich Hickey have even argued that the most valuable part of development is the thinking, not the typing. And you can’t really capture that in a metric.

Where Metrics Are Useful

I see them as feedback mechanisms, not productivity measures. Metrics help uncover inefficiencies in delivery systems and processes.

Take build times. They matter because they affect developer feedback loops. But often, build speed isn’t the real bottleneck; it just feels like it. The real work is mapping your system from “idea to shipped” and identifying actual constraints. That’s where DORA metrics are still a great starting point.

Metrics are also useful as targets plus guardrails. For example, if you have a quality issue, maybe you want to increase test coverage. But you need guardrails so build times don’t spiral or tests don’t become flaky. Used this way, metrics guide improvement without backfiring.

Designing Metrics From Scratch

Like with any engineering problem, one should start with requirements gathering. Ask: why are we measuring this? What problem are we trying to solve?

Often the answers are things like:

• “We can’t ship quickly enough.”
  
  
• “Deploys keep failing and causing long incidents.”
  
  
• “Our products are too slow.”
  
  

From there, you can figure out whether DORA metrics or some custom set are the right fit. The key is to connect the measurement back to an actual pain point the business or developers are feeling.

And stakeholders matter. You need input from developers (what’s not working for them), from management (alignment and resourcing), and from the team itself (so they buy into solving the problem, not just hitting an arbitrary number).

Guardrails, Lifespan, and Goodhart’s Law

First, never rely on a single metric. Goodhart’s Law tells us that when a measure becomes a target, it ceases to be a good measure. That’s why DORA’s four metrics work well—they balance each other out.

Second, recognize that metrics have a lifespan. You might use test coverage as a feedback mechanism while improving quality, then “graduate” it to background monitoring once the team stabilizes. Not every metric deserves permanent prominence.

And finally, keep dashboards lean. If you’re staring at 40 metrics, you’re not really learning anything. Focus on what matters for the current improvement effort.

Why Measure at All?

Two reasons:

1. To create more value (faster, cheaper, better).
   
   
2. To manage risk when it becomes unacceptable.
   
   

That’s it. Everything else should tie back to those. And because developers are one of the biggest investments a company makes, improving their ability to execute is directly tied to business value.

At the end of the day, metrics should help teams improve their experience and delivery flow, not serve as judgment on individual productivity.