Marginal Gains, Marginal Returns

Marginal gains assumes independence. Most systems have dependencies. That’s why it fails.

The seductive idea

British Cycling’s marginal gains philosophy is one of the most cited management concepts of the last decade. The idea: improve everything by 1% — pillows, hand hygiene, bike seats, nutrition — and the gains compound into dominant performance.

It worked spectacularly for cycling. So leaders import it into business. “Let’s find 1% improvements everywhere.” The logic seems sound. Small gains add up.

Except when they don’t.

When gains are additive

Cycling performance is relatively parallel. Aerodynamics, power output, weight, recovery, nutrition — these factors contribute somewhat independently. Improving any one helps, regardless of the others.

If you shave 0.5% off drag and add 0.5% to power output, you get roughly 1% faster. The gains add.

This works when:

• Factors contribute independently
• There’s no sequential dependency
• Improving one thing doesn’t require another to change first

Some business contexts fit this pattern. Brand perception might be parallel: packaging, advertising, customer service, product quality each contribute somewhat independently to overall impression. Improving any one helps.

When gains are multiplicative

Most business processes are serial. Work flows through stages in sequence: leads → qualified → proposals → closed. Requirements → build → test → deploy. Order → manufacture → ship → install.

In serial systems, throughput is determined by the constraint — the slowest stage, the bottleneck, the weakest link.

Improving anything else adds zero.

If your bottleneck is closing deals, generating more leads just creates more proposals that pile up at the same constraint. If your bottleneck is testing, faster development builds inventory waiting to be tested. If your bottleneck is installation capacity, faster manufacturing fills a warehouse.

The gains don’t add. The constraint gates everything.

The Goldratt insight

Eliyahu Goldratt built the Theory of Constraints on this observation:

“An hour lost at a bottleneck is an hour lost forever. An hour saved at a non-bottleneck is a mirage.”

In a chain, strengthening any link except the weakest adds nothing to the chain’s strength. Worse, it adds cost and complexity while the actual constraint stays untouched.

The marginal gains philosophy, applied to a serial system, is actively harmful. It distributes improvement effort across non-constraints, creates the illusion of progress, and leaves the bottleneck — the only thing that matters — unchanged.

How to tell which system you’re in

Parallel (marginal gains works):

• Factors contribute independently to an outcome
• No stage waits for another
• Improving any factor helps, regardless of others
• Example: brand perception, individual athlete performance, customer experience touchpoints

Serial (find the constraint):

• Work flows through sequential stages
• Each stage depends on the previous
• One stage is slower than the others
• Example: sales pipeline, manufacturing line, software delivery, customer onboarding

Most operational processes are serial. Most improvement efforts pretend they’re parallel.

The constraint test

Before improving anything, ask: is this the constraint?

Signs something is the constraint:

• Work piles up waiting for this stage
• This stage is always busy while others have slack
• Improving this stage would immediately increase throughput
• Everything downstream starves when this stage slows

Signs something is not the constraint:

• This stage has idle time
• Work flows through without waiting
• Improving this stage would just build inventory before the next
• The team could handle more if they received it

If you can’t identify the constraint, you can’t improve the system. You can only improve pieces that don’t affect the whole.

The practice

Map the flow first. Before improving anything, understand how work moves through the system. Where are the handoffs? Where does work wait?

Find the constraint. Look for queues, backlogs, and wait times. The constraint is where work accumulates.

Improve only the constraint. Every improvement effort should either expand the constraint’s capacity or reduce demand on it. Everything else is wasted effort.

Expect the constraint to move. Once you improve a bottleneck, a different stage becomes the new constraint. The work is never done — but it’s always focused.

Resist the 1% everywhere instinct. It feels productive. It isn’t. Concentrated improvement beats distributed improvement in any system with dependencies.

Marginal gains is a powerful idea in the right context. The error is applying it universally. Most systems have constraints — find yours first, and improve everything else never.

Connects to Library: Marginal Gains · Theory of Constraints