Theory of Constraints in Software Operations

Identifying and Optimising Bottlenecks

Why the Slowest Part of Your Delivery System Controls Everything

Software organisations love optimisation.

We optimise sprint ceremonies, backlog refinement, deployment pipelines. We optimise the colour of the Jira workflow until it looks like someone tipped a box of Quality Street into Azure DevOps.

Howver, the uncomfortable lesson from the Theory of Constraints is this:

Improving the wrong part of the system improve nothings.

That is the central idea behind Eliyahu M. Goldratt’s Theory of Constraints, first popularised through The Goal. In manufacturing, the constraint might be a slow machine, a shortage of material, or a production line that can only process a certain number of units per hour.

In software operations, the constraint is rarely a machine. It is usually something more awkward. A person, a queue, a review process, a customer who only signs things off once every lunar cycle.

The Theory of Constraints matters because it gives software teams a simple but brutal question:

Where is the one place where improving flow would improve the whole system?

Not the place that is loudest, not the place with the most senior stakeholder, the actual constraint.

What Is the Theory of Constraints?

The Theory of Constraints says that every system has at least one limiting factor that constrains its performance. To improve you should

Identify the system’s constraint.
Exploit the constraint.
Subordinate everything else to the constraint.
Elevate the constraint.
Repeat when the constraint moves.

In plain English:

Find the bottleneck, get the most out of it, stop feeding it unnecessary work, invest in improving it. Then look again, because the bottleneck will move.

That last point is critical. Constraints are not solved forever. They migrate.

Fix testing and deployment becomes the constraint. Fix deployment and product discovery becomes the constraint.

Software delivery is basically a game of “Where’s Wally?”, except Wally is a bottleneck and he is quietly ruining your lead time.

The Software Operations Version of TOC

In software operations, the goal is not simply “keep engineers busy”. That is local optimisation.The goal is usually something closer to:

Deliver valuable, reliable software changes safely and predictably.

That goal contains several important words:

Valuable — the work matters to customers or the business.
Reliable — the service remains stable.
Safely — change does not create unacceptable operational risk.
Predictably — stakeholders can make plans around delivery.

The constraint is whatever most limits that goal.

A constraint is not always where people are visibly busy. Sometimes the most important constraint is where work is silently waiting.

Throughput, Inventory, and Operating Expense in Software

Goldratt used three core measurements:

TOC term	Manufacturing meaning	Software operations equivalent
Throughput	Rate at which the system generates value	Valuable changes released and adopted
Inventory	Work waiting inside the system	Backlog items, open tickets, unfinished branches, unreleased code, partially analysed work
Operating Expense	Cost of turning inventory into throughput	Engineering, QA, product, support, cloud, tooling, meetings, incident handling

This matters because many software organisations optimise the wrong thing.

They focus on utilisation. They try to keep every developer fully loaded. They create more parallel delivery streams.

Then they wonder why everything takes longer.

The answer is simple:

High utilisation creates queues.Queues create delay.Delay creates rework.Rework creates more delay. Eventually everyone is busy and nothing is moving.

It feels productive because calendars are full.It is not productive.It is inventory with a login screen.

Why “Everyone Fully Utilised” Is Usually Bad Management

In many software organisations, there is an unspoken assumption:

If people are not fully utilised, we are wasting money.

This sounds reasonable.

It is also one of the fastest ways to create a slow delivery system.

Software work contains uncertainty. Requirements change. Incidents happen. Reviews take longer than expected. Test environments break. Customers delay feedback. APIs behave like they were written by someone with a grudge against humanity.

If every team is already loaded to maximum capacity, the system has no slack and without slack, every small disruption becomes a queue.

That is why a fully utilised software organisation can be very slot It is not a contradiction, it is predictable - a motorway at 100% utilisation is not efficient tt is a traffic jam.

A Typical Software Bottleneck

Imagine a software operation with the following flow:

flowchart LR
    A[Product Discovery] --> B[Analysis]
    B --> C[Development]
    C --> D[Code Review]
    D --> E[Testing]
    E --> F[Release Approval]
    F --> G[Deployment]
    G --> H[Customer Adoption]

Now imagine development is completing work quickly, but testing is overloaded.

