Waste Before Capacity

A motorway at six in the evening. Nothing has crashed and nothing is broken. Every lane is full of cars that are barely moving.

You have driven that same road at two in the afternoon, when it is busy and you are still doing the speed limit. It does not hold twice as many cars at six. There is no room for twice as many. It holds somewhat more, and that somewhat is the difference between a ten minute journey and a forty minute one.

The obvious response is to add a lane. It is expensive, it takes a year, and within months the road is full again at six.

When we are behind, the reflex is to add capacity. Our standing preference is to remove waste first, and this page is why, plus the honest limits of that preference.

Why a bit more work stops everything#

The behaviour of that road is not a metaphor. It is how queues behave, and it applies to anything where work arrives and somebody has to process it: a checkout, a support inbox, a review queue, a person’s week.

Here is the same effect in a form you can check against your own experience.

Book six hours of somebody’s eight hour day. Something urgent arrives at eleven and is dealt with by lunch, because there was room for it. Now book seven and a half hours of that same day. The identical urgent thing waits until tomorrow, not because it got bigger, but because there is nowhere left to put it. Add a second urgent thing and it waits until next week.

An extra ninety minutes of commitment did not make everything twenty percent slower. It moved the queue from hours to days.

That is the whole idea, and it is why the last stretch before a schedule is full behaves so differently from the rest of it. Up to a point, adding work adds work. Past that point, adding work adds waiting, and the waiting grows much faster than the work that caused it. A team with room absorbs a sick day, an urgent client issue, or a task that took twice as long, and nobody outside notices. The same team with no room turns each of those into a delay that outlasts the surprise itself.

The same shape governs a motorway, a checkout and somebody's calendar. The long flat stretch is what makes the cliff a surprise: for most of the way, adding work changes nothing you can see, so by the time waiting is obvious you are already past the point where taking a little off fixes it.

Two consequences follow, and both are counterintuitive enough that they need saying explicitly.

A fully occupied team is a slow team. Not a productive one. Utilisation and speed are different things, and past the knee they trade against each other. A person with no unallocated time cannot absorb the thing that turns up, so the thing that turns up waits, and everything queued behind it waits too.

Slack is not waste. It is the room that lets a system absorb surprises, and it is the difference between one that flows and one that stops. Cutting it looks like a win at the time, because the same people are now committed to more work. The cost turns up weeks later as things running late, and by then nobody connects the late thing back to the day the calendar was filled. The decision and its consequence are too far apart to be read as one event, which is why this particular mistake gets made repeatedly.

Little’s Law#

The other piece of arithmetic worth carrying is Little’s Law, which relates three things in any stable queue:

work in progress = throughput × lead time

Rearranged, lead time equals work in progress divided by throughput. Which means that if you cannot increase throughput, and usually you cannot quickly, the only lever left on delivery time is to have less work open at once.

This is why starting another thing when you are already behind makes everything later, including the thing you just started. Nothing about the team changed and nothing about the work changed. The only thing that changed is how many items are simultaneously in flight, and every one of them now finishes later.

The practical form: stop starting, start finishing. Halving what is open roughly halves how long each item takes to come out, without hiring anyone.

Only the constraint matters#

Eliyahu Goldratt’s contribution, in The Goal, is that every system has one constraint at a time, and that capacity added anywhere except the constraint produces no additional output at all.

If code review is the bottleneck, a faster designer, an extra engineer, and a better ticket template all produce exactly the same throughput as before, with a longer queue in front of review. The work arrives sooner and waits longer. It looks like progress at every stage except the one that determines the result.

Same pipeline, same total investment, one difference in where it went. Above, three of the four stages are comfortable and the work is stacked in front of the one that is not. Below, only the narrow stage changed and the queue is gone.

The discipline that follows is short: find the constraint, make sure it is never sitting idle and never doing work that something cheaper could do, and only then consider adding to it. Improving anything else changes how the work feels without changing when it comes out.

What waste looks like in our work#

The Toyota Production System calls it muda, and its categories were written for a factory. Translated to what we actually do, these are the ones that cost us:

