The Theory of Constraints

The Theory of Constraints (ToC)

A long time ago, I read a book that profoundly changed the way I think about work. That book was The Goal, written by Eli Goldratt in 1984, The story revolves around Alex Rogo, a factory manager, who meets a physicist named Jonah who some believe represents W. E. Deming. Jonah, through a sometimes frustrating socratic dialogue with Alex, introduces him to some fundamental operations management concepts including the Theory of Constraints (ToC). 

The Goal is credited for transforming the business world, in large part through its accessibility and presentation of powerful concepts in a way that makes them easy to understand and act on. The Goal was apparently the book that inspired Gene Kim to write the excellent DevOps book The Phoenix Project, which adopts a similar format and characters. It’s also one of the three books that Jeff Bezos, apparently, asks his execs to read.

ToC, one of the many concepts introduced in The Goal, is an incredibly simple but powerful idea that helps us to think more about the system of work. It shows us where to make improvements and  indeed, I think even more importantly, where *not* to make improvements. It states that:

“Improvements made anywhere besides the bottleneck are an illusion”. 

The idea at the core of the ToC is that any system or process contains a primary constraint. This is the one thing, the bottleneck, that is throttling the performance of the process. ToC encourages system-wide improvement over local optimisation, emphasising that the strength of any process (or system) is determined by its bottleneck (its constraint). 

Let’s look at a visual example with four steps in a simple manufacturing process:

Assuming there’s nothing preventing component 1 from operating at capacity, it processes 7 units per hour which get passed to component 2. Component 2 can only process 5 units per hour, so the excess 2 units per hour stack up in front of it. Component 3 then only has 5 units available to process in the hour, but because it’s capable of 11 units per hour, it’s operating at less than 50% capacity and both components 3 and 4 end up somewhat starved of work. The entire process throughput is 5 units per hour – the maximum throughput at which the slowest component can operate. In a factory manufacturing process, the units are inventory, which we’d see piling up against component 2 on the factory floor, waiting to be processed. Here the units are inventory but in different contexts they could be products, patients or tasks.

In this example, it’s obvious that if we’re going to improve something, we should improve component 2. If we improve others, such as component 1, we’re only going to increase the rate at which things pile up before component 2. If we improve components 3 or 4, nothing will change, exceptthey’ll be further starved of work. Often, things get improved just because we can – we identify a a cheap and easy improvement, and decide to do it. After all, we should always improve, right?

A crucial learning from ToC is just because you can improve something, doesn’t mean you should! To come back to that crucial line:

“Improvements made anywhere besides the bottleneck are an illusion”. 

Improving the throughput of a non-constraint part of a process without concern for the whole system means that whilst we might feel pleased with ourselves (or even rewarded) for improving the bit that we’re responsible for, we could actually be causing problems elsewhere in the organisation. 

Improving the Flow

Unfortunately, in most contexts, it’s far more difficult to see where the constraint actually exists, and in many cases, we work in organisations where we can’t see the full process from end to end from where we sit. Most of us work in some sort of silo, some part of an organisation where we can only see our part of the process or flow, and it can often be difficult to even understand what units to measure “flow” in.

Goldratt describes a number of steps in order to improve the flow through a process. These are:

• Identify the constraint. We can’t fix the bottleneck until we know where it is. Sometimes that’s obvious, usually it isn’t.
• Exploit the constraint. What can we do to improve that part of the process? Maybe we can provide more resources, different equipment, or reduce the amount of work that component needs to?
• Subordinate everything else to the constraint. Given the constraint is the bottleneck, everything else in the process should be designed to improve the throughput of that part. Maybe other stages can make the work easier to execute or hand over, or take on part of those tasks? Here, Goldratt introduces the idea that everything else should work to the beat of the constraint’s drum*.
• Elevate the constraint. If the constraint still exists, then what else can we do? This might require significant investment or a wholesale change in process.
• Repeat the process. Start again. The constraint should now have moved: there’s always a constraint somewhere – so find it 🙂

*In the book, Goldratt describes a scout group on a hike, and there’s one slower kid who keeps getting left behind. However, by putting the slowest kid at the front, the group is able to stay together, because everyone else can go at that pace. See related reading for a deeper dive into Goldratt’s “Drum Buffer Rope” practice.

Applying ToC to support value flow

Although the book is set in a manufacturing context, I’ve found the ToC valuable in many contexts – from analysing visitor flow on ecommerce websites to improving ingress and egress of thousands of people attending stadium concerts. However, one of my favourite implementations is modelling and improving value flow through an organisation.

Many organisations fail to take constraints adequately into account when designing organisational structure and flow of work (if, indeed, it’s designed at all). I used ToC to model the constraints in an organisation I worked in when the marketing department launched a large campaign. In the diagram below, the numbers are made up ro represent throughput capability for each department – you might want to imagine they’re analogous to “sales that can be processed per day”:

This was a typical organisation that markets, sells, and supports consumer products. The marketing department had a great idea for a campaign, and launched it. It was wildly successful, and the sudden surge in enquiries overwhelmed the inbound sales team. Those enquiries that did get through got passed to fulfilment teams to process, but this is a big spike for them, and they’re not ready, so a backlog started to build. Customers found themselves waiting longer than promised for their deliveries, so they started ringing customer service, who, again, are not geared up for the volume and struggled to meet their call wait time targets.

There are, of course, ways around this. If the campaign was planned well in advance, with effective communication between teams in the process, we could either have decided to manage the campaign differently and trickle sales in, or ensure that we’ve got the capacity at each stage to handle the likely demand and not let customers down. 

In the case I observed, because the KPIs for the marketing department consisted primarily of scores around engagement and enquiries, they were incentivised to maximise the metrics of their campaigns, with little regard to whether other teams in the organisation could fulfil resultant demand. This is unfortunately rather common – the marketing team who drive a very successful campaign and generate lots of interest get praised, even given bonuses, despite a suboptimal outcome for the organisation. As a result of this, the heavily utilised teams further along the process may even be criticised or punished for their poor performance, but remember what happens when we utilise a team over 90%? Everything comes to a standstill. A lack of organisational systems thinking (or rather the conditions, structures and capabilities that facilitate systems thinking) are in part responsible for this. It’s certainly not restricted to marketing teams – any team who are given KPIs and incentives that focus solely on their own silo are likely to unintentionally act to the detriment of the larger system.

We can see ToC at work across all domains in social, technical and sociotechnical contexts: sales teams with big targets who flood delivery teams with demands, large events that overwhelm local road networks, software systems where one crucial component is overwhelmed, healthcare systems that send patients to wards that don’t have capacity, and of course, the wonderfully graphical representation of the Suez Canal incident in March 2021, where the the container ship Ever Given reduced the flow of the primary international shipping constraint to zero.

So why is this so hard to do?

It can be difficult to see the whole system when you’re inside an organisation, due to organisational design, incentives, silos and interpersonal dynamics including competition, incentives, or even antagonism between teams. These dysfunctional organisational patterns can make it challenging to apply the ToC organisationally, even when doing so would have significant benefits.

Whether or not we consider psychological safety to be a team phenomenon or applicable to wider group contexts, it has an important role to play here. When members of different teams come together to plan and discuss work, they will feel a certain level of psychological safety, depending on the perceived costs and benefits of candid and open discussion. And that degree of psychological safety will have a direct effect on the effectiveness of coordination and handovers between teams.

However, one of the most common dysfunctions I see is organisations prioritising local optimisation of psychological safety over global optimisation. They end up with high performing “bubbles” – teams that feel psychologically safe, have high behaviour standards, and possess ambitious goals – but communication outside of the bubble and between teams is less effective. This poor communication can be exacerbated by competition between teams (or between managers of those teams) and can result in one team passing an overwhelming amount of work along to another team. Usually this is unintentional, but it can sometimes be intentional. 

We instead need to foster a broad “fabric” of psychological safety across an organisation. We can do this, and mitigate against local optimisation and poor communication between members of dependent teams, by creating well defined Team Charters, Team APIs, defining Team Interaction Modes, and fostering broader adoption of behaviour standards across the organisation*. Improving the communication between members of different teams helps us to take a more systemic approach to the flow of value (whatever that value looks like in your organisation) across multiple teams. We should recognise that unlike most factory production lines, in most organisations we can’t always control how fast work comes in, but we can have honest and candid conversations about how to best handle it so that we’re not simply passing pain down the chain.

ToC is a rather linear approach to constraints in systems, and makes a number of assumptions, including that organisations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. It’s not applicable in all contexts, and many, if not most, situations are not as simple as the ToC model would have us assume. However, as simple models often are, it’s a powerful tool when applied well in the right context. 

I hope you found this dive into the Theory of Constraints, organisational bottlenecks, psychological safety between teams, and organisational fabric useful, or at least interesting!

Notes:

*. Another way to mitigate high-friction handoffs is to restructure the organisation so that one team can own and manage the flow of value from start to finish, but that’s often not within our power to do.

ToC on quality: ToC doesn’t make a great deal of explicit reference to quality, except for checking to ensure defects are not passed downstream, and there is little focus on the integrity of social handovers, or alignment of value with objectives (i.e. making sure that we’re doing the right thing, not simply the wrong thing more quickly!).

Further Reading:

