Theory of Constraints

Faster development didn't make delivery faster

A software team gives its developers better tools and they finish changes much faster. Review capacity stays the same.

Completed work begins piling up. The reviewer switches between more changes, feedback arrives later, developers have to reload old context, and defects become harder to spot. The release side is still waiting for approved work while the reviewer becomes exhausted.

Developers finished more changes, but the same number reached customers. The rest waited for review, so work in progress grew, feedback arrived later and the team had more half-finished work to manage.

Find the stage that governs the whole flow

The Theory of Constraints says the amount a system can deliver is limited by its tightest point. When work must pass through several stages, the slowest required stage decides how much can finish. That limiting point might be a machine, one person, a policy, rare expertise, a decision only one leader can make, a supplier or even too few customers.

Making another part faster usually will not increase delivery while the same hold-up remains. It may still improve quality or cost, or prepare for the hold-up to move. To deliver more overall, more useful work needs to get through the limiting stage, or less work needs to pass through it.

Work through the constraint in order

Work through it in this order:

1. Identify the constraint. Find where work waits, where demand exceeds capacity, or which condition currently caps the goal.
2. Use the constraint well. Protect it from avoidable interruptions, bad inputs and work that doesn't need its scarce capability.
3. Match the rest to it. Let earlier stages send only what the limiting stage can handle, and organise the other stages to keep it working well.
4. Increase what it can handle. Add capacity, change the design, share the knowledge or remove the limiting rule when the earlier moves are not enough.
5. Repeat. Once one constraint improves, another part of the system becomes limiting.

Using the constraint well does not mean asking one exhausted person to work longer. If every decision waits for one senior reviewer, the better move may be clearer rules, smaller review scopes, delegated authority and sharing the knowledge only that person has.

How the constraint appears elsewhere

Manufacturing and operations. If one furnace can process 100 units an hour, making the cutter before it produce 180 instead of 140 only piles up more stock before the furnace. Keeping every station busy can make waiting and storage worse. The whole line improves when the furnace loses less time, gets the right work and is protected from avoidable stops.

Biology. Liebig’s law of the minimum says a plant grows only as far as its scarcest needed nutrient allows, not according to the total amount of nutrients around it. Adding more of something the plant already has enough of does little while another needed input is missing and may even damage the soil. Living things can adapt and several limits can interact, so the comparison has limits too.

Software systems. A request may pass through an interface, a waiting line, a database and a service run by another company. The slowest required part sets the pace. Bigger waiting lines only hide the problem for longer. Repeating failed requests can make it worse by sending more work to the same busy part. The limiting part can change with traffic or data, so look where requests are actually waiting instead of blaming the same service every time.

Organisational design. A company may appear short of engineers while the real constraint is that priorities, designs or releases all wait for the same executive decision. Starting more projects keeps more people busy and creates more work requiring that scarce attention. People wait for permission, decisions lose context, and the person at the centre carries a growing queue nobody else can resolve.

Find the real constraint before adding capacity

Use this model when everyone is busy but output stays flat, waiting time is much longer than working time, new capacity fails to improve delivery, or the same person and queue appear in unrelated delays.

Look for:

• The oldest work in the system
• A stage with a persistent queue before it and spare capacity after it
• Work that repeatedly waits for one permission, skill or dependency
• A resource protected by everyone because losing an hour there loses an hour for the whole system
• A policy that creates a limit even when physical capacity is available

Stop sending work into the queue faster just to keep the people before it busy. Protect the limiting stage, reduce the work that truly needs it and check whether the whole system now delivers more. If that queue disappears and another grows elsewhere, the limit has moved.

When there's more than one limit

Real systems can have several constraints that shift with time, customer type or failure mode. Variability also matters: a stage with enough average capacity may still create long queues when arrivals are uneven. In creative work, treating people as interchangeable processing stations ignores learning, motivation and the value of exploration.

The model is most dangerous when “the person is the bottleneck” becomes permission to extract more from an exhausted person. First check whether too much authority sits with them, inputs arrive in poor shape or knowledge has never been shared. Asking them to work longer treats the symptom as the solution.

Requisite Variety asks whether the system has enough possible responses for the situations it faces. The Theory of Constraints asks what currently limits progress. Braess's Paradox is different again: adding a route can make a network worse because people change how they use it.