The usual organisational response is:

“Development is going well. Let’s start more work.”

This makes the system worse.More development creates more items waiting for testing. Lead time increases and defects are found later.Context switching increases.

The correct TOC response is different:

Testing is the constraint. Protect it. Feed it properly. Stop overwhelming it. Improve it.

That might mean:

Reducing work in progress.
Improving automated regression tests.
Pairing developers with testers earlier.
Improving test data.
Removing low-value testing.
Fixing unstable environments.
Making acceptance criteria clearer.
Preventing half-ready work from entering test.

The answer is not “make everyone busier”.

The answer is “make the constraint flow”.

The Five Focusing Steps Applied to Software Operations

1. Identify the Constraint

Do not guess.

Look for where work waits.

Useful indicators include:

Long queue times.
Ageing work items.
Repeated blockers.
Items bouncing backwards.
High defect rework.
Overloaded specialists.
Frequent escalations.
Dependency queues.
Deployment delays.
Incident interruptions.

In software, the constraint is often visible in cumulative flow diagrams, cycle-time scatter plots, blocked-item reports, escaped defect trends, and support-ticket ageing.

But it is also visible in conversation.

Listen for phrases like:

“We’re just waiting for…”
“Only Sarah knows that area.”
“It is stuck in test.”
“We can’t deploy until…”
“The environment is down again.”
“The customer hasn’t signed it off.”
“Security need to review it.”
“We need architecture approval.”

Repeated waiting language is often constraint language.

2. Exploit the Constraint

“Exploit” sounds harsh, but in TOC it means:

Get the maximum value from the constraint using what you already have.

If the constraint is testing, do not waste tester time on poor-quality handovers.

If the constraint is architecture review, do not send vague designs.

Exploiting the constraint means protecting it from waste.

Software examples:

Improve the quality of work entering the bottleneck.
Remove unnecessary meetings from constrained specialists.
Prepare decisions before review sessions.
Batch similar reviews sensibly.
Add checklists before work enters constrained stages.
Make required information visible before the constraint touches it.
Stop sending low-priority work into the constraint.

The constraint should work only on things that matter.

3. Subordinate Everything Else to the Constraint

This is the step organisations resist. Subordination means the rest of the system adapts to the constraint.

If testing can handle five items per week, development should not push fifteen items per week into test.

This feels uncomfortable because it may make some people appear less busy.

That discomfort is precisely the point.

TOC optimises the whole system, not local activity.

In practical terms:

Set WIP limits.
Stop starting and start finishing.
Sequence work around constraint capacity.
Reduce priority churn.
Make policies explicit.
Do not flood constrained teams.
Hold work upstream until it is genuinely ready.

If the constraint is overloaded, feeding it more work is not ambition.

It is sabotage with a roadmap.

4. Elevate the Constraint

Only after exploiting and subordinating should you invest. Elevation means increasing the capacity or capability of the constraint.

Examples:

Constraint	Elevation options
Manual testing	Automation, better test data, risk-based testing, developer-owned checks
Code review	Smaller changes, pairing, review SLAs, ownership models
Deployment	CI/CD, feature flags, environment automation, release decoupling
Support noise	Better observability, self-service, knowledge base, problem management
Product discovery	Dedicated discovery capacity, clearer decision forums, stronger customer access
Architecture review	Guardrails, reference architectures, paved roads, delegated decision rights
Security review	Threat-modelling templates, automated scanning, embedded security patterns

Elevation often costs money.

That is why TOC says exploit and subordinate first.Do not buy more capacity before proving the constraint is real and protected.Otherwise you may simply make a wasteful process more expensive.

5. Repeat

Once the constraint improves, it moves.

This is not failure.It is progress.

How TOC Links to DevOps

The connection between TOC and DevOps is strong.

The Phoenix Project helped popularise this link by applying Goldratt-style thinking to IT work, especially around bottlenecks, work in progress, unplanned work, and flow.

DevOps is often described through the Three Ways:

Flow — move work smoothly from idea to customer.
Feedback — create fast learning loops.
Continual learning and experimentation — improve the system over time.

TOC supports all three.

It asks:

Where is flow blocked?
Where is feedback delayed?
Where is learning being trapped?
Where is work waiting?
Where is the system pretending to be busy while value is not moving?

