As software engineers, we’re often told to optimise everything; our code, our pipelines, our estimates, even how many Slack notifications we can endure before snapping. But the brutal truth? Most teams are already working hard. The real bottleneck isn’t effort. It’s focus.

That’s where The Theory of Constraints comes in. Originally developed by Eliyahu Goldratt in the 1980s for manufacturing, it’s one of the few frameworks that still feels refreshingly relevant in today’s world of sprints, pull requests and continuous delivery pipelines.

In this post, I’ll walk through what the Theory of Constraints (TOC) is, how it applies to software delivery, and how teams I’ve worked with have used it to move faster without just throwing more people, meetings or Jira tickets at the problem.

You’re only as fast as your slowest step

TOC starts from one deceptively simple idea:

Every system has a constraint, and that constraint determines the output of the whole system.

Your team’s ability to deliver value is limited by one thing at a time, not twenty. Not your monorepo. Not the fact that you’re still waiting on that one designer to upload final Figma assets.

It might be:

• A dependency on another team for API changes
• A single principal engineer who reviews all high-risk PRs
• A flaky end-to-end test suite that blocks every deployment
• Or a product owner with more backlog items than hours in the week

Until you address that constraint, optimising anything else is largely noise.

The Five Focusing Steps

Goldratt lays out five steps to improving any system:

1. Identify the constraint: What’s the one part of your delivery process slowing everything else down?
2. Exploit the constraint: Make sure that step is working as efficiently as possible. Remove any time-wasting or context switching.
3. Subordinate everything else: Align all other activities to support the constraint. Don’t optimise other parts at its expense.
4. Elevate the constraint: If you’ve done all the above and it’s still the bottleneck, find ways to add capacity or rework the process.
5. Repeat: The constraint has likely moved. Find the new one and start again.

This isn’t theory for theory’s sake; it’s a mindset shift.

What it looks like in a software team

Here’s a real-world example.

In one cross-functional team I worked with, we had everything “agile”: Story points, daily stand-ups, CI/CD pipelines. Yet releases still were delayed or at the very least hard work to get completed. Features sat in review for days and every retro turned into a rehash of the same blockers.

We applied TOC and quickly realised the true constraint: a senior dev who acted as the gatekeeper for critical PRs.

Not because they were power-hungry; they were genuinely the only person trusted to approve changes in a complex legacy module.

Here’s how we applied the steps:

• Identified the constraint: Review bottleneck by one person
• Exploited it: Gave them focused time for uninterrupted review blocks
• Subordinated: Paused less-urgent work to get critical PRs queued early
• Elevated: Began knowledge-sharing sessions so more team members could review safely
• Repeated: Once the constraint shifted to test suite flakiness, we tackled that next

The result? Our lead time dropped by over 30% in six weeks. Same people. Same stories. Just fewer delays in the system.

Why it works: You stop pretending “busy” equals “effective”

Most engineering teams fall into the same trap: we measure activity, not throughput.

We obsess over burndown charts. We celebrate velocity. But what really matters is how fast ideas move from backlog to customer hands, safely and sustainably.

TOC forces a focus on flow.

By finding the one thing holding you back, and rallying the team to improve it, you stop optimising in isolation and start delivering as a system.

Common Software Constraints (and What to Do About Them)

Here are some of the most common constraints I see in software teams, and how you can start tackling them.

1. Manual QA Processes
Symptoms:

• Releases delayed while waiting on testing
• Stories pile up in “Ready for Test”
• Bugs escape due to rushed test passes

What to try:

• Automate critical smoke and regression tests
• Shift testing left - test during development, not after
• Invest in exploratory testing guides for engineers

2. Dependencies on External Teams
Symptoms:

• User stories blocked mid-sprint
• Work-in-progress inflates with “Waiting on XYZ” tickets
• Handoffs create frustration and delay

What to try:

• Bring dependent teams into sprint planning or refinements
• Create/improve shared definitions of “ready” and “done”
• Identify recurring external blockers and escalate

3. Single Reviewer or Gatekeeper
Symptoms:

• PRs sit for days waiting for review
• Only one person “knows” a particular area of the code
• Review work piles up when they’re out or context-switching

What to try:

• Pair on critical changes to spread knowledge
• Rotate review responsibilities across the team
• Create lightweight review checklists to speed up quality sign-off

4. Flaky or Slow CI Pipelines
Symptoms:

• Developers “babysit” their commits
• Test failures that aren’t real failures
• Fear of deploying due to inconsistent results

What to try:

• Prioritise fixing flaky tests - treat them like production bugs
• Add fast, deterministic tests earlier in the pipeline
• Give engineers visibility into pipeline performance metrics

5. Product or Decision-Making Bottlenecks
Symptoms:

• Work stalls waiting for clarification
• Vague or shifting priorities mid-sprint
• Features partially built due to indecision

What to try:

• Push for smaller, clearer slices of work
• Use story kickoffs and short feedback loops
• Clarify product ownership and decision rights

Each of these constraints can feel “normal” in isolation, just part of how we build software. But TOC teaches us to zoom out, spot the actual bottleneck, and put our collective effort into fixing it first.

When teams start thinking this way, they stop just doing Agile and start delivering value faster, with less drama.

A culture shift, not a tool

The Theory of Constraints doesn’t need a Jira plugin or a Notion template. It’s about how you think.

It encourages teams to:

• Prioritise flow efficiency over resource efficiency
• Rally around the actual bottleneck instead of reacting to symptoms
• Continuously improve, rather than just “doing Agile”

It’s uncomfortable at first. You might have to admit your strongest engineer is also your biggest bottleneck. Or that your test suite is more performative than protective.

But if you want to ship faster without burning out, it’s a trade-off worth making.

You don’t fix everything. You fix the right thing next.

If there’s one lesson I’ve learned applying TOC in software teams, it’s this:

You don’t need to optimise everything, just the thing that matters most right now.

The Theory of Constraints helps you see delivery not as a checklist of best practices, but as a living system. A system that can be improved not by working harder, but by working smarter and together.

And if that sounds like the kind of engineering culture you’d like to build, I’d love to hear from you.

Recommended Reading

If you want to dive deeper, these resources bridge the gap between theory and practice (please note, these are amazon affiliate links, if you buy via this link, I get a small percentage….which would be very much appreciated):

• The Goal by Eliyahu Goldratt

Still the best introduction to TOC, told through a fictional lens. Required reading for systems thinkers.

• The Phoenix Project by Gene Kim et al

Brings TOC into a modern IT and DevOps context. Great for helping leaders understand flow in tech orgs.

• The Bottleneck Rules by Clarke Ching

Quick read, full of practical applications of TOC to service and knowledge work.

• Accelerate by Forsgren, Humble & Kim

Uses data to show why flow, feedback, and constraint-focused improvement drive software delivery success.

• Beyond the Goal (audio) by Eliyahu Goldratt

Advanced thinking on how TOC applies to business transformation, policy constraints, and strategic leadership.

Gary Worthington is a software engineer, delivery consultant, and agile coach who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance.