Eliyahu Goldratt gave manufacturing a rigorous principle: every system has exactly one active constraint at any given time, and that constraint dictates total output. Improve a non-constraint resource and you build inventory, not throughput. Improve the constraint and the entire system improves. The five focusing steps — identify, exploit, subordinate, elevate, repeat — are mechanically simple.
Yet most implementations I have audited produce the same disappointing result. Throughput stays flat, lead times lengthen, and work-in-process grows. The operations team adopts new vocabulary — "we moved the bottleneck" — spoken with the same resignation once reserved for supplier delays. The methodology did not fail. The organisation failed to execute the steps that make it work, particularly the ones that require behavioural change.
TOC demands that you deliberately run non-constraint resources below capacity. It demands that you stop rewarding local efficiency. It demands that you re-run the five-step cycle every time the constraint shifts. These requirements conflict with standard cost accounting, departmental KPIs, and supervisory habits built over decades. The failure modes are predictable, and they are fixable — but only if you are willing to dismantle the policies that create them.
Misidentifying the Constraint
Constraint identification is treated as a one-time event. Someone reviews a snapshot of production data, or asks the loudest department head, or recalls where the bottleneck was during last year's audit. The result is a TOC programme built around a resource that is not actually constraining the system. You exploit it, subordinate to it, and invest in elevating it. Throughput does not change.
The error compounds quickly. A temporary bottleneck — a machine down for maintenance, a supplier with a one-time delay — gets mistaken for a systemic constraint. Capital is spent elevating a resource that will not be the constraint once the temporary condition clears. The organisation has optimised a non-bottleneck, which Goldratt identified as the precise definition of waste in a constrained system.
Valid constraint identification requires real-time data and continuous validation. Crossover periods — where demand mix or volume shifts create a near-tie between two resources — need particularly careful monitoring. In my experience at a major aerospace manufacturer, routing verification KPIs exposed constraint shifts within hours, not weeks. Organisations that get this right treat identification as a daily question, not an annual assumption.
The test is simple: if you removed one unit of capacity from the suspected constraint, would total system output drop? If yes, you have found it. If not, keep looking. Do not write the constraint on a whiteboard and build a three-year strategy around it.
Constraint Validation Thresholds
Subordination That Never Happens
Step three — subordinate everything to the constraint — is where most TOC programmes die. Subordination requires every non-constraint resource to deliberately produce less than it could. Operators must stand idle while parts pile up. Supervisors must accept utilization numbers below target. Plant managers must defend those numbers in the monthly operations review. Most organisations cannot stomach this for more than a few weeks.
The behavioural resistance is predictable and structural. A machine operator measured on utilization for twenty years will not voluntarily run below capacity. The supervisor pushes back because idle time looks bad on the shift report. Finance pushes back because idle capacity is a balance sheet problem. So the subordination step is quietly abandoned, and every machine goes back to running at full speed.
The consequence is invisible but severe. The constraint is still the constraint, but now it is drowning in work-in-process it cannot process. Changeover times lengthen because the queue is chaotic. The scheduling team builds an elaborate prioritization system to manage 500 jobs in front of the bottleneck — a system that would not exist if subordination had been enforced. The organisation has technically implemented steps one and two, but skipped the step that makes exploitation meaningful.
Subordination separates organisations that understand TOC from organisations that have read the book. The fix is measurement: stop penalizing idle time at non-constraint resources. If the machining centre runs at full capacity feeding a constraint that cannot absorb the output, the machining centre is producing waste — not value. Reward the operator for standing down, not for building inventory.
The Bottleneck Shell Game
When an organisation successfully identifies, exploits, and subordinates, the constraint moves. This is supposed to happen. It is step five. It is the sign the process is working. But in most organisations, the constraint moves and nobody notices — or someone notices but the information does not reach the scheduling team, the metrics, or the managerial attention still locked on the old constraint.
The organisation remains subordinated to a resource that is no longer the bottleneck. The actual new bottleneck runs uncontrolled. This is the bottleneck shell game, and it is the most common reason TOC implementations fail after the initial honeymoon period. The team got a quick win by exploiting the original constraint, celebrated, wrote a case study, and assumed the constraint would stay put forever.
Goldratt warned against this explicitly. Step five says repeat, but he also warned: do not let inertia become your constraint. The dashboards, meetings, and metrics built around the original constraint become the new constraint — because they prevent the organisation from seeing where the actual constraint has moved. In a dynamic manufacturing environment, the constraint can shift in hours. Daily validation is not excessive; it is the minimum.
Local Optimisation Masquerading as TOC
The most toxic failure mode is adopting TOC language without changing the measurement system. Every department is still measured on its own utilization, its own efficiency, its own output. People talk about the constraint, throughput, and drum-buffer-rope — but the dashboard drives behaviour in the opposite direction. The machining department maximizes parts per hour. Assembly maximizes units completed. Paint maximizes throughput. None of these metrics has any relationship to system output.
Goldratt spent enormous effort on throughput accounting precisely because traditional cost accounting drives local optimisation. Throughput accounting measures throughput at the constraint, investment in inventory, and operating expenses. It does not reward a department for producing parts the constraint cannot absorb. Yet most organisations that adopt TOC never change their accounting system. They keep measuring labor utilization, machine utilization, and standard hours earned.
The result is an organisation paying its people to defeat the methodology. Operators and supervisors respond to what is measured and rewarded. If building excess inventory earns the same performance score as feeding the constraint at the right rate, the system will produce excess inventory. The TOC language creates the illusion of alignment while the measurement system drives every department in a different direction.
The real constraint is the set of policies, measurements, and beliefs that prevent you from managing the physical constraint.
Consultant Dependency and Hollow Thinking Processes
Many TOC implementations begin with an external expert. The consultant runs the Thinking Processes, identifies the constraint, facilitates a breakthrough, and departs. Within three to six months the implementation is dead. TOC was treated as a project with a beginning and an end, not as an operating discipline. There was no mechanism for sustaining the daily constraint review, no change to the measurement system, no training for the people who needed to carry the methodology forward.
The consultant-driven model creates the illusion of competence transfer. The consultant identifies the constraint; the team observes. The consultant designs the subordination plan; the team observes. When the constraint moves — as it inevitably does — there is no one in the organisation with the skill or authority to re-run the process. The team has observed everything but practiced nothing.
Goldratt's Thinking Processes — the Current Reality Tree, the Evaporating Cloud, the Future Reality Tree, the Prerequisite Tree, the Transition Tree — are rigorous analytical tools when used with discipline. Used poorly, which is most of the time, they produce diagrams that look impressive on a conference room wall and serve no practical purpose. The Current Reality Tree becomes a list of complaints arranged in boxes. The Evaporating Cloud becomes an exercise in justifying the existing conflict rather than challenging it.
This typically happens when the facilitator understands the mechanics but not the spirit — someone who can draw the diagrams but cannot push the team to surface the uncomfortable assumptions actually holding the system back. The result is a set of documents everyone agrees with and nobody acts on. The Thinking Processes require intellectual honesty, not just procedural compliance.
Consultant-Driven vs Embedded TOC
What teams do
- Constraint identified once during initial assessment
- Subordination plan designed externally, handed over
- Thinking Processes facilitated by someone who departs
- No mechanism to re-run the cycle when the constraint shifts
What works
- Constraint validated daily by internal schedulers and supervisors
- Subordination enforced through changed KPIs, not willpower
- Internal team trained to run Thinking Processes independently
- Plant manager owns the process and reviews it weekly
Building a Sustained TOC Discipline
Organisations that sustain TOC share a consistent set of characteristics. They have changed their measurement system: they measure throughput at the constraint, not utilization at every workstation. They reward subordination, not inventory creation. They have shifted from standard cost accounting to throughput accounting — or at minimum, to a hybrid system that does not actively punish the behaviours TOC requires.
They have built constraint management into their daily rhythm. Constraint identification is not an annual event. It is a daily, sometimes hourly, conversation. The scheduler knows where the constraint is. The operators know. The plant manager knows. When it moves, everyone adjusts — because the adjustment is procedural, not a crisis requiring a new consulting engagement.
They have invested in internal capability. Their people can run the Thinking Processes without an external facilitator. They can re-subordinate when the constraint moves. They have made TOC a capability rather than a dependency. And they are honest about failure: when subordination breaks down, they acknowledge it and fix it rather than writing optimistic progress reports while the shop floor quietly reverts to pushing inventory.
The physical constraint is usually easy to find and, with enough capital, relatively easy to elevate. The policy constraint — the utilization metric, the standard cost system, the department-level bonus structure — is far harder to change because it is embedded in the organisational structure and defended by the people who benefit from it. TOC is not a scheduling technique. It is an organisational change methodology that uses the physical constraint as a lever to expose and dismantle the policy constraints that actually limit your system.