The Theory of Constraints is deceptively simple: find the bottleneck, fix the bottleneck, repeat. Millions have read The Goal. The Five Focusing Steps fit on a single page. Yet after 40 years, sustained TOC success stories in manufacturing remain surprisingly rare.
The problem isn't Step 1 (Identify) or Step 2 (Exploit). Most practitioners can find their constraint and squeeze more from it. The problem is Step 3: Subordinate, and it's where the majority of TOC implementations quietly fail.
What Subordination Actually Means
Subordination is the requirement that every non-constraint resource aligns its behaviour to serve the constraint's needs, even when this makes those resources appear inefficient by traditional measures.
Your constraint sets the pace for the entire system. Everything else must dance to its rhythm, not their own.
The car analogy: If your engine (constraint) has a maximum speed of 120 mph, your tyres, suspension, and brakes must adequately support that speed. Adequate means margin for variation: brakes rated for 150 mph, not exactly 120 mph. But not 500 mph either. That's overengineering. Same in manufacturing: non-constraints need 15-30% overcapacity to absorb variation, not infinite spare capacity.
In practical manufacturing terms, subordination means:
| Resource Position | Subordination Requirement |
|---|---|
| Upstream processes | Maintain a buffer before the constraint so it's never starved, but don't overproduce and flood the system with WIP |
| Downstream processes | Maintain a buffer after the constraint and sprint capacity to clear it, so the constraint is never blocked waiting for space |
| Maintenance | Prioritise constraint availability above all other equipment |
| Quality | Inspect before the constraint (never waste constraint time on defective inputs) AND protect quality after the constraint (post-constraint scrap is direct throughput loss because the constraint time is already spent) |
| Scheduling | Minimise changeovers at the constraint; accept more changeovers elsewhere |
The Counterintuitive Part
Subordination gets difficult because it often requires accepting lower efficiency at non-constraints.
Example
Your filling line (constraint) runs at 100 units/hour. Your case packer (downstream) can run at 150 units/hour but has 90% availability.
You need a buffer between filling and case packing. When case packing goes down, that buffer absorbs the constraint's output, preventing the constraint from blocking.
You want this buffer empty. Run case packing as fast as possible to clear it. Empty buffer = maximum space to absorb constraint output if case packing goes down. That's maximum protection.
When case packing comes back up after a stoppage, it sprints at 150 units/hour to clear the accumulated WIP, then continues at full speed to keep the buffer empty.
The acceptable idleness: When case packing has cleared the buffer, it waits. The constraint isn't blocked; there's just nothing queued yet. This visible idleness is fine.
The common mistake: People slow downstream equipment to "match the constraint" so operators aren't visibly idle. But this removes the sprint capacity. When downstream eventually has a stoppage and needs to clear the buffer quickly, it can't. The capability has been engineered out in pursuit of looking busy.
Upstream buffer: keep it full. Downstream buffer: keep it empty. Both need sprint capacity.
The mathematics matters. In TOC, the value of time at different resources differs fundamentally:
Constraint time value: Vconstraint = Rc × M
Where Rc is throughput rate and M is contribution margin per unit.
Non-constraint time value: Vnon-constraint = 0 (direct)
Marginal recovery of time at a non-constraint has zero direct throughput value. Its indirect value exists only via protection of the constraint.
Post-constraint quality losses: Scrap after the constraint is valued at the full constraint rate. The constraint time is already spent, so you can't recover it. This is why quality protection downstream of the constraint is as critical as quality inspection upstream.
This isn't theoretical handwaving. If your constraint generates £600/hour in contribution margin, and non-constraint labour costs £20/hour, you should accept up to 30 person-hours of non-constraint idleness to prevent one hour of constraint starvation. The maths is unambiguous.
Why Subordination Fails
If the logic is sound, why do implementations fail? Because subordination requires behavioural and cultural change that conflicts with decades of industrial conditioning:
1. Efficiency Metrics at Non-Constraints
Most factories measure OEE or utilisation at every work centre. Supervisors are rewarded for hitting targets. Telling someone their efficiency target no longer applies because they're "just a non-constraint" is a hard conversation, and often doesn't happen.
2. The Busy = Good Fallacy
Seeing idle operators feels wrong. It triggers intervention from management. The emotional difficulty of watching people wait, while knowing you're paying them, undermines the discipline.
The common response: slow equipment down so operators aren't visibly idle. This feels like a compromise, matching speeds, staying busy, looking efficient. But it's a trap. You've just removed the sprint capacity needed to recover from stoppages. When downstream equipment goes down and you need to clear the buffer quickly, you can't. The constraint blocks. Throughput is lost.
Accept the idleness. Protect the sprint capacity.
3. Lack of Clear Rules
"Support the constraint" is abstract. Operators need concrete rules: When do I start? When do I stop? How much buffer is enough? How do I know if I'm blocking or starving the constraint? Without this operational detail, subordination remains a management concept rather than shop floor reality.
4. Local vs System Optimisation
Each department optimises its own metrics. Procurement buys in large batches (better unit cost). Production runs long campaigns (fewer changeovers). Warehouse ships in full pallets (transport efficiency). Each decision is locally rational but may harm constraint throughput.
Making Subordination Work
Successful subordination requires a two-pronged approach: focus on the constraint and disciplined support from everything else. Neither alone is sufficient.
Drum-Buffer-Rope (DBR)
DBR operationalises subordination through three mechanisms:
- Drum: The constraint sets the pace. All scheduling works backwards from constraint capacity
- Buffer: Time buffers (not quantity buffers) protect against upstream variation. Size them to cover the majority of credible variation, typically the 90th-95th percentile of historical lead times.
- Rope: Material release is tied to constraint consumption. Work enters the system only when the constraint can process it
Clear Operational Rules
Convert abstract principles into specific behaviours:
Example rules for a packaging line:
Upstream (before filler constraint):
• Buffer target: 2 hours of WIP before the filler (sized to cover credible upstream breakdown duration)
• If buffer below target: upstream runs at maximum speed until recovered
• If buffer at target: upstream matches constraint pace
Downstream (after filler constraint):
• Buffer target: empty. Run case packing at full speed to clear WIP
• If buffer accumulates: case packing sprints to clear it
• If buffer empty: case packing waits. This is fine, the constraint isn't blocked
Constraint:
• Filler changeovers: maximum 2 per shift; other equipment absorbs variety
Revised Metrics
Remove efficiency targets from non-constraints. Replace with:
- Buffer health: Is the constraint buffer within target range?
- Response time: How quickly can non-constraints recover from disturbances?
- Constraint availability: Was the constraint ever starved or blocked due to non-constraint failures?
Sprint Capacity
Non-constraints, both upstream and downstream, should have 15-30% overcapacity. Not as waste, but as variation insurance:
- Upstream: When upstream processes have problems, sprint capacity allows rapid recovery before the constraint buffer depletes
- Downstream: When downstream processes have problems, sprint capacity allows them to clear accumulated WIP and prevent constraint blocking
This excess capacity has positive economic value despite appearing "inefficient." The alternative, a balanced plant where every process runs at exactly demand rate, has no margin for variation and systematically underperforms.
The Mathematical Justification
For those wanting rigour: the case for unbalanced capacity (and therefore subordination) comes from queueing theory. When sequential processes are dependent and each exhibits random variation, system variance exceeds the sum of individual variances due to positive covariance:
Delays at one process create correlated delays downstream. This covariance is created by blocking and starving interactions: when Process A slows, Process B waits; when B blocks, A stops. A balanced system (capacity = demand everywhere) has no margin for this variation. Systematic underperformance is mathematically guaranteed.
Excess capacity at non-constraints breaks this pattern. Buffers and sprint capacity reduce covariance by absorbing variation before it propagates. The constraint sees stable input flow. System throughput is protected.
The Two-Pronged Focus
The original insight from LinkedIn is correct: successful TOC requires equal attention to both:
Focus on the Constraint
Identify it accurately. Exploit every minute. Elevate when necessary. Measure ruthlessly.
Focus on Subordination
Clear rules. Revised metrics. Buffer management. Deliberate overcapacity. Cultural change.
Most implementations emphasise the first and neglect the second. They find the constraint, improve it, then watch gains evaporate as unsupportive non-constraints starve, block, or destabilise it.
Subordination isn't glamorous. It doesn't feature in case studies. It requires telling people their efficiency targets don't matter, accepting visible idleness, and maintaining discipline when every instinct says "keep the machines running."
But without it, constraint focus is incomplete. The Achilles heel remains exposed. And TOC implementations continue to fail, not from bad theory, but from incomplete execution.
The devil lies in details, including for TOC implementation on the shop floor. Get subordination right, and the Five Focusing Steps work as designed. Get it wrong, and you're just another organisation that read The Goal but couldn't make it stick.