Standing on the Shoulders of Giants – Production concepts versus production applications The Hitachi Tool Engineering example. This is a fantastic paper by Goldratt, analysing the methodologies of Henry Ford, Taiichi Ohno, and Goldratt himself and presents explicitly the four principles of flow management according to these operations management philosophies.

Drum Buffer Rope – process improvement practice.

The Five Focusing Steps, the Thinking Processes, Drum-Buffer-Rope (DBR) scheduling, and Critical Chain Project Management (CCPM).

Related articles:

Team Charters

Making Work Visible

Queuing Theory and Utilisation

Deming’s 14 Points

Statistical Process Control

Sociotechnicality

Conway’s Law

Psychological Safety at Work

Remember dieselgate (the VW emissions scandal)? It’s back, but this time it’s trains! Trains made by Polish manufacturer Newag began to malfunction or stop working at odd times and in bizarre ways. An investigation by the Dragon Sector team revealed software conditions that disabled trains when serviced at specific locations or after replacing components, affecting numerous trains across Poland and leading to major schedule disruptions. It’s now being reported that the team who discovered these software “traps” and repaired them (with permission from the owners of the trains) are now being threatened with legal action by the manufacturer. 

Thanks to Nick Drage for this fantastic guest post on safe-to-fail “wargames”. Nick makes the excellent point that simulations are very common in some domains (particularly safety critical domains), and much rarer in others. When was CIO at a large concert and event stadium, we would often run disaster and critical incident simulations, which enabled us to improve our preparations, make better decisions, and practice working and communicating in difficult circumstances, safely. Generally, outside the safety critical world, simulations and “war gaming” are rare. “Being able to openly experiment and fail in front of peers and seniors, and being able to see that the only consequences are shared experiences, shared learnings, and improved responses when the real situation occurs, can provide that benefit.” This is a great piece by Nick that dives into the dynamics of simulated adversarial games and what part psychological safety has to play.


Hat tip to Dan Fox in the psychological safety community for sharing this episode of All in the Mind on BBC Radio 4, featuring Amy Edmondson, discussing whistleblowing, amplifying weak signals, and how the quality and safety of work depends on our willingness to be candid. Community member Jonathan Cohen also gets a well deserved shout out 🙂 

I was really pleased to be invited to speak with Teri Schmidt on the Strong Leaders Serve podcast, talking about cognitive load and psychological safety. We discuss how, in environments or contexts where our cognitive load is very high, we’re more likely to default to silence, because less of our mental capacity is available to make that cost/benefit calculation of whether speaking up is worth the risk. That also means we can end up in a sort of catch-22 situation where we don’t ask for help – but it’s the very help itself that could reduce our cognitive load.

Thanks to Jade Garratt for this one – Brian Cox on the High Performance Podcast. I could listen to Brian Cox for hours, and this is a great episode where he and Jake Humphrey discuss how in domains like aviation, when someone makes a mistake, it’s analysed in detail in order to surface the systemic causes. Nobody points a finger, and the focus is on improvement rather than blame. Success is about acquiring knowledge and doing it better next time. They discuss the ingredients that create psychologically safe environments where people don’t find it fearful to be challenged, including rewarding people for being wrong and acknowledging it’s part of the process of being better. Whilst this approach (psychological safety) is more common in safety critical industries, they discuss how interesting it would be to try to bring that culture into non-safety critical industries, such as politics…

Finally, I love this piece from sustainability and regenerative agriculture expert Erica Löfving, on the safety in finding your “tribe”.

Stickers are back in stock! (And there’s a new one…)

There are three ways that you can get your hands on some of our psychological safety stickers!

1. Buy some at our online shop
2. Attend a workshop
3. Promote psychsafety.com on social media and send us your postal address!

This week’s poem:

Glory Be to the Gang Gang Gang, by Momtaza Mehri

In praise of all that is honest, call upon the acrylic tips
and make a minaret out of a middle finger, gold-dipped
and counting. In the name of Filet-O-Fish, pink lemonade,
the sweat on an upper lip, the backing swell and ache
of Abdul Basit Abdus Samad on cassette tape, a clean jump shot,
the fluff of Ashanti’s sideburns, the rice left in the pot
the calling cards and long waits, the seasonal burst
of baqalah-bought dates.

Every time they leave and come back
alive.

Birthmarks shaped like border disputes.
Black sand. Shah Rukh’s dimples, like bullets
taking our aunts back to those summer nights,
these blessings on blessings on blessings.

Give me the rub of calves,
rappers sampling jazz,
the char of frankincense
and everything else that makes sense
in a world that don’t.



Momtaza Mehri is a Somali-British poet who in 2018 was named the Young People’s Poet Laureate for London.