Developer productivity

Why activity is an incomplete measure

An engineer can have a very productive day without writing much code. They might identify the cause of an outage, remove an unnecessary dependency, or help another engineer avoid a difficult design mistake. Each contribution can matter more than a large implementation that never reaches a customer.

Activity measures are still useful. Commits, reviews, and completed tasks describe things that happened. The mistake is treating them as interchangeable units of value. Splitting one change into five pull requests increases the count without necessarily increasing the result.

The SPACE research frames productivity as multidimensional. It includes satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. The framework helps teams choose a set of measures instead of expecting one number to capture the whole job.

Match the measures to the work

A product team shipping a new workflow might care about whether customers can complete it successfully, whether releases remain stable, and how quickly feedback reaches the team. An internal tools team might measure how much waiting its improvements remove from other developers' days.

Start with the outcome you want to improve, then identify the constraints that could be preventing it. Useful supporting measures might include review waiting time, repeated build failures, rework, or the number of unresolved dependencies. Developer feedback helps explain which of these problems is expensive in practice.

The comparison period also matters. A week spent migrating infrastructure can look unproductive through a feature-delivery lens even when it prevents months of future maintenance work. Make the type of work visible before drawing conclusions.

An example with an AI coding assistant

Suppose an illustrative team starts using an assistant and opens more pull requests. That is evidence of increased activity. It is not yet evidence of increased productivity.

Look at what happens next. Are the changes useful and accepted? Does review take longer? Are more patches needed after release? Has time spent generating code simply moved into time spent checking it?

If the team delivers more useful functionality with similar quality and less total effort, the productivity case is stronger. If reviewers become overloaded and unfinished work piles up, the new tool may have accelerated one stage while slowing the workflow overall.

Avoid a universal target

There is no meaningful universal quota for commits, story points, or pull requests per developer. Teams differ in architecture, support responsibilities, product maturity, and task complexity. Even within one team, a specialist's contributions may look different from those of someone working on routine changes.

Use measurements to support a specific improvement and compare the team with its own relevant baseline. Include qualitative evidence and acknowledge uncertainty. A useful productivity discussion ends with a better understanding of the work, rather than a ranking that hides why the numbers differ.