Improving Efficiency through Increased Slack
The instinct when a team is under a time-crunch is to push harder. Fill every hour. This feels like the right move. It is almost always wrong.
What maximizing utilization actually optimizes for is busyness. Everyone looks busy, everyone is busy, and yet things aren't moving. The reason is that utilization and speed are not the same thing. The metric you actually want to improve is cycle time: how long it takes a single piece of work to move from start to done. And cycle time gets destroyed when a system is running at full capacity.
Think about how a CPU behaves. At 80% capacity it runs smoothly — tasks get scheduled, work gets done, the system responds. Push it to 100% and something different happens. It starts context-switching constantly, thrashing between tasks, spending more time managing the load than processing it. Output actually drops. The same dynamic plays out on teams. A team running at full capacity isn't a team running at peak performance. It's a team that has no room to absorb anything.
Here's how it plays out in practice. Every developer is working on something. A high-priority item comes in. It waits, because there's no one to pick it up. Meanwhile, a developer hits a blocker — waiting on a design review, waiting on an API, waiting on a decision. Rather than sitting idle, they pick up something new. Now they're carrying two things. Neither finishes. The in-progress pile grows. The team looks busier than ever and the actual output has slowed to a crawl. Not because people aren't working hard, but because the system is full and nothing can move.
A useful way to picture this: imagine a team passing work to each other like balls. If everyone is already holding a ball, no one can catch a new one. Work stops moving. The solution isn't to throw more balls — it's to make sure someone always has a free hand. That free hand is slack. It looks like unused capacity. It is actually what keeps everything else flowing.
The counterintuitive truth is that a team with slack moves faster than a team running at capacity. Not because they're doing more, but because they can actually finish what they start, absorb the unexpected, and respond when something urgent arrives. Protecting that capacity isn't inefficiency. It's the mechanism that makes the whole system work.
What would it take to protect enough slack that your team could actually respond when something urgent comes in? And how do you make the case for doing less when the pressure is always to do more?
