Thinking tool: Optimise only the constraint by finding your bottleneck
When improving a system with many parts: find the bottleneck and improve only that.
If you've ever played Shapez or Factorio, you'll have an intuition that it's the bottlenecks that are key. In manufacturing (or manufacturing games) this usually becomes quite obvious. But the same applies to anywhere else you care about flow: of team tasks through different stakeholders, of API requests through microservices, or of candidates in a recruiting pipeline.
In The Goal, a novel about manufacturing optimisation, the protagonist leads a Boy Scout hike through a narrow trail wide enough for only 1 boy at a time. It sounds obvious, but they realise the group is held back by its slowest member, Herbie - fast walkers at the front just create a long gap, not a faster hike.
The group only speeds up when they offer to take weight out of Herbie's backpack, and they stop spreading apart when they put Herbie at the front to set the pace. (There are other nice analogies: the spread of the group is 'work in progress' inventory, the trail ahead of the first boy is raw material, the speed of each boy is process throughput.)
From this, The Goal sets out a theory of constraints, with 5 focusing steps:
- Identify: The signal for this is "where does work pile up?". In the walking analogy, this is "which boy has a large space ahead of them to the next boy", which is Herbie. In practice, this requires a deep understanding of your system and what outcome it is you're even optimising for.
- Exploit: Take free actions to optimise throughput of the constraint. In the story, they realise Herbie is carrying a bunch of equipment which can be distributed to the other boys.
- Subordinate everything else: Every non-constraint should run at the constraint's pace. In the story, this is done by moving Herbie to the front of the pack. In practice this is often done poorly as it requires deliberately creating idleness. But note that this is better than the alternative: producing excess work-in-progress parts just increases WIP inventory (a cost), not final output.
- Elevate: Spend money to optimise the throughput of the constraint. This isn't given in the hiking story, but perhaps it could look like buying Herbie higher-spec lightweight gear so he moves faster. Often in knowledge work jobs, this looks like hiring a new person onto the team.
- Repeat: In doing the steps above, you might have changed the balance of the system and have introduced new constraints. Go back to step one and analyse again!
I'll re-highlight the bit in point 3: it's actually better sometimes for non-bottlenecks to be idle. Additionally, intentionally blocking the system on the constraint can help focus efforts on this bottleneck. In the example above, putting Herbie in front helped keep the pack together (equivalent to having less in progress work that would make the team less agile), and incentivised people to take things out of his backpack.
This is built into certain management systems: Kanban sets low max limits on "work in progress" tasks. This forces the system to stop and resolve bottlenecks, improving overall flow. Additionally, in the same way that subordinating to the constraint kept the pack together above, here the reduced WIP helps you to be more agile: if you don't have to worry about a bunch of half-complete conflicting work, you're more able to pivot when you receive important new information.
In the Kanban board above, review is the constraint: it's full at its limit of 3, so nothing can move into it. That backs up into Build, where four finished tickets sit in "done" with nowhere to go. Because build is now at its limit of 5, nobody there can start anything, so the sensible thing left to do is to help review.
Related concepts
This is part of my thinking tools series.