The Last Twenty Percent

The final stretch of capacity isn’t capacity at all. It’s the margin that absorbs variance.

The utilisation curve

A server running at 50% capacity handles traffic spikes gracefully. The same server at 90% becomes brittle. Normal variations that were absorbed before now cause requests to queue, response times to spike, and eventually requests to drop.

The relationship isn’t linear. Going from 50% to 70% costs you some headroom. Going from 70% to 90% costs you most of your resilience.

Teams work the same way.

At 70% utilisation, people have time to absorb the unexpected. A colleague is sick, a client escalates, a system breaks. The slack in the system handles it.

At 90%, those same disruptions cascade. One person’s delay becomes another’s bottleneck. The ripple spreads. Everyone’s working flat out, but throughput drops because the system has no give.

Why the last 20% is different

Most people assume capacity works linearly. Use 50%, get 50% output. Use 90%, get 90% output. The remaining 10% is waste you should eliminate.

But that’s not how systems under load behave.

The unused capacity isn’t idle. It’s doing something: absorbing variance. Every system has variation — demand fluctuates, people have off days, dependencies fail, priorities shift. At lower utilisation, the slack absorbs this. At high utilisation, there’s nowhere for it to go.

The last 20% of capacity looks like headroom. It functions as a shock absorber.

When you use it for production, you haven’t gained 20% more output. You’ve traded resilience for throughput. The maths might look like a good deal — 90% is better than 70%, surely? — but you’ve changed what kind of system you’re running.

The cascade effect

At the individual level, high utilisation means context-switching and interruptions. Small delays compound. Work that should take an hour stretches to three because you’re juggling five other things.

At the team level, everyone’s delays propagate. If Alice is blocked, Bob waits. If Bob is late, Carol’s work piles up. At 70% utilisation, these absorb naturally. At 90%, they cascade.

At the organisational level, the whole system becomes fragile. A single sick day, a single urgent request, a single unexpected problem — and suddenly multiple projects slip, deadlines move, and firefighting becomes the norm.

The irony: pushing to 90% utilisation often delivers less than staying at 70%, because the cascade effects eat the gains.

When it makes sense anyway

Sometimes you choose to push into the last 20%. A product launch, a funding round, a critical deadline. The organisation runs hot for a period, trading resilience for output.

This can be the right call. But it’s a trade-off, not a free lunch.

What you’re trading: the ability to absorb surprises. While you’re running at 90%, every disruption hits harder. Recovery takes longer. The team accumulates fatigue that compounds invisibly.

What you’re gaining: concentrated output for a defined period. If the stakes are high enough and the duration is short enough, it can be worth it.

The mistake is treating 90% as the new normal. Sprint mode works as a sprint. As a permanent state, it’s just slow with extra exhaustion.

The honest question

Before pushing into the last 20%, ask: what happens when something goes wrong?

If the answer is “we’ll handle it” — that’s wishful thinking. At 90% utilisation, you don’t have the capacity to handle it. You’re already using the capacity that would handle it.

If the answer is “we’ll drop something else” — that’s honest. You’re acknowledging the trade-off. Just make sure you know what you’re willing to drop.

If the answer is “nothing will go wrong” — that’s the planning fallacy. Something always goes wrong. The question is whether your system can absorb it or whether it cascades.

Running at 70% isn’t leaving 30% on the table. It’s keeping 30% available for the variance that’s coming.

Whether that trade-off makes sense depends on your context. But it is a trade-off. The last 20% of capacity comes at a price, and the price is resilience.

Related: Capacity and Flow · Expensive Yes

Connects to Library: Complex Adaptive Systems · Theory of Constraints