Waiting. Work finished by one person and sitting until another looks at it. Review queues, approval queues, waiting on a client answer. In most knowledge work this is the largest single category by a wide margin.
Handoffs. Every boundary crossed loses context and adds a queue. See Handoffs.
Partially done work. Anything started and not finished. It has consumed cost, returned nothing, and is quietly ageing into rework as the surrounding code and the surrounding situation change.
Task switching. Two things half-done take longer than two things done in sequence, and the difference is not small.
Rework from unclear requirements. Built, reviewed, then discovered to be the wrong thing. The cheapest place to fix this is before building, which is what Define is for.
Defects. Anything that comes back. A bug found in production costs many times what the same bug costs in review.
Unused features. Work that shipped and nobody uses is 100% waste, and it is invisible because it looks exactly like delivery.

How to tell where the waste is#

Measure flow efficiency, not utilisation. Take one recent piece of work and divide the time somebody was actively touching it by the total elapsed time from start to done. In most teams that ratio is startling, often well under a quarter. The gap is queue, and the queue is where the time actually went.

Find the queue, not the busy person. Waste accumulates in front of a stage, not inside one. Look at where things are piled up waiting, and note that the busiest-looking person is frequently not at the constraint, because people upstream of a bottleneck stay busy producing things that then wait.

Count what is open. How many items are in flight per person right now? If it is more than a couple, Little’s Law says lead time is being inflated by the count itself.

Ask what somebody is waiting for. Not what they are working on. The answers to that question are the queue, stated in plain language, and they take a minute to collect.

When it goes wrong: the common failure is measuring how busy people are and concluding the team is at capacity. High utilisation with low flow efficiency is the exact signature of a system that needs less work in it, not more people.

Where this stops#

This is a preference rather than a law, and it is misusable in four specific ways.

Sometimes capacity really is the answer. If flow efficiency is already high, work in progress is already low, the constraint has been addressed, and there is still more demand than output, then the honest conclusion is that we need more people. The preference is about sequence: exhaust the cheaper, faster, reversible option before the expensive, slow, hard-to-reverse one. Hiring is not forbidden, it is last.

It can be turned into an excuse for understaffing. “Remove waste” said to a team that has already removed the waste is just a refusal, and it burns the credibility of the idea. If someone shows you the flow efficiency and the queue and the constraint, and the answer is still that they need help, that is the framework working as intended.

Slack must not be reclassified as waste. This is the most dangerous misreading available here, because it uses the vocabulary of the page to argue for the thing the page is against. Unallocated time is what lets a system absorb variation. Squeezing it out is precisely how you get to the wrong end of the curve.

In genuinely new work, some of what looks like waste is how you learn. When nobody knows yet what the right thing is, the version you build and throw away is often the only way the team could have found out what to build instead. Counting that as waste is a category error: it was the cost of finding out, and it bought real information. All of this comes from manufacturing, where the right thing to build is already known and the only question is how to produce it efficiently. Applied to work that is genuinely uncertain, it will tidy you into never attempting anything you are not already sure about.

How we use it here#

Make the capacity case with evidence, because it wins. “We need another person” is easy to argue with and easy to defer. “Our flow efficiency on the last three pieces of work was under a quarter, we each have four things open, everything is queuing behind review, and we have already removed the handoffs we could” is not. It is the same request, and the second version is very hard to say no to.

This is not a hurdle to clear before you are allowed to ask. It is how to ask so that the answer is yes. If the evidence says we are short, we are short, and the numbers make that case far better than anyone’s account of how busy they feel.

Prefer removing a step to adding a person. A handoff deleted, an approval that turns out to be unnecessary, an old path removed so nobody takes it: all of these increase throughput immediately, cost nothing ongoing, and cannot be un-hired.

Protect the slack. A block planned to the last hour is planned to fail on the first surprise. See Blocks & Sprints.

Treat unused work as the most expensive waste we produce, because it consumed everything a shipped feature consumes and returned nothing. That is a discovery problem, not a delivery one, and it is the argument for Discovery Craft being upstream of all of this.

Cadence and Blocks & Sprints are where work in progress is actually limited.
Handoffs is the waste category we control most directly.
Structured Problem Solving is how to find the constraint rather than guess at it.
Discovery Craft is how we avoid building the most expensive waste of all.