The Law of Diminishing Returns

The problem it solves

Adding more of something is the default response to a system that isn't producing enough, and for a while it works. A second person on a task roughly halves it, a second reviewer catches things the first missed, and a second server absorbs the load. The improvement is large enough that adding becomes the move a team reaches for without much discussion.

What tends to happen next is that the improvements get smaller while the total keeps rising. Output is still going up with each addition, so nothing looks wrong from the outside, and the number that would show the problem is the one almost nobody plots, which is what each extra unit bought compared with the one before it.

Past a certain point the total can fall. Adding people to a late project is the familiar case, and the reason it's familiar is that the total output curve turns over quietly, without anybody deciding it should.

The idea

Where one input grows and something else is held fixed, each extra unit of the growing input produces less than the last. That's the whole law, and the phrase worth holding on to is the second half, because the fixed thing is where the answer is.

Enlarge: The line keeps climbing. What each step buys is the part that's shrinking.

A curve rising steeply, then flattening, then turning gently downwards as a dashed line past its peak. The horizontal axis is how much you add and the vertical is what you get. Three equal steps are marked along the horizontal axis, and beneath it a strip of bars shows what each step added, each much smaller than the last, then one hanging below the line.

The line keeps climbing. What each step buys is the part that's shrinking.Close

The line keeps climbing. What each step buys is the part that's shrinking.

In the original agricultural version the fixed factor is land, so more labour on the same field eventually adds very little. In a team it's rarely so tidy, and the fixed factor is usually coordination capacity, review throughput, the one environment everything has to pass through, or the single person who understands how the system fits together. Naming which of those it is turns an observation into a decision, because all four can be relieved and each takes a different kind of effort.

The economics transfers well, with a caveat that matters. An economist can hold the other inputs constant by assumption and a manager can't, so a team's falling throughput is a mixture of diminishing returns, staff turnover, a harder problem and whatever else moved that quarter. What survives the transfer is the question rather than the measurement.

How to use it

Plot the increments rather than the total, even roughly. Two columns are enough, one for how much of the input there is and one for what the most recent addition bought, and the shape is usually obvious after four or five rows.

Name the fixed factor before doing anything about the curve. A team whose bottleneck is a shared review queue is not helped by better tooling, more headcount or a stricter process, and each of those will be proposed before anybody checks.

Then take one of the two honest moves. Relieve the constraint, which is expensive and permanent, or put the next unit of effort where the curve is still steep, which is usually somewhere nothing has been tried yet. The third move is adding anyway, and it happens most often, generally because the constraint has never been named out loud.

Where you're past the peak, subtract. Removing a person from an overloaded project, cutting a meeting, or narrowing scope raises total output there, which is a genuinely counterintuitive action that needs stating clearly to whoever has to approve it.

Where it breaks down

Every concept here has one. It is the section most summaries leave out.

It describes a shape and explains nothing. Falling output per person is consistent with diminishing returns, with a harder backlog, with a departure nobody replaced and with a morale problem. The curve tells a manager to go looking and gives no help at all in choosing between the candidates, so a team that stops at the diagram has bought a vocabulary rather than a diagnosis.

Plenty of things run the other way. Networks, marketplaces, standards and platforms get more valuable with each participant over the range most businesses care about, and applying this idea there produces exactly the wrong decision with an economics textbook behind it. Check which regime you're in, because both curves are available and each one makes its own conclusion look obvious.

The fixed factor is rarely fixed and rarely single. Real teams have several partial constraints that shift as the work changes, so the tidy story of one scarce resource is usually a simplification chosen after the fact. It's a useful simplification, and it does mean the confident version of the diagnosis is overstated.

The evidence for the organisational version is thinner than for the agricultural one. Ricardo's case rests on land, which is genuinely fixed and genuinely measurable. Ringelmann's rope-pulling experiments hold up and cover small groups doing one simple task. Between that and a claim about a sixty-person engineering department there's a great deal of extrapolation and very little measurement.

It's an excellent excuse for refusing resources. Because the argument sounds technical and the constraint is rarely proven, a manager who doesn't want to grow a team has a respectable-sounding reason available at all times, and the team asking for help has no way to disprove it.

In one line

Watch what each extra unit buys rather than the total, and when it stops buying much, go and find the thing you're holding fixed.