The Theory of Constraints

In Lean Thinking, we explored how value moves through an organisation and how waste slows that movement.

The natural next question is:

Where should leaders focus first?

Most organisations try to improve everywhere at once. More tools. More initiatives. More optimisation. Effort increases, yet outcomes barely shift.

The Theory of Constraints, introduced by Eli Goldratt in The Goal, offers a different perspective:

Every system has a limiting factor. Improve that first. Optimising elsewhere is irrelevant.

For executives and CIOs, Theory of Constraints provides discipline. It prevents well-intentioned improvement work from becoming busywork.

Seeing the Organisation as a System

Theory of Constraints asks us to think of the organisation as a chain of connected activities. Requests come in. Work flows across teams. Value is delivered.

And somewhere along the way, one part of that chain moves slower than the rest.

That point becomes the constraint.

  • It limits throughput.
  • It drives delays.
  • It quietly increases cost and frustration.

Crucially, optimising anything other than the constraint does not improve the system. It might make someone’s area look better, but the organisation still moves at the speed of its slowest point.

This is where Theory of Constraints aligns beautifully with Lean: both care about flow, not activity.

A Simple Illustration

Imagine a process intended to deliver 100 units of value per day.

Each step has capacity:

  • Step A: 120
  • Step B: 50
  • Step C: 130
  • Step D: 80

The entire system can only produce 50, because Step B is the bottleneck.

Improving A, C, or D might make those teams more efficient. But nothing changes system output until Step B improves.

And once Step B is lifted to 100, the constraint naturally moves to Step D.

This is the point: constraints move. Improvement is not a project. It is ongoing leadership discipline.

Constraints Outside Manufacturing

It’s tempting to assume constraints belong on factory floors.

In knowledge work, they show up differently:

  • approval queues
  • overloaded product owners
  • under-resourced integration teams
  • specialist skills only a few people have
  • change governance processes that move slower than delivery

In technology functions, the constraint is often not the team people assume.

Sometimes it is:

  • vendor turnaround times
  • funding cycles
  • prioritisation processes
  • deployment pipelines
  • decision latency at leadership level

This is why Theory of Constraints matters at the executive level. Constraints are often systemic, not local.

The Five Focusing Steps

Goldratt provided a practical discipline known as the Five Focusing Steps — a loop, not a checklist.

1. Identify the Constraint

Where is value consistently slowing or piling up?

Look for:

  • queues
  • rework
  • delays in decision-making
  • constant escalation patterns

This step requires honesty. Many constraints are cultural or structural, not technical.

2. Exploit the Constraint

Ask: How do we make the most of the constraint we have?

This may involve:

  • reducing distractions
  • improving clarity
  • simplifying handoffs
  • eliminating low-value work that competes for the same capacity

Often, significant improvement comes without adding resources.

3. Subordinate Everything Else

Align the rest of the system around the constraint.

This means:

  • slowing non-essential work upstream
  • prioritising flow over local optimisation
  • resisting the urge to “keep everyone busy”

This step is uncomfortable. Productivity may appear to drop in some areas. But system throughput increases.

4. Elevate the Constraint

Only after exploiting and subordinating do we invest.

This might mean:

  • adding capability
  • outsourcing specific work
  • changing structures
  • automating repetitive tasks

Investment becomes targeted instead of scattered.

5. Repeat

Once the constraint moves, start again.

Improvement becomes continuous, not episodic.

Practical Examples

Example 1: Delivery teams constantly waiting on decisions

Teams are criticised for moving slowly. Backlogs are full. Projects stack up.

Closer inspection reveals that major decisions wait weeks for executive clarification.

The true constraint is not development capacity. It is decision latency.

Applying Theory of Constraints:

  • clarify decision ownership
  • shorten feedback loops
  • establish clear governance guardrails so fewer items need escalation

Delivery speed improves without hiring anyone.

Example 2: Support teams overwhelmed by recurring incidents

Support appears to be the constraint. Tickets increase. Response times stretch.

However, analysis shows many incidents originate from the same few root causes.

The true constraint is lack of time for upstream problem solving.

Applying Theory of Constraints:

  • carve dedicated improvement time
  • fix sources of recurring issues
  • reduce incident creation instead of chasing faster responses

Throughput improves because demand drops.

Where Theory of Constraints Fits in the Series

Design Thinking helps us choose the right problem.
Lean helps us improve flow.
The Toyota Way shapes leadership behaviour.

Theory of Constraints ensures improvement is aimed where it matters most.

It reminds leaders:

  • not every inefficiency is worth fixing
  • local optimisation can make system performance worse
  • the constraint deserves disproportionate attention

And above all:

If everything is a priority, nothing is.

For CIOs, Theory of Constraints offers a disciplined lens that prevents transformation efforts from drifting into activity for activity’s sake.

It focuses leadership energy on the point where change actually increases value.

Further Reading

Goldratt, E. (1984). The Goal.
Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project.
Goldratt, E., & Cox, J. (2004). The Theory of Constraints.