It feels responsible to keep every engineer 100% booked. Idle time looks like waste. But there's a piece of math from queueing theory that says a fully-utilized team isn't a maximally productive team, it's a gridlocked one. As utilization approaches 100%, the time work spends waiting doesn't rise gently. It explodes.
Key Takeaways
- Queueing theory (Kingman) shows wait time rises non-linearly with utilization, and spikes toward 100% (queueing theory).
- A rough model: queue size scales like U² / (1 − U), so going from 80% to 95% utilization multiplies delays (Kingman's formula).
- Work on product-development flow warns against pushing past ~80% utilization without expecting delays to balloon (LeSS on queueing).
- A little slack isn't waste; it's what keeps a team fast and responsive.
The Math Nobody Wants to Believe
Here's the counterintuitive result. In any system where work arrives with some variability, and software work always does, the time a task spends waiting depends brutally on how full the system is. A common approximation puts queue length proportional to U² / (1 − U), where U is utilization (Kingman's formula). Plug in numbers: at 50% utilization the term is modest; at 80% it's meaningfully higher; at 95% it's enormous; and as U approaches 100%, it heads toward infinity. The idea traces to the mathematician Kingman, who studied exactly this heavy-traffic behavior in the 1960s.
Translated: a team you've booked to 100% has no capacity to absorb the normal variability of real work, an urgent bug, a task that ran long, so everything queues behind everything else, and lead times blow up (queueing theory for teams).
| Utilization | Relative wait time |
|---|---|
| 50% | Low |
| 80% | Noticeably higher |
| 90% | High |
| ~100% | Runaway |
Why Highways and Engineers Are the Same
You already know this from traffic. A highway at 50% capacity flows freely. At 100% capacity it isn't moving twice as much traffic, it's a jam, and one extra car creates a wave of brake lights behind it. Engineering teams work the same way. A fully-booked engineer has no room for the unexpected, so when something urgent lands (and it always does), it either waits behind their queue or bumps everything else into a longer queue. The variability real work always carries turns full utilization into gridlock.
A Concrete Version
A manager proudly assigns every engineer a full sprint of committed work, 100% booked, no slack. Then a production bug lands, a customer escalation comes in, and one story turns out twice as big as estimated. With no slack, each of those shoves the committed work back, half the sprint's commitments slip, and everything is now "urgent." Book the same team to ~80% and leave real slack, and those same interruptions get absorbed without derailing the plan. The 80%-booked team reliably finishes more than the 100%-booked one, because it isn't in a permanent traffic jam.
The Honest Counterpoint
Slack can absolutely be abused, and "leave 20% free" is not a license to loaf. The point isn't idle engineers; it's unallocated capacity that absorbs variability and gets spent on the things full-booking squeezes out: paying down technical debt, fixing flaky tests, mentoring, and the small improvements that compound. And the right amount of slack varies, a stable, predictable workstream can run hotter than one full of interrupts. The rule isn't a magic 80%. It's: stop treating 100% booked as the goal, because the math guarantees it makes you slower.
What This Means for Planning
Planning a team to the edge of its capacity feels efficient and reliably backfires, which is why experienced engineering leaders build in slack on purpose. It pairs with the cost of context switching (an over-booked team interrupts itself constantly) and the crunch research (a maxed team has no recovery capacity). When demand genuinely exceeds sustainable capacity, the fix is more capacity or less scope, not booking people to 100% and hoping. See available engineers.
Frequently Asked Questions
Why does 100% utilization slow a team down?
Queueing theory shows wait times rise non-linearly with utilization and spike toward 100%. A fully-booked team has no capacity to absorb the normal variability of real work, so everything queues and lead times explode.
What utilization should a team target?
There's no universal number, but work on product-development flow warns against routinely pushing past about 80% without expecting delays to balloon. More variable, interrupt-heavy work needs more slack.
Isn't slack just wasted capacity?
No. Slack absorbs variability (urgent bugs, underestimated work) and gets spent on debt reduction, testing, and mentoring. It keeps a team responsive; the math says removing it makes you slower, not faster.
What if demand really exceeds capacity?
Then add capacity or cut scope. Booking people to 100% doesn't create more throughput; it creates a queue. The honest fixes are fewer commitments or more hands.
The Bottom Line
Full utilization feels efficient and is quietly self-defeating. Queueing theory guarantees that as a team approaches 100% booked, wait times explode and everything slows down. Leave real slack, plan to something like 80%, and the team absorbs the unexpected and finishes more, not less.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
