Throughput beats utilisation

Every engineering leader has walked into an organisation where everyone is genuinely busy and nothing is arriving.

It's a confusing thing to see for the first time, because busy looks like the right answer. Calendars are full. Nobody's idle. Every engineer can tell you what they're working on, and none of them are lying. And the roadmap hasn't moved in six weeks.

The explanation isn't effort, or talent, or even prioritisation. It's arithmetic, and it's been well understood since the 1960s by everyone except the people who plan software teams.

The curve nobody puts on a slide

Take any system where work arrives at unpredictable times and takes an unpredictable amount of effort. A motorway. A hospital. A checkout queue. An engineering team.

For that system, the wait time doesn't rise gently as you load it up. It rises slowly, then it goes vertical. At 60% loaded, a queue barely exists. At 80%, waiting time is roughly double what it was at 60. At 95%, you're waiting something like ten times longer, and the system is no longer really predictable at all. Same people, same skill, same amount of work arriving. Only the loading changed.

The exact numbers depend on how variable the work is, and software work is about as variable as work gets. Two tickets that look identical can differ by a factor of twenty in effort. That variance is what turns a busy team into a stuck one.

Traffic is the intuition everyone already has. A motorway at 60% capacity moves at the speed limit. Add 20% more cars and it doesn't slow down by 20%, it stops. Nobody looks at a traffic jam and concludes the drivers weren't trying hard enough.

Why full teams feel fast and aren't

The reason this is hard to see from inside is that utilisation is visible and queueing isn't.

You can see whether an engineer has work assigned. You cannot see the four days a change spent waiting for review, because those four days aren't in anyone's calendar and don't appear on any dashboard. They're not idle time for a person, they're idle time for the work, and no standard management tool tracks it.

So the org optimises the thing it can see. Everybody gets assigned something. Nobody has a gap. And the work itself sits in queues that nobody is measuring, for the overwhelming majority of its life.

When teams first measure this honestly, the ratio of active work to elapsed time usually comes in somewhere between five and fifteen percent. That number is not a productivity problem. It's a queueing problem wearing a productivity problem's clothes, and hiring more people makes it worse before it makes it better.

The number I actually run

Sixty to seventy percent booked. Not eighty, not "as close to a hundred as we can get."

That's lower than most leaders are comfortable saying out loud, and I want to be precise about what it means, because it isn't a licence to do less. It means that of the hours a team has, only 60 to 70 percent are committed to planned work in advance. The rest is real work too. It's the interrupt that arrives on Tuesday, the incident, the review that needs someone senior for two hours, the colleague who's stuck, the thing that turned out to be three times harder than anyone thought.

Every one of those is going to happen. The only question is whether the calendar admits it in advance or discovers it in arrears.

A team at 100% planned utilisation isn't a team with no slack. It's a team whose slack is unbudgeted, and unbudgeted slack gets paid for out of the plan. Something slips, every time, and because it wasn't planned it slips invisibly and late.

The interrupt budget

The mechanism that makes this concrete, and that I'd put in place before almost anything else, is naming who is on interrupts this week.

One person per team. They take the questions, the small requests, the "can you just look at this," the escalations from support. Everyone else is protected. The rotation moves weekly and it's explicitly a real job, not a punishment or a slow week.

What this buys you is a team where the other six people are actually working on planned work at close to the rate you planned it, instead of seven people each being interrupted enough to lose their thread twice a day. The interrupt load doesn't go down. It just stops being spread thinly across everyone, which is the version that destroys the most value per hour of interruption.

It also makes the load visible for the first time. If the interrupt person is drowning every single week, you don't have an interrupt problem, you have a product quality problem or a documentation problem, and now you can see it and argue about it with numbers.

Defending it upward

This is where most leaders lose the argument, because they defend slack on humane grounds and get met on economic ones.

Don't argue that people need breathing room. It's true, and it will be heard as a request for permission to be slower. Argue the throughput case instead: we are choosing a loading level that maximises how much shipped work comes out the other end, and the fully-booked version produces less. Slack isn't the cost of being kind. It's the cost of being fast, and it's cheaper than the alternative.

Then bring evidence from your own system rather than from a textbook. Lead times before and after. The one week the team was fully committed and delivered less than the week they weren't. A count of how many things are currently in progress versus how many finished last month.

The strongest version of the argument is a promise attached to it: we will hold the loading, and in exchange the dates we do commit to will be dates we hit. Most executives will take that trade instantly, because unreliable commitments cost them more than slow ones. What they won't accept, and shouldn't, is slack with no accountability attached.

What to check on Monday

Count the things currently in progress on one team, then count how many things that team finished last month. If the first number is anywhere near the second, everything on that list is going to take much longer than anyone thinks.

That's not a motivation problem, and the fix isn't a conversation about focus. Stop starting things.