Everyone Is Busy and Nothing Is Shipping

An engineering director I worked with pulled up the resource dashboard at the quarterly review. All six teams between 93% and 97% utilized. Green across the board. She presented it as operational proof: the organization was running tight, no waste, everyone working.

Twenty minutes later, the VP of Product asked why a feature estimated at three weeks had been "in progress" for eleven weeks. The director checked her notes. "The team is fully loaded. They're working on it."

The team was fully loaded. That was the problem.

The pattern nobody names

Every software organization has a version of this meeting. The board is full. Everyone has a task. Sprint capacity is allocated to 100%. And yet: features drift. Deadlines slide. "Two-week stories" take six weeks. The diagnosis is always local: bad estimates, unclear requirements, too many meetings, not enough senior developers.

Nobody looks at the utilization number and says: that's the cause.

Not understaffed. Not poorly managed. Overloaded. The organization treats full utilization as a sign of health. It is the opposite: a system running at 95% utilization with variable work is mathematically guaranteed to produce long queues. The proof has existed since 1961. Almost nobody in software has read it.

The math nobody checks

How long work waits in a queue depends on three things: how variable the work is, how loaded the system is, and how long one unit of work takes. The first two multiply each other. When utilization is moderate, variability causes wobbles. When utilization is high, the same variability causes catastrophe. The relationship is not linear. It is exponential.

John Kingman proved this in 1961 for any system with limited capacity and variable demand. The utilization factor alone tells the story. At 50% utilization, wait time equals the work time: manageable. At 80%, it quadruples. At 90%, it is nine times the work time. At 95%, nineteen times. At 99%, ninety-nine times.

At 50%, the system breathes. At 90%, it gasps. At 95%, it is effectively broken. The transition from "fine" to "everything is late" is not gradual. It is a cliff.

And software is the worst case. Variability amplifies the utilization penalty. The more variable the work, the steeper the cliff. Software development sits in the moderate-to-high variability range by any industrial classification. A "five-point story" takes two days or three weeks. Bug fixes range from five minutes to five weeks.

A developer starts the week with a clean plan. By Wednesday, a production incident has eaten a day, a dependency request from another team has consumed the morning, and the requirements for the main feature have changed. The plan didn't survive contact with the system. That is not a failure of planning. It is variability.

Don Reinertsen surveys executives before his product development courses. They self-report 98.5% utilization. At that load, with moderate variability, a two-week task waits 98 weeks before anyone touches it.

Two years. For two weeks of work. Not rhetoric. Arithmetic.

One feature, two structures

Take a single feature. Two weeks of development work.

In a cross-functional team running at 80% utilization, the math predicts eight weeks of waiting plus two weeks of work: ten weeks total. Only 20% of the lead time is active work. The rest is the queue. That ratio is not unusual. Most teams that measure it land between 5% and 15%.

Now route the same feature through three component teams in sequence: backend, API, frontend. Each team's share takes about a week of hands-on effort. Each team is its own queue. Each is running at 90% because managers push for higher numbers.

Each stage: nine weeks of waiting, one week of work. Three stages: thirty weeks.

Same feature. Same people. Same skills. Three times the lead time. The only difference: how loaded the system is and how many queues the work crosses. Every organizational boundary adds a queue. Every queue adds independent wait time. The queues multiply.

Even manufacturing learned this the hard way. Quick Response Manufacturing prescribes 80-85% utilization. Companies that followed the prescription saw lead times drop 80% and revenue double. Manufacturing has lower variability than software. Software runs hotter.

So they prioritize

When everything is late, somebody suggests better prioritization. The logic sounds right: if we can't do everything, at least do the important things first.

But prioritization in a system with 19x wait times is not resource allocation. It is a political contest. The feature that moves to the front of the queue is not the feature with the highest customer value. It is the feature backed by the person with the most organizational weight: the loudest voice, the highest title, the biggest budget. That executive's feature jumps the line. The feature behind it waits another month. That feature's stakeholder escalates. Now two executives are competing for the same overloaded queue.

Then comes the progress report. Weekly status updates. Traffic-light dashboards. Slide decks showing a feature is "in progress" and "on track." The progress report does not exist to inform. It exists to pacify: to tell the stakeholder "we are working on it" so they stop escalating for another week. The report buys time. It does not buy delivery.

The loop closes. High utilization produces queues. Queues produce political prioritization. Prioritization produces escalation. Escalation produces progress reports. And the progress reports produce just enough appearance of movement that nobody questions the utilization number that started the whole cycle. On the dashboard, it is still green.

Why every organization does this anyway

The utilization trap is not caused by ignorance. It is caused by incentive structure.

Cost accounting treats idle people as waste. A team at 70% utilization looks like 30% wasted budget on every report that reaches finance. Managers are evaluated on "is everyone busy?", never on "is work flowing?" "Slack" sounds like laziness. Proposing 80% utilization in an organization that measures resource efficiency feels like asking permission to waste a fifth of the budget.

The asymmetry runs deeper. Nobody measures the cost of waiting. Everyone measures the cost of idle hands. The invisible cost: a feature that a customer needed in January arrives in April. The revenue lost, the trust eroded, the competitor who shipped first. Enormous, but distributed across projects, quarters, and relationships that nobody connects. The visible cost: a manager walks by a developer who is thinking instead of typing. "Do you need something to work on?" Small, but concentrated on one dashboard, in one meeting, on one manager's review. The small visible cost wins every time.

The manager who reports 95% utilization is protecting her budget. The manager who reports 75% utilization is protecting her delivery. The organization rewards the first and questions the second.

The dashboard

The engineering director's quarterly dashboard. Six teams, all green. 93% to 97% utilized.

The numbers have not changed. What changed is what they mean. 95% utilization is not an achievement. It is a prediction: next quarter, someone in this room will ask again why a three-week feature took eleven weeks. And the dashboard will still be green.

Two questions before that meeting happens.

What is your team's utilization? If you don't know, nobody is managing the lever that controls your lead time.

What is the ratio of waiting time to working time for your last five completed features? If the answer is above 5:1, the utilization number on that dashboard explains why.