Not All Waste Is Waste
The word "waste" smuggles in a verdict before the analysis begins. Theory of Constraints offers a sharper test: waste relative to what?
TL;DR
Lean says eliminate waste. Theory of Constraints asks: waste relative to what? Removing idle capacity at a non-bottleneck can make a system fragile, not efficient. Optimizing a process that is not the constraint produces local gains with zero global impact. Both errors flow from evaluating parts of a system without reference to the whole.
Someone posted a question on LinkedIn recently that stopped me mid-scroll. It was in response to one of Rami Goldratt’s “TOC Slaps” cartoons — Rami is Eli Goldratt’s son and, along with his sister Efrat, continues the TOC work Eli began. The cartoons riff on the Batman-slapping-Robin meme to poke at ideas that sound obvious but aren’t. The question was:
“How can removing waste in a system be a bad thing?”
It’s the kind of question that feels like it answers itself. Of course removing waste is good. Who would argue for keeping waste? The word itself does most of the work. Nobody defends waste. The moment you label something as waste, the argument is over.
And that is exactly the problem.
The Word Does Too Much Work
“Waste” is not a neutral description. It is a verdict. When you call something waste, you have already decided it has no value. What remains is just the mechanics of removing it. The strategic question — should we remove it — has been skipped entirely.
Lean methodology uses the Japanese term muda to categorize activities that do not add value from the customer’s perspective. The framework is elegant and has contributed enormously to operational thinking. I am not dismissing it. But the test it applies — “does this step add value for the customer?” — is a local test. It evaluates each activity on its own terms. It does not ask where that activity sits in the larger system, or what role it plays relative to the thing that is actually limiting performance.
That is where Theory of Constraints diverges, and the divergence matters.
Waste Relative to What?
In TOC, the system has a constraint — the one resource or policy that most limits the system’s overall performance. Think of it as the bottleneck, the narrowest point in the pipe. Everything upstream and downstream of that constraint exists in relationship to it. The performance of the whole system is governed by what happens at the constraint.
This gives you a very different test for waste. Instead of asking “does this activity add value?” you ask “does this activity affect the constraint?”
That test produces two results that surprise people.
First: some things that look like waste are not. A machine sitting idle upstream of the bottleneck looks wasteful. A nurse with downtime between tasks looks inefficient. A buffer of work-in-process inventory between two stations looks sloppy. But in a system governed by a constraint, these are not waste. They are protective capacity. They are the slack that absorbs variation and keeps the constraint from starving.
If you strip out that slack — because it looks like waste, because someone put it on a dashboard and it made the utilization numbers look bad — you have not improved the system. You have made it fragile. The next time there is a hiccup upstream (and there is always a hiccup), the constraint has nothing to work on. Throughput drops. The whole system pays for an efficiency gain that existed only on a spreadsheet.
Goldratt was direct about this: a system needs protective capacity at non-constraints. Removing it in the name of efficiency is not improvement. It is damage.
Second: some things that look productive are waste. This is harder to see because it is wrapped in the language of improvement. A team spends three months optimizing the turnaround time of a process that is not the constraint. They succeed. The numbers improve. There are presentations. People feel good about the work.
But system throughput does not change. It cannot change, because the constraint has not moved. The improvement happened somewhere that does not govern the system’s output. The time, money, and management attention spent on that project were consumed without producing any global benefit.
That project was the waste. Not the idle machine. Not the buffer. The improvement initiative itself.
Two Misidentification Errors
So the answer to the LinkedIn question — “how can removing waste be bad?” — comes down to misidentification. There are two kinds.
Calling something waste when it isn’t. Protective capacity, buffers, strategic slack — these look like inefficiency. They violate the intuition that every resource should be fully utilized and every minute should be productive. But that intuition is wrong at the system level. A system where every resource runs at full utilization is not efficient. It is brittle. It has no ability to absorb the variation that every real system encounters.
This is counterintuitive enough that it is worth restating. In a well-managed system, non-constraint resources should have excess capacity. If they don’t, something is wrong.
Not calling something waste when it is. Improvement projects aimed at non-constraints consume real resources — staff time, management attention, capital, organizational energy, morale. These are finite. Every hour spent optimizing a non-bottleneck is an hour not spent on the constraint. And because the results look good locally (faster turnaround, higher utilization, cleaner metrics), the organization gets positive feedback for doing work that does not matter at the system level.
This second error is more damaging because it is self-reinforcing. The local wins generate reports, meetings, promotions. An entire improvement infrastructure can grow around work that has no global impact. And because everyone involved is working hard and producing measurable results, it is almost impossible to challenge from inside the system.
What Both Camps Can Take From This
I want to be careful here. This is not a case against Lean. Lean’s contribution to operational thinking is real and substantial. The discipline of looking at every step through the customer’s eyes, of mapping value streams, of making problems visible — that discipline has improved countless organizations.
But Lean’s definition of waste does not include a system-level filter. It treats waste as something you can identify by examining each activity in isolation. TOC says you cannot. TOC says waste only has meaning in relationship to the constraint, and that without knowing where the constraint is, you cannot tell the difference between genuine waste and load-bearing capacity.
For Lean practitioners, the useful takeaway is: before you eliminate, locate. Find the constraint first. Then the waste categories become powerful — applied at the constraint, they are exactly the right tool. Applied everywhere indiscriminately, they are expensive misdirection.
For TOC practitioners, the useful takeaway is: Lean’s vocabulary and tools for identifying non-value-added activity are genuinely helpful once you know where to point them. The two frameworks are not enemies. They are incomplete without each other.
The Question Behind the Question
“How can removing waste be a bad thing?” is really asking: “How can something obviously good be harmful?” And the answer is that the obvious goodness depends on a hidden assumption — that you have correctly identified what is waste and what is not.
If you label protective capacity as waste and remove it, you break the system.
If you label non-constraint optimization as improvement and invest in it, you starve the constraint of the attention it needs.
Both errors flow from the same source: evaluating parts of a system without reference to the whole.
I think being very precise about what we call waste — and being willing to defend things that look like waste but aren’t — is one of the most practical disciplines an organization can develop. It is also one of the hardest, because it requires saying “that improvement project is not worth doing” to people who are proud of it.
Distinguishing between true waste and protective capacity is rarely obvious. In fact, it is usually the hardest part of the analysis.
If you are looking at a specific process in your system and aren’t sure if it’s waste or insurance, send me a note. I am happy to help you sanity-check your logic.
You can reach me at john@common-sense.com.