Constraints That Govern Systems
Your team launches a major optimization initiative: faster servers, improved algorithms, streamlined processes. Six months later, overall system throughput increases 5%. Disappointing. The bottleneck wasn't compute power or code efficiency—it was the single database that every service queries. You optimized everything except the one constraint that actually limited performance.
This is the fundamental truth about systems: every system has constraints that govern what it can do, and improving non-constraints is largely wasted effort. The binding constraint—the bottleneck, the limiting factor, the scarce resource—determines system capacity. Everything else is secondary.
Understanding constraints transforms how you improve systems. Instead of optimizing randomly or uniformly, you identify what actually limits performance and focus there. This principle applies far beyond technology: manufacturing, organizations, personal productivity, even ecosystems operate under constraints that shape their behavior and determine their limits.
This article explores what constraints are, why they matter profoundly, how to identify binding constraints, and how to work with rather than against them.
What Are Constraints?
Definition
Constraint: A limit that governs what a system can do—a bottleneck, resource limit, physical law, or rule that bounds behavior and capacity.
Types of Constraints
| Type | Description | Examples |
|---|---|---|
| Physical | Laws of nature, material limits | Speed of light, thermodynamic efficiency, material strength |
| Resource | Scarcity of inputs | Time, money, people, materials, energy |
| Capacity | Throughput limits | Production line speed, network bandwidth, processing power |
| Policy | Rules and regulations | Laws, organizational policies, standards, procedures |
| Paradigmatic | Mental models, assumptions | "We've always done it this way," unquestioned beliefs |
Binding vs. Non-Binding Constraints
Binding constraint (bottleneck):
- Currently limits system performance
- Determines total capacity
- Improvement here increases overall output
Non-binding constraint:
- Has capacity to spare
- Not currently limiting performance
- Improvement here doesn't affect overall output
Key insight: At any moment, only one (or few) constraints are truly binding. Everything else has slack.
Example: Highway traffic
Components:
- 3-lane highway for 50 miles
- Narrows to 1 lane at bridge
- Returns to 3 lanes after bridge
Binding constraint: The 1-lane bridge
Non-binding: The 3-lane sections (have excess capacity)
Optimization implications:
- Widening 3-lane sections: No effect on throughput
- Widening bridge: Directly increases throughput
- Adding more lanes before bridge: Makes congestion worse (more cars arrive at bottleneck faster)
Why Constraints Matter
Reason 1: The Constraint Determines System Capacity
System capacity = capacity of binding constraint
Everything else is irrelevant to total throughput.
Example: Manufacturing line
| Station | Capacity (units/hour) | Type |
|---|---|---|
| Cutting | 100 | Non-binding |
| Assembly | 60 | BINDING |
| Quality check | 80 | Non-binding |
| Packaging | 90 | Non-binding |
System capacity: 60 units/hour (limited by assembly)
Improving cutting to 150/hour: No effect (assembly still bottleneck)
Improving assembly to 80/hour: System now produces 80/hour (but quality check becomes new bottleneck)
Reason 2: Optimizing Non-Constraints Wastes Resources
Improvement effort = time, money, attention
Improving non-binding constraints:
- Consumes resources
- Doesn't increase system performance
- May make things worse (by increasing pressure on bottleneck)
Example: Sales and fulfillment
System:
- Sales team can generate 100 leads/month
- Fulfillment can handle 50 customers/month
Binding constraint: Fulfillment capacity
What happens if you optimize sales (non-binding):
- Hire more salespeople → 200 leads/month
- Fulfillment still handles only 50
- Result: 150 disappointed customers, damaged reputation, wasted sales effort
Right approach: Optimize fulfillment first (binding constraint)
Reason 3: Constraints Shift
Fix one constraint, another becomes binding.
System optimization is continuous constraint identification and relief.
Example: Website performance
Initial state:
- Slow database queries (bottleneck)
- Fast application code
- Adequate bandwidth
Optimize database:
- Database now fast
- Application code becomes bottleneck
- Bandwidth still adequate
Optimize application:
- Database fast, application fast
- Bandwidth becomes bottleneck
Each improvement shifts the binding constraint.
Reason 4: Constraints Focus Effort
Benefit: Constraints force prioritization.
Without constraint awareness:
- Optimize randomly
- Spread effort thin
- Incremental improvements everywhere, little system-level gain
With constraint awareness:
- Identify bottleneck
- Focus resources there
- Dramatic system-level improvement
Theory of Constraints (TOC)
Core Concepts
Developed by: Eliyahu Goldratt (The Goal, 1984)
Central premise: Every system has at least one constraint limiting throughput. System performance improves only by addressing constraints.
The Five Focusing Steps
1. IDENTIFY the constraint
- Find the bottleneck
- What limits system throughput?
2. EXPLOIT the constraint
- Get maximum output from existing constraint
- Eliminate waste, optimize utilization
- No capital investment yet
3. SUBORDINATE everything else
- Adjust rest of system to support constraint
- Don't overproduce (feeds inventory, not throughput)
- Match pace of bottleneck
4. ELEVATE the constraint
- If exploitation insufficient, add capacity
- Invest to expand constraint
- May require capital, hiring, redesign
5. REPEAT
- Constraint shifts after elevation
- Return to step 1 with new constraint
- Continuous improvement cycle
Example: Restaurant
Step 1: Identify
- Kitchen can prepare 50 meals/hour
- Seating capacity: 100 people (turns over every 1.5 hours = ~66 meals/hour capacity)
- Wait staff can serve 80 meals/hour
Binding constraint: Kitchen (50 meals/hour)
Step 2: Exploit
- Streamline kitchen workflow
- Prep ingredients in advance
- Optimize equipment layout
- Result: Kitchen now handles 60 meals/hour
- No capital required, just process improvement
Step 3: Subordinate
- Don't seat more customers than kitchen can handle (creates bad experience)
- Coordinate front-of-house with kitchen pace
- Adjust reservations to match kitchen capacity
Step 4: Elevate
- Kitchen still bottleneck after exploitation
- Invest: Add oven, hire cook, expand prep area
- Result: Kitchen capacity 80 meals/hour
New constraint: Seating (66 meals/hour)
Step 5: Repeat
- Now optimize seating (faster table turns, add tables)
- Continuous improvement
Identifying Binding Constraints
Method 1: Follow the Work
Track where work queues up.
Symptoms of bottleneck:
- Work piles up before this step
- Step is always busy (utilization ~100%)
- Work flows quickly after this step
- Delays originate here
Example: Software deployment pipeline
| Stage | Duration | Queue |
|---|---|---|
| Code review | 30 min | 2-3 PRs waiting |
| Automated tests | 15 min | No queue |
| Manual QA | 3 hours | 10+ items waiting |
| Deployment | 10 min | No queue |
Bottleneck: Manual QA (long duration, large queue)
Method 2: Measure Throughput at Each Stage
Identify where throughput drops.
Process:
- Measure capacity at each step
- Find lowest capacity
- That's your constraint
Method 3: The Increment Test
Ask: "If we improved this component, would system performance increase?"
If yes: Likely a binding constraint If no: Non-binding
Example: Customer support
Current state:
- 10 support agents
- Average handle 30 tickets/day each
- Total: 300 tickets/day
- Incoming tickets: 250/day
Test: Add 5 agents
- Would throughput increase?
- No—only 250 tickets/day to handle
- Constraint is not agent capacity (they have slack)
Actually constraint: Ticket volume (limited by incoming demand)
Method 4: Analyze Utilization
High utilization (90-100%) → Likely bottleneck Low utilization (50-70%) → Probably not constraint
Caution: High utilization doesn't prove bottleneck, but low utilization rules it out.
Working with Constraints
Strategy 1: Accept Unchangeable Constraints
Some constraints are physical laws or immutable facts.
Examples:
- Speed of light (physics)
- 24 hours in day (time)
- Laws of thermodynamics
- Human cognitive limits
Response: Work creatively within the constraint, don't fight it.
Example: Physical distance
Constraint: Speed of light limits communication to distant servers (~100ms round-trip cross-continent)
Can't change: Physics is physics
Work with it:
- Cache data closer to users
- Design for asynchronous communication
- Regional data centers
- Optimistic UI (assume success, sync later)
Strategy 2: Challenge Assumptions About Fixedness
Many "unchangeable" constraints are actually policy or paradigm constraints.
Question: "Is this really fixed, or do we just assume it is?"
Example: "We need approval from all stakeholders"
Assumed constraint: Unanimous approval required
Challenge: Why? What's the actual rule?
Discovered: Policy says "relevant stakeholders," not "all stakeholders"
Result: Faster decisions, constraint was paradigmatic not actual
Strategy 3: Exploit Before Elevate
Get maximum from existing constraint before adding capacity.
Why:
- Exploitation is usually cheaper
- Often reveals constraint wasn't what you thought
- Teaches you about the system
How to exploit:
- Eliminate waste in constraint process
- Increase utilization (reduce downtime)
- Improve quality (reduce rework)
- Streamline workflow
Example: Meeting room shortage
Constraint: Only 3 meeting rooms, high demand
Exploit before elevate:
- Cancel unnecessary meetings (reduce demand)
- Shorten meeting times (increase turnover)
- Better scheduling (reduce gaps)
- Remote option for some meetings
Result: May not need to build new rooms (elevation)
Strategy 4: Subordinate Non-Constraints to Constraints
Adjust rest of system to support bottleneck.
Common mistake: Overproducing in non-constraints
Example: Software features and QA
Constraint: QA capacity (can thoroughly test 5 features/month)
Development: Can build 15 features/month
Mistake: Build all 15 features
- Queue of 10 untested features grows
- Rushed testing to clear backlog
- Quality suffers
Subordinate development to QA:
- Build 5 features/month (match QA pace)
- Use remaining capacity for refactoring, tech debt
- Maintain quality, no inventory buildup
Strategy 5: Use Constraints as Creative Force
Constraints can improve solutions by forcing creativity.
Unlimited resources → lazy solutions Tight constraints → creative innovations
Example: Twitter's 140-character limit (original)
Constraint: SMS technology (160 char limit, left 20 for username)
Result:
- Forced brevity
- Created distinctive style
- Made platform unique
- Became defining feature
Constraint drove creativity and differentiation.
Example: Apollo 13 CO2 scrubber
Constraint: Square scrubbers, round holes, limited materials on spacecraft
Under unlimited resources: Design perfect new system
Under tight constraint: Creative solution using only available materials (duct tape, plastic bags, cardboard)
Constraint forced innovation that solved problem.
Constraints in Different Domains
Manufacturing
Common constraints:
- Bottleneck machine or process
- Skilled labor shortage
- Material availability
- Storage capacity
TOC application:
- Identify bottleneck machine
- Maximize utilization (reduce setup time, eliminate downtime)
- Schedule production to bottleneck pace
- Invest to expand bottleneck capacity if needed
Software Development
Common constraints:
- Deployment pipeline capacity
- Code review availability
- Testing resources
- Database performance
- Key person dependencies ("only Jane knows this system")
Example: Continuous deployment constraint
Constraint: Manual approvals slow deployment
Exploit: Batch approvals, simplify approval process
Elevate: Automate approvals for low-risk changes
Result: Deployment frequency increases 10x
Organizations
Common constraints:
- Decision-making bottlenecks
- Key skill shortages
- Communication breakdowns
- Budget limitations
- Regulatory requirements
Example: Hiring process
Constraint: Final approval takes 2-3 weeks (CEO must approve all hires)
Exploit: Batch approvals, streamline paperwork
Elevate: Delegate approval for certain roles/levels
Result: Faster hiring, reduced candidate loss
Personal Productivity
Common constraints:
- Time (fixed 24 hours/day)
- Energy (finite cognitive resources)
- Attention (limited focus capacity)
- Key skills (lacking expertise in critical area)
Example: Time management
Constraint: Deep work capacity (~4 focused hours/day)
Response:
- Don't try to increase deep work to 12 hours (impossible)
- Protect the 4 hours ruthlessly (exploit)
- Schedule most important work during peak hours
- Batch meetings and shallow work outside deep work time
Ecosystems
Common constraints:
- Limiting nutrient (nitrogen, phosphorus)
- Water availability
- Sunlight
- Space/territory
Liebig's Law of the Minimum: Growth limited by scarcest resource
Example: Ocean productivity
In many oceans: Iron is constraint
- Plenty of nitrogen, phosphorus, sunlight
- Tiny amounts of iron limit phytoplankton growth
Adding iron → Algae bloom (constraint relieved) Adding nitrogen → No effect (not constraint)
Common Mistakes
Mistake 1: Optimizing Everything Equally
Problem: Spreading effort across all components
Result:
- Incremental improvements everywhere
- Little system-level gain
- Wasted resources on non-constraints
Fix: Focus 80% of effort on binding constraint
Mistake 2: Not Recognizing Constraint Shifts
Problem: Fix bottleneck, assume system now unconstrained
Result:
- New bottleneck emerges
- System capacity doesn't increase as expected
- Confusion about why improvements didn't work
Fix: After relieving constraint, immediately identify new one
Mistake 3: Local Optimization Degrades Global Performance
Problem: Optimize component without considering system
Example:
- Increase sales (local optimization)
- Overwhelm fulfillment (system bottleneck)
- Result: Worse customer experience, lower retention
Fix: Subordinate local optimization to system constraints
Mistake 4: Assuming Constraint Is Fixed
Problem: Accept constraint as unchangeable without challenging
Result: Miss opportunities to elevate constraint
Fix: Always question: "Is this really fixed?"
Mistake 5: Elevating Before Exploiting
Problem: Immediately invest in expanding constraint
Result:
- Expensive
- May not be necessary
- Miss learning opportunities
Fix: Exploit first (often sufficient and cheaper)
Beneficial Constraints
Constraints as Design Tools
Tight constraints can improve outcomes:
1. Force prioritization
- Can't do everything → Must choose what matters
2. Drive creativity
- Easy solutions eliminated → Novel approaches emerge
3. Provide focus
- Clear limitation → Direction becomes obvious
4. Enable completion
- Unlimited time → Project drags on
- Tight deadline → Forces decisions, ships product
Example: Haiku poetry
Constraints:
- 17 syllables (5-7-5)
- Seasonal reference
- Present-tense observation
Result:
- Forces precision
- Every word matters
- Constraint creates art form
Example: Startups vs. Large companies
Startups:
- Severe resource constraints (time, money, people)
- Forces focus, speed, creativity
- Must prioritize ruthlessly
Large companies:
- Abundant resources
- Often lack focus, move slowly
- Can pursue many mediocre initiatives
Paradox: Constraint often enables better outcomes.
Conclusion: Find and Focus on the Constraint
Core insights:
1. Every system has constraints
- At least one factor limits performance
- Usually one binding constraint at any time
- Others have slack capacity
2. The constraint determines capacity
- System throughput = constraint throughput
- Everything else is secondary
3. Optimization must target constraints
- Improving non-constraints wastes effort
- Focus on bottleneck for system improvement
4. Constraints shift
- Relieve one, another becomes binding
- Optimization is continuous process
- Regular re-identification required
5. Work with constraints, not against them
- Accept unchangeable constraints, design around them
- Challenge assumed constraints
- Exploit before elevate
- Use constraints as creative force
The path forward:
Step 1: Identify your binding constraint
- Where does work queue up?
- What has highest utilization?
- What limits throughput?
Step 2: Exploit it
- Eliminate waste in constraint
- Maximize utilization
- Improve quality and speed
Step 3: Subordinate everything else
- Match pace of constraint
- Don't overproduce
- Support the bottleneck
Step 4: Elevate if needed
- Invest to expand capacity
- Only after exploitation exhausted
Step 5: Repeat
- Constraint has shifted
- Start over with new constraint
Remember:
- Don't optimize blindly (target the constraint)
- Don't optimize everything (focus on bottleneck)
- Don't assume constraints are fixed (challenge them)
- Don't forget constraints shift (continuous process)
The constraint governs the system. Find it. Focus on it. Everything else is distraction.
References
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
Goldratt, E. M. (1990). Theory of Constraints. North River Press.
Cox, J. F., & Schleier, J. G. (2010). Theory of Constraints Handbook. McGraw-Hill.
Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
Deming, W. E. (1986). Out of the Crisis. MIT Press.
Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
Womack, J. P., & Jones, D. T. (1996). Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Simon & Schuster.
Little, J. D. C. (1961). "A Proof for the Queuing Formula: L = λW." Operations Research, 9(3), 383–387.
Hopp, W. J., & Spearman, M. L. (2011). Factory Physics (3rd ed.). Waveland Press.
Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
Simon, H. A. (1996). The Sciences of the Artificial (3rd ed.). MIT Press.
Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.
Senge, P. M. (1990). The Fifth Discipline: The Art & Practice of The Learning Organization. Doubleday.
Sterman, J. D. (2000). Business Dynamics: Systems Thinking and Modeling for a Complex World. McGraw-Hill.
Liebig, J. von (1840). Organic Chemistry in Its Application to Agriculture and Physiology. Taylor and Walton.
About This Series: This article is part of a larger exploration of principles and laws. For related concepts, see [Tradeoffs: The Universal Law], [First-Order vs Second-Order Effects], [Universal Principles Across Domains], and [Economic Laws Explained Simply].