Fix Your Bottleneck and It Just Moves Somewhere Else

When a reporter pushed Eliyahu Goldratt to compress the theory of constraints into a single word, he answered: focus. Every system has exactly one factor limiting its throughput, and total process throughput can only be improved when the constraint is improved. Fix that one limit and something surprising happens: the bottleneck does not disappear. It moves.

I find this idea genuinely useful, because it explains why so many improvement efforts feel like running in place. You work hard, you fix real problems, and the system as a whole barely moves. The theory of constraints tells you why: you were probably improving something that was never the limit.

Where the theory of constraints came from

The theory of constraints entered mainstream management through a novel. In 1984, physicist-turned-consultant Eliyahu Goldratt published The Goal, a business story about a plant manager racing to save his factory. Rather than a textbook, he wrote a page-turner, and the method spread on the strength of the story.

The core claim is almost stubbornly simple. Goldratt used the image of a chain: no chain can ever be stronger than its weakest link. A system is the same. Its output is governed by a single limiting element, and adding strength anywhere else changes nothing about what the whole thing can carry.

That is why the one-word summary matters. When asked to distill the whole method, Goldratt said, "never mind a sentence, I'll explain in one single word: FOCUS". Focus is not a motivational slogan here. It is a mathematical consequence of how constrained systems behave.

The physics background shows. Goldratt approached organizations the way a physicist approaches a system: look for the governing variable, and treat everything else as noise around it. Most management advice assumes improvement is additive, that ten small gains sum to one large one. The theory of constraints says the opposite. Only the gain at the limit counts, and the rest is rounding error until the limit moves.

What actually counts as a constraint

A constraint is the point where demand for capacity exceeds supply of capacity. In a factory it might be one machine. In a service business it is more often a person, an approval step, a single skill only one team member has, or the number of decisions the owner can personally make in a week.

The constraint is rarely where the noise is. It hides behind the loudest complaints, which usually come from the busy areas that are not actually the limit. This is where the theory of constraints becomes uncomfortable, because it asks you to ignore visible activity and look for the quiet choke point that everything else is waiting on.

Knowledge work is not exempt. Analysts have extended the method well past the factory floor: the constraints theory applies in all sorts of manufacturing and development areas, including lean, agile, and more, and across software development, IT operations, and project management. A backlog of half-finished work is just inventory piling up behind a bottleneck by another name.

The five focusing steps, in detail

Goldratt turned the principle into a repeatable cycle. The five focusing steps are the practical engine of the theory of constraints, and each one has a specific job.

Identify the constraint. Find the single element that currently limits throughput. Not the ten things that annoy you. The one thing everything else queues behind.

Exploit the constraint. Before spending any money, wring every drop of capacity out of the limit you already have. If the constraint is idle during lunch, during handoffs, or while waiting for approvals, you are losing throughput you could recover for free. This step matters because constraints are often under-utilized, running well below their real capacity simply because nobody protected them.

Subordinate everything else. Make every other part of the system serve the constraint. Non-constraints should run at the pace the constraint can absorb, not at their own maximum speed. This is the step that feels wrong, and it is the most important one.

Subordination is where discipline shows, because it means deliberately holding back parts of your operation that could go faster. A team trained to keep everyone maximally busy will resist it. The point is not to keep people idle. It is to stop producing work that has nowhere to go, and to redirect that freed effort toward feeding and protecting the constraint instead.

Elevate the constraint. Only now do you add capacity: hire, buy, automate, or restructure to lift the limit. You do this after exploiting and subordinating, because those steps are cheaper and often make elevation unnecessary.

Prevent inertia from becoming the constraint. Once you elevate, the limit moves. Do not let the rules and habits you built around the old bottleneck harden into the new one.

Why local efficiency away from the constraint is waste

Here is the counterintuitive part that trips up most teams. Making a non-constraint faster does not help. It usually hurts. The Institute puts it plainly: strengthening any link of a chain apart from the weakest is a waste of time and energy.

When you optimize a step that sits upstream of the bottleneck, you produce work faster than the constraint can process it. That work does not become output. It becomes inventory, a queue, a pile of half-done things waiting. You feel productive while the system gains nothing.

This is the trap of local efficiency: optimizing each part in isolation and assuming the whole improves. It rarely does. A machine running at one hundred percent utilization looks impressive on a dashboard and, if it sits behind the real constraint, is just manufacturing delay. I have written before about how teams game every metric you set, and local efficiency targets are a prime example: they reward motion that does not move the system.

The same logic explains why most website and operational metrics fail to connect to revenue. A number that measures a non-constraint can climb all quarter while throughput stays flat, because you were never measuring the thing that limits the outcome.

The moving constraint, and why that is good news

The corollary is the part people find deflating at first. The moment you break the current constraint, a new one appears somewhere else. The weak link, once elevated, may not remain the weakest; a new constraint demands a new way of managing, so you return to Step 1.

People hear "it never ends" and feel defeated. I read it the opposite way. A moving constraint means your job is never to optimize everything at once. It is to find the one active limit, exploit it, subordinate the rest, elevate if you must, and expect to repeat.

That reframes improvement from an impossible mandate into a sequence. You are not permanently behind on a hundred fronts. You have one constraint at a time, and a queue of everything else that can safely wait its turn. The work is bounded, even when it is continuous.

This is also why running operations well is a discipline rather than a one-time fix. Removing the real constraint in a business system, then finding the next one, is exactly the ongoing loop that a managed digital operations methodology is built to sustain, rather than a project you finish and walk away from.

How a small team applies it: sequence over overwhelm

For a small operation, the theory of constraints is less a factory technique and more an antidote to feeling underwater. When everything seems urgent, the method gives you permission to work on one thing.

Start by asking what everything else is waiting on. If new work stalls until the owner personally reviews it, the owner is the constraint, and hiring another salesperson upstream only deepens the queue. The honest answer to that question decides where all your energy should go, which is often a different question than when to automate and when to hire.

Protect the constraint from interruption. Context-switching is one of the quietest ways a small team starves its own bottleneck, since the limiting person loses capacity every time attention fragments. I have covered the real cost of context-switching separately, and it is precisely the kind of free capacity the "exploit" step is meant to recover.

Be careful about automating around the constraint before you understand it. Some steps genuinely should stay manual, and knowing which tasks you should never automate keeps you from pouring effort into a non-constraint that only produces more queue.

Finally, remember that a bottleneck is often not a capacity problem but a coordination problem. When your operational picture is scattered across tools that do not talk to each other, the true constraint is visibility itself, which is why disconnected data is more expensive than missing data. You cannot subordinate a system you cannot see.

The calm version of all this: chasing local efficiencies away from the constraint is motion, not progress. Find the one choke point, give it everything, and let the rest wait. You can read more of how we think about building durable operations across the Kief Studio blog.

Related reading

• When to Automate and When to Hire
• The Real Cost of Context-Switching
• Disconnected Data Is More Expensive Than Missing Data
• Five Website Metrics That Actually Connect to Revenue
• Anti-Automation: The Tasks You Should Never Automate
• Why Your Team Games Every Metric You Set

Frequently Asked Questions

What is the theory of constraints in simple terms?

It is the principle that every system has one limiting factor, or constraint, that governs its total output. Improving anything other than that limit produces little or no gain, so the practical work is to find the one bottleneck and focus your effort there before anything else.

What are the five focusing steps?

Identify the constraint, exploit it (get the most from what you already have), subordinate everything else to it, elevate it (add capacity only if needed), and then prevent inertia from letting old habits create the next constraint. When the limit moves, you return to step one and repeat.

Why does fixing one bottleneck just create another?

Because a system always has a single tightest point. When you relieve the current one, some other element becomes the new limit on throughput. This is expected, not a failure. It means improvement is a continuous loop rather than a one-time fix, and it keeps your attention on the one constraint that matters right now.

Why is improving a non-constraint considered waste?

Because work produced faster than the constraint can absorb it does not become output. It piles up as inventory, queues, and half-finished tasks waiting behind the bottleneck. The system as a whole gains nothing, even though the sped-up step looks more productive on its own.

How does a small business use the theory of constraints?

Treat it as sequence instead of overwhelm. Identify the single thing everything else is waiting on, protect that person or step from interruption, and let lower-priority work wait its turn. You are not behind on ten things; you have one active constraint and nine things that can safely wait.