Why The Bottleneck Is Everything

This is probably the least intuitive idea that I’ve come across in my working career, but when explained and demonstrated, possibly one of the most important.
Here it is: it is inefficient to have everyone working at 100% effort, 100% of the time.
This seems wrong – we’re paying for these people, they should be putting all their time and effort towards our product features! Get back to working on them! However, due to a concept called the “theory of constraints” (see “The Goal” by E.M. Goldratt) this is actually a terribly inefficient way of getting value through your business.

I’m going to approach this slightly differently to Goldratt, so let’s start with these premises
1) Development of a product/service goes through several sequential steps
Yes, even if we’re super agile we do still find ourselves going through sequential steps, e.g. defining what we want, identifying what it depends on, actually doing it, getting reviews & presumably smashing a big green release button.
2) Work in progress costs effort
Someone has to estimate, design, do something with it, otherwise it’s not really in progress
3) Unfinished work goes stale over time and costs effort to un-stale-ify
Un-stale-ify …. you’re welcome! Pretty much any work that isn’t completely implemented and on test will get out of date enough to be not worth having.

Based on these, I think we can build the case the case for the importance of bottlenecks.
Starting with 1, lets assume that we have an overly simplistic sequence A-B-C.
A is super efficient and puts 10 units through per day
B is not too bad with 9 units per day
C is our bottleneck with just 4 units per day

It seems fairly obvious that if we get A and B to work at full capacity then we still don’t make any more than 4 units per day that we can sell. A and B are consuming cost and produce surplus that starts to pile up, rust, and everyone is blaming poor C.
So, ok, that was obvious and we decide to recruit a second C, now we’re a bit closer and managing 8 units per day… we still have that surplus though and that hurts (see premise 2 and 3).
A is still making 10 units per day
B is still making 9 units per day
C is now 8 units per day

Getting A and B to work at full capacity doesn’t help. Throughput will never be higher than 8 & we’ll end up with a big rusting backlogs behind B and C. This ‘rusting’ occurs over time, the longer the thing sits around, the more effort it costs.
Ultimately there is no benefit to optimising locally at A and B, if C isn’t going any faster, then the system isn’t going any faster.
Bottlenecks are everything because any optimisation anywhere apart from the bottleneck is only going to cost you more and gain you nothing – even slow you down!
What if we took a different approach? A ‘Pull’ rather than ‘Push’ approach. Let’s give each step a fixed backlog of up to C’s maximum capacity and no more. The previous step only feeds in enough to fill the backlog if there’s space. This means that A and B start realising that they sometimes don’t need to work at full capacity and the same end product quantities get generated regardless, while also not causing overflowing backlogs.
Applying this idea to knowledge work like software development, there’s even more benefit – as this ‘spare’ time can be used for learning, personal development, to look at what *should* be done as well as what *must* be done, maybe help the bottleneck out or (and this is really important) investigate new and creative ideas to give your business an edge.
Suffering with bottlenecks? Yes you are. =)
Here are the 4 steps to dealing with them, plus a link that explains each step in more detail
1) Identify
2) Exploit
3) Subordinate
4) Elevate
https://masteringbusinessanalysis.com/mba082-addressing-bottlenecks-theory-constraints/

Thanks for reading!