Linking Out Loud #8: Theory of Constraints

By David Laing

David Laing

Dear readers,

You have likely heard the expression, “a chain is only as strong as its weakest link.” This saying is the mantra of a management paradigm called the Theory of Constraints. The argument, which I first read in Tiago Forte’s short, provocative primer on the subject, goes as follows.

Premise #1: in every system there is a constraint that is more limiting than all others. Every chain has a weakest link, every hose has a tightest bottleneck, etc.

Premise #2: the most limiting constraint is what determines the throughput of the system. A chain can't support a weight heavier than what its weakest link can support; a hose can't pass more water than its tightest bottleneck can pass; etc.

Conclusion: the only way to increase the throughput of the system is to relieve the most limiting constraint. The only way to make a chain stronger is to strengthen its weakest link; the only way to make a hose pass more water is to expand its tightest bottleneck; etc.

If you take it seriously, this conclusion bends the mind. Have I been wasting my time by trying to make improvements to constraints that aren’t the most limiting one? Is my current ability at rock climbing limited entirely by my finger strength, such that no improvements in general fitness or mindset will make any difference? Is the speed of the software I build at work limited entirely by my choice of programming language, such that no improvements can be made by choosing different algorithms?

The Theory of Constraints doesn’t tell you which constraint is the most limiting, only that one of them must be the most limiting. Everything else is irrelevant.

My initial reaction to the Theory of Constraints was that if we want to improve our systems, we ought to spend much more energy identifying which constraints are the most limiting. We should be skeptical of the more common approach of making scattershot improvements wherever we happen to notice deficiencies in a system.

After thinking about it more, I’ve come to two conclusions.

One is that the Theory of Constraints only applies to systems which take the form of a sequence of dependencies. Hoses and chains are good examples of such systems, as are production lines and algorithms and recipes. But many of the systems we care about have independent components, so they require different models. Consider two highways:

  • A one-lane highway.

  • A two-lane highway that has a short segment with just one lane.

If you apply the Theory of Constraints to these systems, you might predict that they have the same throughput. However, in the two-lane highway, faster cars can pass slower ones at any point except when it drops to one lane. So the mostly-two-lane highway will have the greater throughput. Whenever a system has independent components like this, we need to think more broadly about how and where to make improvements.

My other conclusion is that even when dealing with a sequence of dependencies, we might sometimes be better off making scattershot improvements, without considering which constraint is the most limiting. One reason for this is that identifying the most limiting constraint is often costly. Another reason is that as long as we continually make improvements in multiple areas, we will occasionally make improvements to the most limiting constraint. At such times, we don’t just unlock the improvements from that specific constraint; we also unlock the pent-up improvements from all the other constraints that we relieved previously.

I trained as a competitive swimmer for eight years. Like many athletes, I often had the experience of hitting a plateau for eight months, in which I made seemingly no progress at all, and then suddenly breaking through the plateau and making a lot of progress all at once. Having reflected on the Theory of Constraints, I think I now have a better mental model for those seemingly incomprehensible patterns of stagnation and improvement. When you’re stuck at a plateau, it’s probably not the case that you’re making no improvements at all. Instead, you’re just making improvements that won’t manifest until one day when, by chance, you relieve your most limiting constraint. The floodgates open wide, and the cycle begins again.

Yours unlimitedly,