The five focusing steps are the Theory of Constraints' repeatable improvement loop: identify the constraint, exploit it, subordinate everything else to it, elevate it, then repeat. Run in order and cycled continuously, they raise throughput by concentrating every improvement on the system's single slowest necessary step.
Eliyahu Goldratt built the steps as an answer to a common trap: plants improve everywhere at once, spend a fortune, and watch total output barely move. This guide treats the steps as a how-to. Not what the Theory of Constraints is that is covered in our guide to the Theory of Constraints but how you actually run each step on a floor, in what order, and why the loop never ends.
What are the five focusing steps?
The five focusing steps are Goldratt's ordered cycle for improving any system through its constraint. You work them in sequence, then loop back to the top, because fixing one constraint reveals the next. Here is the loop:
- Identify the constraint. Find the single resource that limits the whole system's output. It is usually the step where work-in-process piles up in front and the steps behind sit starved and waiting.
- Exploit the constraint. Get the most out of it without spending money. Keep it running through breaks and changeovers, protect it from defective input, and make sure it never waits on a missing operator, part, or instruction.
- Subordinate everything else. Make every other resource serve the constraint. Non-constraint stations run at the constraint's pace, feeding it a steady diet instead of burying it in inventory. This is the step that feels wrong and matters most.
- Elevate the constraint. Only now do you spend. Add a shift, a second machine, offloaded work, or capital, but only after exploiting and subordinating have run out of free gains.
- Repeat. Once the constraint is broken, a new one appears elsewhere. Return to step one, and watch that inertia does not turn yesterday's fix into today's policy constraint.
Why not just improve everywhere at once?
Because a system moves only as fast as its constraint, and effort spent anywhere else does not raise output, it just relocates the inventory pile. A packaging line running at 100 cases an hour cannot ship more just because the mixer upstream got 20% faster. The extra mix has nowhere to go but a growing pile in front of packing. You spent money and gained nothing but work-in-process.
This is the insight that makes the five focusing steps worth the discipline. Local improvements feel productive, every station is busier, every efficiency number ticks up, while the number that pays the bills, throughput, sits flat. The steps force you to answer one question first: where is the constraint? Then they spend your attention only there. It is the opposite of a plant-wide efficiency drive, and it is why a smaller, more focused effort usually beats a bigger scattered one.
| Step | The question it answers | Typical action | Cost |
|---|---|---|---|
| 1. Identify | What limits the whole system? | Find where WIP piles up and downstream starves | None |
| 2. Exploit | How do we get more from it now? | Stagger breaks, guard input quality, cut its downtime | Low / none |
| 3. Subordinate | How does everything else help? | Pace upstream to the constraint; stop overproducing | None (discipline) |
| 4. Elevate | Do we need more capacity? | Add a shift, a machine, or offload work | High |
| 5. Repeat | Where is the constraint now? | Re-run the loop; check for policy constraints | None |
By the numbers. The five focusing steps come from Eliyahu Goldratt's 1984 business novel The Goal which has sold millions of copies and is a standard operations-management text (Theory of constraints). The Theory of Constraints Institute, founded by Goldratt's collaborators, publishes the canonical wording of the steps as "a process of on-going improvement" (TOC Institute, Five Focusing Steps). The order is the whole point: the free steps come before the expensive one.
How do you identify the constraint?
The constraint announces itself if you know the signs. Work-in-process accumulates in front of it. The steps immediately after it sit starved and idle, waiting for it to feed them. It is the resource everyone blames when an order ships late, and the one that never seems to have spare capacity. On paper, you find it by comparing each resource's load against its true capacity, the one running closest to or over 100% is the bottleneck.
The trap is trusting the wrong numbers. Nameplate speeds and spreadsheet load estimates routinely point at the wrong machine, because the real constraint's true rate is dragged down by small stops, quality holds, and changeover time that never make it into the plan. Finding the constraint honestly means looking at actual cycle times, real machine downtime and where inventory physically accumulates between steps, not the tidy plan. A walk of the floor with your own eyes, or live data from the line, will find the constraint faster than any capacity spreadsheet.
How do you exploit a constraint without spending money?
Exploiting means squeezing every available minute of good output from the constraint before you consider buying more capacity. Every minute the constraint is down, waiting, or making scrap is throughput the entire plant loses and can never get back, so exploitation is a hunt for those lost minutes. The common leaks are predictable.
Concrete exploit moves, in rough priority: stagger breaks and lunches so the constraint runs while people rotate through; put a quality check before the constraint so it never wastes a minute processing parts that will be scrapped downstream; stage its material and tooling ahead of time so it never waits; and move changeover prep off the machine so the constraint is down only for the cut-over itself, not the setup. These are the same tactics as SMED-style quick changeover aimed squarely at the one machine that matters. None of them cost capital, and together they often free 10-20% more output from an asset the plant thought was maxed out.
What does subordinating everything else look like?
Subordinating means every non-constraint resource stops optimizing itself and starts serving the constraint. In practice that is a hard cultural sell, because it asks fast upstream machines to slow down. A station that can run at 140 units an hour, feeding a constraint that can only absorb 100, should run at 100, not 140. Running faster just builds a pile of work-in-process the constraint cannot use, which lengthens lead time, ties up cash, and hides problems in the heap.
This is the step that looks like inefficiency to anyone measuring station-level utilization. That is exactly why it needs management air cover: the supervisor who lets a non-constraint machine sit partly idle is doing the right thing, and the metric that punishes them is the enemy. Subordination is the daily-management face of the loop, it belongs on the gemba board and in the huddle, where the team can see the constraint's pace and match it. It also connects the five steps to flow kaizen which redesigns the whole value stream to feed the constraint smoothly rather than in lumps.
When should you elevate the constraint, and why is it last?
Elevate means adding real capacity, a second machine, another shift, outsourced volume, a capital upgrade, and it comes fourth on purpose. If you elevate before exploiting and subordinating, you spend money buying capacity you already had but were wasting through idle minutes and overproduction. Plants do this constantly: they approve a capital request for a second machine when the first one is only truly running two-thirds of the time it is scheduled.
The rule is simple. Exhaust the free gains first. Only when the constraint is genuinely maxed out, running full, fed clean, protected from starvation, and still unable to keep up with demand, is elevation justified. Done in that order, elevation is a smaller, better-targeted investment, because you know precisely how much more capacity you need and exactly where. Done out of order, it is expensive guesswork.
Why do you always repeat, and what is a policy constraint?
You repeat because breaking a constraint does not remove the bottleneck, it moves it. Elevate the packing line that limited the plant, and the filler upstream becomes the new slowest step. The fifth step sends you back to identify, and that is what makes the five focusing steps a continuous practice rather than a project. A plant running the loop well is always chasing the current constraint, because there always is one.
Goldratt's sharpest warning was about the fifth step: do not let inertia become the constraint. The rules you wrote to manage the old bottleneck can quietly strangle the new one. A policy constraint is a habit or metric, "run every machine at full speed," "never let an operator stand idle," "batch to minimize changeovers", that once made sense and now blocks flow. These are the hardest constraints to see, because they live in the way people already think about the plant. Every time you loop, ask whether the current limit is a machine or a rule.
How is this different from the Theory of Constraints itself?
The Theory of Constraints is the broader body of thinking, the philosophy that every system has a constraint, the throughput/inventory/operating-expense measures, drum-buffer-rope scheduling, and the thinking processes for untangling conflicts. The five focusing steps are the operating loop inside that theory: the repeatable, step-by-step method you actually run to improve. If TOC is the map of why constraints govern a system, the five focusing steps are the turn-by-turn directions. For the wider picture, including drum-buffer-rope and how constraints migrate across the plant, read our Theory of Constraints guide, and see how the loop fits the broader waste-elimination toolkit in lean manufacturing.
The steps only work as well as the data underneath them. Identifying the constraint, proving it is truly maxed out before you spend to elevate it, and catching it the moment it migrates all depend on trustworthy, live numbers from the floor, not spreadsheet estimates. That is the visibility Harmony is built to give: real cycle times, real downtime, and where inventory actually accumulates, captured as the work happens. CLS made exactly that shift, from paper logs found the next morning to production data visible during the shift, the feedback loop that lets constraint management run continuously instead of once a year. Pair the steps with that kind of live picture, and the loop stops being a book and becomes how the plant runs.