The numbers everyone repeats · 6.5

The ten times more productive worker

The ten times more productive worker. What is actually the case, and how it compares with what is repeated.

A practical software reference for this part of the discussion is Monitask's overview of employee tracking software.

The belief that some workers are ten times more productive than others is close to universal in software and has a specific origin: a study of twelve people published in 1968.

The study

Twelve programmers were given tasks under two conditions and their times recorded. Ratios between the fastest and slowest ran as high as twenty-eight to one on debugging time.

The sample was twelve. The group mixed experienced and inexperienced programmers, which alone would produce large ratios. The two conditions being compared were batch and time-sharing access, which was the actual subject of the paper. And the measure was time to complete one specific task.

What happened next

Later reanalysis of that study and of the subsequent literature found the variation real and considerably smaller than the headline ratio, and found that the headline had been inflated by the comparison of extremes in a small sample, by the experience mix, and by the choice of measure.

Comparing the best and worst of any twelve people at anything produces a large ratio. It is a property of extremes in small samples, not a finding about programmers.

What survives

That performance in complex cognitive work varies substantially between individuals. That is well supported and is not controversial.

The specific multiple does not survive, and neither does its use as a management principle, which is where the damage happens.

The inferences that do not follow

That such people can be identified in advance, which the hiring part of this site suggests is difficult. That the variation is a stable property of a person rather than of a person in a particular role, team and codebase. That paying one person ten times as much would be efficient. And that a team of the best would be ten times as productive, which ignores everything about coordination.

The measurement problem underneath

Individual productivity in software is not measurable, for the reasons the part on measurement sets out: output is not countable, contributions are not separable, and every available proxy is gameable.

A claim that one person is ten times another therefore rests on a comparison nobody can perform. It persists because everybody has encountered a colleague who seemed to work at a different speed, and the figure supplies a number for the impression.

What the impression is often picking up

Familiarity with the specific system. Knowing who to ask. Having written the code being modified. Freedom from interruption. Being given the tractable problems.

Each of those is contextual and each can be changed. Attributing the difference to the person makes it fixed, which is convenient for whoever allocated the conditions.

Why it matters

Because it licenses a set of practices: extreme selectivity in hiring justified by the multiple, large pay dispersion within teams, and tolerance of behaviour from people believed to be at the top of the distribution.

The last is the expensive one. A person whose measured contribution is high and whose effect on five colleagues is negative is a net loss that no individual metric will show.

What to do with the idea

Keep the part that is supported, which is that variation is real and worth attending to. Drop the number. And notice that the variation you observe is partly a fact about the environment you built.

The team-level version

Where variation can be measured with any confidence it is at team and organisation level, and it is large: comparable teams in comparable organisations differ substantially in throughput and quality.

Almost all of that difference is attributable to how the work is organised rather than to who is in the team, which is the opposite of the inference the ten times figure invites.

Where the figure does real damage

In hiring processes designed to avoid false positives at any cost, which reject large numbers of capable people to be certain of excluding the weak. The arithmetic only makes sense if the multiple is real and the identification is reliable, and neither holds.

What a good developer actually looks like

Where teams have been studied rather than individuals, the traits associated with high team output are unglamorous: clear interfaces between people, small changes, fast feedback, and low interruption. None of them is a property of an individual.

The related figure

The claim that a small share of developers write most of the useful code is derived the same way, from small samples with the same extreme-comparison problem, and travels with the same confidence.

For broader context, consult McKinsey talent research.