Theory Of Constraints
The Core Insight#
Every system has exactly one constraint at any given moment. Not several. Not many. One. This is the foundational insight of Eliyahu Goldratt’s Theory of Constraints, and understanding it changes how you think about improving anything.
The constraint is whatever limits the system’s output. In a manufacturing line, it might be the slowest machine. In a restaurant, it might be the number of tables. In a software team, it might be the time it takes to get code reviewed, or the availability of a particular person, or the speed of the deployment pipeline. Whatever it is, the constraint determines how fast the whole system can move.
Here’s what makes this powerful: improving anything other than the constraint produces no improvement to the system. None. You can optimize every other part of your process, make everyone else faster, invest in better tools for non-bottleneck activities, and throughput stays exactly the same. The work simply piles up in front of whatever is actually limiting flow.
Why Most Improvements Fail#
Teams try to improve everything at once. They adopt new practices, invest in training, upgrade their tools, restructure their processes. Each change feels productive in isolation. Yet when they measure actual output, nothing has changed.
The Theory of Constraints explains why. If your constraint is code review and you invest in faster CI pipelines, you’ve made a non-constraint faster. Code still waits for review at the same rate. If your constraint is a shared database administrator and you train developers on frontend frameworks, you’ve improved people who aren’t the bottleneck. Work still queues behind the DBA.
This isn’t intuitive. It feels like any improvement should help. But systems don’t work that way. A chain is only as strong as its weakest link, and strengthening the other links does nothing for the chain’s overall strength. The Theory of Constraints takes this observation and builds a methodology around it.
The location of an improvement relative to the constraint determines its effect. Improving something upstream of the constraint, something that feeds into the bottleneck, actually makes things worse. You’re producing more work faster, which piles up even higher in front of the constraint. Improving something downstream, something that consumes from the bottleneck, makes no difference at all. The downstream process was already waiting for work; making it faster just means it waits more efficiently. Only improvements to the constraint itself translate into improved system output.
Finding Your Constraint#
Identifying the constraint requires looking at where work accumulates. In physical systems, you can see inventory piling up in front of the slowest machine. In knowledge work, you look for queues: pull requests waiting for review, tickets waiting for a particular person, features waiting for deployment.
The constraint often isn’t what you expect. Teams assume their constraint is development capacity because developers always seem busy. But busyness isn’t the same as being a bottleneck. If code sits waiting for review for days while developers start new work, the constraint is review capacity, not development capacity. The developers are busy precisely because they keep starting things that can’t finish.
Sometimes the constraint is a policy rather than a resource. A change approval board that meets weekly becomes a constraint regardless of how fast everything else moves. A requirement that all work go through a particular architect creates a bottleneck even if that architect is brilliant. Constraints can be people, processes, policies, or tools.
The Five Focusing Steps#
Goldratt formalized the approach to constraints into five steps that form a continuous improvement cycle.
Identify the constraint. Find where work accumulates, where queues form, where the system actually limits. This requires honest observation rather than assumptions about where problems should be.
Exploit the constraint. Before adding resources or making changes, maximize what you already have. If code review is the constraint, ensure reviewers spend their time actually reviewing, not in meetings or context-switching. Get full value from the limiting resource before trying to expand it.
Subordinate everything else. Align the rest of the system to support the constraint. There’s no point in developers producing code faster than it can be reviewed. Slowing down non-constraint activities to match the constraint’s pace prevents work from piling up and actually improves flow.
Elevate the constraint. If exploitation and subordination aren’t enough, invest in expanding the constraint’s capacity. Add reviewers, automate parts of the process, change policies that create artificial bottlenecks. This step often requires resources or organizational change.
Repeat. Once you’ve addressed a constraint, a new one emerges. The slowest machine is no longer slowest, so now a different machine limits throughput. This is expected and healthy. Continuous improvement means continuously finding and addressing the current constraint.
Constraints in Software Teams#
The Theory of Constraints originated in manufacturing, but it applies directly to software development. The difference is that our constraints are often less visible than a pile of inventory on a factory floor.
Code review is a common constraint. Work moves quickly through development, then sits in pull requests for days. Developers respond by starting new work, which creates more pull requests, which makes the review queue longer. The solution isn’t to develop faster. It’s to either review faster or develop slower to match review capacity.
Deployment pipelines can be constraints when they’re slow or unreliable. If deploying takes hours and fails often, teams batch changes to deploy less frequently. This makes each deployment riskier and debugging harder. Improving the pipeline removes the constraint and enables smaller, safer deployments.
Key individuals become constraints when critical knowledge concentrates in one person. Every decision waits for their input. Every design needs their approval. The solution involves spreading knowledge through pairing, documentation, or accepting more distributed decision-making.
Product clarity can be a constraint when teams wait for decisions about what to build. Developers sit idle or start speculative work while requirements get debated. The solution might be smaller batches of well-defined work, empowering teams to make more decisions themselves, or restructuring how product direction gets communicated.
The Discipline of Focus#
The Theory of Constraints is ultimately about focus. Instead of trying to improve everything, you identify the one thing that matters most right now and put your energy there. Everything else can wait.
This requires discipline. It’s satisfying to improve things, and non-constraint improvements are often easier. But easy improvements that don’t move the needle are a form of productive procrastination. They feel like progress while the real bottleneck remains untouched.
The reward for this discipline is significant. Improvements to the actual constraint translate directly into improved system output. When you double the capacity of your bottleneck, you’ve doubled your throughput. No other improvement can make that claim.
The next time your team discusses process improvements, ask a simple question: is this the constraint? If not, the improvement might feel good, but it won’t change how much work actually gets done.