Theory of Constraints
Every system has exactly one binding constraint at any given time — one factor that limits overall throughput more than any other. Improving anything other than that constraint does not improve system performance. It may improve local efficiency while leaving overall output unchanged. Goldratt’s Theory of Constraints gives this observation a precise operational method: five focusing steps that direct all improvement energy at the one thing that actually matters.
☰ Contents
The core insight
Eliyahu Goldratt introduced the Theory of Constraints (TOC) in his 1984 novel The Goal, co-authored with Jeff Cox. The central argument is precise: every system — a factory, a hospital, a software company, a government department — is limited in achieving its goal by a small number of constraints. At any given time, one constraint is binding: it determines the maximum throughput of the entire system regardless of what happens everywhere else.
The managerial implication is equally precise: if you improve a non-constraint, you improve nothing. The throughput of the system is determined by its constraint. Improving a step that is not the bottleneck simply means that step produces output faster — which then piles up in front of the constraint. Work-in-progress increases. Lead times lengthen. The organisation is busier than ever and no more effective.
A chain is as strong as its weakest link. Strengthening any link other than the weakest does not increase the strength of the chain — it just means more links are now stronger than necessary. Identifying and strengthening the weakest link is the only action that matters. Once it is no longer the weakest, a new weakest link emerges — and that becomes the new focus. This is the entire theory in one image.
The five focusing steps
Goldratt’s operational method for applying TOC is a five-step cycle. The cycle repeats indefinitely because elevating a constraint creates a new constraint elsewhere — improvement is continuous, not terminal.
Identify the constraint
Find the one element that limits overall system throughput. Where does work pile up? Where is the queue longest? Where does everything else wait? In a service organisation, the constraint is often a person, a decision, or a system that everything must pass through. In manufacturing, it is the slowest machine or the highest-utilisation workstation.
Bootstrap CUSUM on the output measure helps here: a flat line means the system is constrained at a stable level. The constraint is the reason the line is flat rather than rising.
Exploit the constraint
Get maximum output from the constraint without spending money. Before investing in more capacity, ensure the constraint is not being wasted. Is the constraint idle for any part of the working day? Is it processing work that does not need to go through it? Is it being starved of input by upstream variability? Exploitation means making the most of what you already have.
In a knowledge work context: is the constrained person spending time on meetings, emails, and administrative work that could be handled by someone else? Every hour the constraint spends on non-constraint work is an hour of throughput permanently lost.
Subordinate everything else to the constraint
This is the hardest step and the one most often skipped. Every non-constraint in the system should operate at the pace of the constraint — not at its own maximum pace. Running non-constraints at full speed simply builds inventory in front of the constraint and creates the illusion of productivity.
In practice this means: the Goalie team handles all inbound work so the Builders are never interrupted. The support library handles repetitive queries so the constraint (developer time) is never consumed by failure demand. Every role in the system is subordinated to protecting the constraint’s productive time.
Elevate the constraint
If exploitation and subordination are not sufficient to meet demand, invest in expanding the constraint. Hire more people, add equipment, redesign the process to increase throughput at the bottleneck. Elevation is the step that requires resource commitment — which is why Steps 2 and 3 must come first. Elevating before exploiting wastes money. Elevating before subordinating means the new capacity is immediately consumed by the same inefficiencies that constrained the old capacity.
Repeat — do not let inertia become the constraint
When a constraint is elevated, it is no longer the bottleneck. A new constraint emerges somewhere else in the system. Return to Step 1 immediately. The most dangerous outcome of successfully elevating a constraint is declaring victory and stopping — because inertia and the policies built around the old constraint will then become the new binding limitation.
Throughput vs local efficiency
TOC introduces a precise accounting framework that conflicts directly with standard cost accounting. Standard cost accounting rewards local efficiency: every workstation should be busy, every person should be utilised, every resource should run at capacity. TOC argues this is exactly wrong.
Throughput is the rate at which the system generates money (or value) through sales. It is the only metric that matters for system performance.
Inventory (work-in-progress, queue length) is money tied up inside the system. High inventory is a symptom of a constraint downstream, not a sign of productivity upstream.
Operating expense is the cost of converting inventory into throughput.
The goal is to increase throughput while reducing inventory and operating expense. Local efficiency measures — utilisation rates, individual productivity metrics — can be maximised while throughput falls, because they measure activity at non-constraints rather than flow through the constraint. Deming’s Point 11 makes the same argument: eliminate numerical quotas that measure activity rather than results.
Types of constraint
Constraints are not always physical bottlenecks. Goldratt identified several categories:
- Physical constraint: A machine, a person, a space, a piece of equipment whose capacity limits throughput. The most visible type.
- Policy constraint: A rule, procedure, or habit that prevents the system from operating at its potential. Often harder to see than physical constraints because policies feel like good management. A rule that requires every customer request to be handled individually rather than batched is a policy constraint. A requirement that only the most senior person can approve a decision is a policy constraint.
- Market constraint: Demand is lower than the system’s capacity. The constraint is external — not enough customers or orders. The correct response is to increase demand (marketing, new markets, new products) rather than improve internal efficiency.
- Knowledge constraint: The system lacks the information or skill to proceed. Common in knowledge work organisations — the constraint is not capacity but expertise or understanding.
In professional services, software companies, healthcare teams, and policy organisations, the constraint is almost always a policy constraint masquerading as a capacity problem. The senior person is overloaded — but the reason they are overloaded is a policy (implicit or explicit) that everything significant must go through them. The fix is not to make that person work harder. It is to change the policy: define what can be handled without them, build the systems that enable others to handle it, and protect their time for the work that only they can do.
In practice
The worked example from the 7-step improvement method illustrates TOC directly. A specialist software company has a growth constraint: new work is replacing losses but not exceeding them. The constraint analysis finds that everything routes through the same expert people — the Boss for sales, the developers for both support and new product work.
Applying the five steps:
- Identify: Developer time is the constraint. Support calls, implementation queries, and new product development all compete for the same resource. Support and implementation win because they are urgent. New product development loses because it is important but not urgent.
- Exploit: Reduce the waste of constraint time. Scripted restart procedures handle the 172 most common support cases without developer involvement. A help library allows customers to self-serve. Each script and library article returns hours of developer time without adding headcount.
- Subordinate: Goalies handle all inbound contact. Builders (developers) never answer a support call. The Investigator owns the learning loop — analysing support patterns, directing the library, escalating only what genuinely requires developer expertise. Every role is designed around protecting the constraint.
- Elevate: Once exploitation and subordination are in place, the Toolmaker role adds development capacity ring-fenced from operational work. Elevation only after Steps 2 and 3.
- Repeat: Once developer capacity is freed, the new constraint becomes sales — the Boss is the only sales channel. The Blueprint product and the Investigator are the response to that next constraint.
Bootstrap CUSUM and the constraint
📊 How Bootstrap CUSUM locates the constraint in data
A flat Bootstrap CUSUM line on the outcome measure is the signature of an unaddressed constraint. If new contract value has been flat for three years despite multiple improvement initiatives, the constraint has not been addressed. Each initiative improved a non-constraint — it created local efficiency while leaving the bottleneck unchanged.
A Bootstrap CUSUM upward change point on the outcome measure confirms that the constraint was elevated. When the right intervention was made — exploiting, subordinating, and elevating the actual constraint — throughput increased and a change point appeared in the outcome series. The date of the change point should coincide with the intervention that addressed the constraint, not with earlier interventions that addressed non-constraints.
Bootstrap CUSUM on component measures identifies where the constraint is. If support cases fall (change point down) at the same time as new contract value rises (change point up), that confirms that reducing failure demand on the constraint released the capacity that produced the growth. The two change points together are the evidence of the mechanism.
See Three Charts, Three Stories for how Bootstrap CUSUM makes these structural shifts visible in ways that conventional averages and trend lines cannot.
This concept connects directly to Step 4 of the 7-step improvement method. See Why Nothing Changes for the broader diagnostic framework, or Necessary But Not Sufficient for Goldratt’s related logical framework.