Measuring the System, Not the Person

Every measurement programme in this field eventually gets asked to produce per-developer numbers. The request is reasonable-sounding and the answer should be no.

Why individual metrics fail

They measure output, not value. Commits, lines changed, pull requests, story points — all countable, none correlated with whether the work mattered.

They are trivially gamed, and gaming them is rational once they carry consequences. Smaller commits, split pull requests, padded estimates.

They punish the wrong work. Reviewing code, mentoring, debugging someone else's problem, fixing a flaky test, writing documentation — all valuable, all invisible in output counts.

They punish difficulty. The person on the hardest problem produces the fewest commits.

They measure the system. A developer on a fast toolchain in a well-understood codebase produces more of everything than an equally capable one on a slow toolchain in a legacy system. The difference is the environment.

What they break

Collaboration. Helping someone else lowers your number and raises theirs.

Honest reporting. A flaky test, a slow build, a bad estimate — all become risky to mention.

The measurement itself. Once numbers carry consequences, the data degrades. This is not a hypothetical; it is the reliable outcome.

Trust in the whole programme, which is what makes the system measurement possible in the first place. Developers who believe the telemetry is aimed at them will resist the local build instrumentation that this field depends on.

The frameworks, read correctly

DORA metrics — deployment frequency, lead time for changes, change failure rate, time to restore — are team and system measures. Applying them to individuals is a misuse of the framework, and the people who developed it say so.

SPACE was written partly to argue that productivity is multidimensional and cannot be captured in one number, and explicitly warns against individual measurement.

Both are frequently cited while being used for the opposite of their stated purpose.

What to use instead

System measures, which are the subject of this whole site: build times, queue times, flake rates, feedback latency.

Team-level delivery measures, used to spot trends rather than to rank.

Surveys, which capture the experience that telemetry cannot — and which stop being honest the moment they are attributed.

Conversation. The question "what slowed you down this week" answered by five people produces more actionable information than any dashboard.

When someone asks anyway

They will, and usually for a legitimate reason: a manager who genuinely wants to know whether someone is struggling.

Answer the underlying question. That is a management question, and it is answered by working with the person, not by a chart.

Offer the system view. "I can show you where this team loses time, and it is a twelve-minute build" is frequently the real answer.

Say no to the ranking, clearly, and give the reason: it degrades the data the programme depends on and it does not measure what they want to know.

Write the position down before you are asked, because deciding it under pressure produces the wrong answer and the decision becomes precedent.

Writing the position down

The refusal is easier if it was decided before it was requested.

State what is collected and what it is used for.

State explicitly that it will not be used for individual assessment.

Name who decides if an exception is proposed.

Publish it to the people whose data it is.

Review it annually rather than when challenged.

The first request will come within a year, and a written position turns a negotiation into a reference.

Answering the underlying question

The request for individual numbers usually has a legitimate concern behind it, and it is answerable.

"Is someone struggling?" — that is a management observation, made by working with the person.

"Is this team slower?" — answerable with system measures, and the answer is usually the toolchain.

"Where is capacity going?" — answerable at team level.

"Who should I recognise?" — the metric would have told you the wrong answer anyway, since it undercounts review, mentoring and debugging.

Offer the answer to the real question rather than only refusing the stated one.