This is why TOC is useful for software operations. It makes DevOps less abstract.

“Improve flow” becomes:

Find the constraint and redesign work around it.

Software Operations Constraints Are Often Human

A key difference between manufacturing and software is that software constraints are often cognitive.

The constraint might be:

One senior engineer who understands the legacy rating engine.
One product owner who can make commercial decisions.
One architect who approves integrations.
One customer expert who understands the real workflow.
One operations person who knows how deployments actually work.
One support analyst who can diagnose production issues.

This is dangerous.A human constraint creates fragility not because the person is doing anything wrong, often it is the opposite, they are too valuable.They become “Brent” from The Phoenix Project: the heroic specialist who saves the day so often that the entire system becomes dependent on heroics.

The TOC answer is not simply “make Brent work harder”.

The answer is:

Reduce demand on the specialist.
Document repeatable knowledge.
Create playbooks.
Cross-train others.
Build guardrails.
Reduce interruptions.
Make expert time visible and deliberately allocated.
Stop using heroics as an operating model.

Heroics feel impressive.

They are usually evidence of a broken system.

The Product Manager’s Role

Product managers are often in a good position to apply TOC because they can see across the system. A TOC-minded product manager asks:

What is limiting customer value?
Where is work waiting longest?
Which queue hurts revenue or adoption most?
Which dependency repeatedly delays delivery?
Which team is overloaded with invisible work?
Which metric is being locally optimised at the expense of overall flow?
What work should we stop starting?

This changes product management from backlog administration into operational strategy.The PM becomes less of a feature dispatcher and more of a flow designer.That is a much more useful job.

A Simple TOC Workshop for Software Teams

You can run a practical TOC session without turning it into a consultancy festival.

Step 1: Map the flow

flowchart LR
    A[Idea] --> B[Discovery]
    B --> C[Analysis]
    C --> D[Build]
    D --> E[Review]
    E --> F[Test]
    F --> G[Release]
    G --> H[Operate]
    H --> I[Learn]

Step 2: Add queues

For each stage, ask:

How many items are waiting?
How long do they wait?
Who owns the queue?
What causes rework?
What causes blocking?

Step 3: Identify the constraint

Look for the stage where improving flow would most improve the whole system.

Step 4: Decide how to exploit it

Ask:

What waste hits the constraint?
What low-value work enters it?
What information is missing?
What interruptions reduce its capacity?

Step 5: Subordinate

Ask:

What upstream work should slow down?
What WIP limit should we introduce?
What should stop entering the system?
What should be finished before more work starts?

Step 6: Elevate

Ask:

What investment would genuinely increase system throughput?
What automation would remove repeatable work?
What training would reduce single points of failure?
What tooling would make work visible?

Step 7: Review monthly

The constraint will move.

That is the point.

TOC and AI in Software Operations

AI makes TOC more important, not less.

Many organisations are trying to apply AI everywhere at once:

Generate requirements.
Summarise calls.
Write tests.
Review code.
Draft release notes.
Analyse incidents.
Produce documentation.
Answer support questions.

Some of this will help.Some of it will create more noise.

TOC gives a better approach:

Apply AI where the constraint is.

If the constraint is test design, AI-assisted test generation may help.If the constraint is support triage, AI-assisted classification may help.

But applying AI to a non-constraint may simply create more work downstream.

Faster requirements generation is not useful if engineering is already overloaded. Faster code generation is not useful if testing is the constraint.

AI should not be sprayed across the organisation like expensive Febreze. It should be aimed at the constraint.

Final Thoughts

The Theory of Constraints is powerful because it is simple, but not simplistic. It forces software organisations to stop pretending that every improvement matters equally.

They do not.At any point in time, one constraint is limiting the system more than anything else.For software operations, this is especially valuable because our bottlenecks are often hidden inside queues, dependencies, approvals, interruptions, and overloaded experts.

The result is a practical management philosophy for product managers, engineering leaders, delivery managers, support teams, and operations teams.The next time delivery feels slow, resist the temptation to ask everyone to go faster.

Ask a better question:

Where is the constraint?

Because until you answer that, most improvement is just noise with a meeting invite.

Back to Writing