“What improves developer productivity?” is the wrong question

Jason Yip
3 min readNov 27, 2022

I’ve noticed people sharing this Google paper “What Improves Developer Productivity at Google? Code Quality”.

I didn’t find it that interesting.

Product development productivity is not just the sum of the productivity of individual participants

The simplest model to explain this comes from the Theory of Constraints.

Let’s imagine a simple scenario with 3 participants (A, B, C). The work flows through person A to person B and finally to person C before it is completed. However, for whatever reason, it takes longer for B to complete their activity than A. This means that a bottleneck will appear at B.

Workflow with 3 people (A handing off to B handing off to C). Bottleneck appears at B.
Simple workflow scenario with a bottleneck at B

So, what can we do?

  1. Focus on improving productivity and utilization of bottleneck B;
  2. Limit incoming work from A to avoid overwhelming B AND make sure B is never having to wait for anything;
  3. Work on improving the capacity at B: A and C can pitch in and/or take over lower priority tasks, add more people at B, etc.
Improve productivity and utilisation at the bottleneck; limit incoming work to prevent overwhelming the bottleneck; pitch in to help at the bottleneck if you can; add more people at the bottleneck
Various ways to improve in response to a bottleneck

What doesn’t matter?

When there’s a bottleneck at B, any productivity improvements to A or C will have no impact on overall productivity. Overall productivity is constrained by the performance of B.

Workflow from A to B to C with a bottleneck at B. Improved productivity at A can’t be absorbed at the bottleneck. Improved productivity at C will be unutilised.
Improved productivity outside the bottleneck doesn’t help

Increased coding activity is a poor proxy for measuring productivity

Let’s imagine the overall product development system as a black box. What does it mean for that box to be “productive”?

Productivity is the rate of output per unit of input.

Roughly the input is the number of people involved and the output is how many valuable things come out, aka throughput.

Productivity is higher when there is more throughput for the same or fewer people involved OR the same throughput for fewer people involved.

Productivity is the rate of output per unit of input. For a product development system: Input is the number of people involved, Output is the rate of valuable things coming out.
Productivity is the rate of output per unit of input

Generally increased coding activity doesn’t mean higher throughput, especially given potential bottlenecks.

So, what’s worth measuring if you want to measure productivity?

  • Cost (aka the number of people involved) (INPUT)
  • Throughput (# of things delivered) (OUTPUT)
  • Quality (so you’re not fooled by increased throughput of things that don’t work) (OUTPUT)

I’d also suggest measuring lead time, which isn’t technically productivity, but is valuable to measure responsiveness.



Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl