Finding the bottleneck when everyone is busy

On the page The principle we show the bottleneck with two teams and one boundary. A real organisation has more teams, plus systems owned by different departments. With twelve teams and systems, you don’t see the bottleneck at first glance. There is some work in front of every handover, and everyone is busy.

This article is for anyone who has not come across the Theory of Constraints or Conway’s Law before. You don’t need any prior knowledge.

What a bottleneck is

The word comes from the neck of a bottle. How fast a bottle empties does not depend on its belly. It depends on the neck, the narrowest point. Make the belly bigger and it won’t empty one bit faster.

Work behaves the same way. An order passes through several hands before it reaches the customer. One point along the way is the slowest. It determines how much comes out at the end. Anything you speed up elsewhere never reaches the customer.

Eliyahu Goldratt turned this into a theory in the 1980s: the Theory of Constraints. It became known through his novel “The Goal”, in which a plant manager has to save his factory from being closed.

Herbie and the hiking troop

The best-known image from the book is a hike. The plant manager joins his son’s scout troop. The troop walks in a line, and soon gaps open up. The fast ones at the front pull away, and the line at the back keeps getting longer.

Nobody is to blame. Somewhere in the line walks a boy called Herbie, who is slower than everyone else. Herbie decides when the troop reaches the camp. It doesn’t help that the fast ones at the front walk even faster. They just wait longer for him at the end.

The solution in the book is simple. Herbie walks at the front, so nobody runs ahead and the troop stays together. Then his heavy backpack is shared out among the others. Afterwards the whole troop is faster, even though nobody walks faster than before.

This picture already holds almost the whole theory. More on that below.

From hiking troop to organisation

In a company, the path of the work is longer and harder to see. A request comes in, one team checks it, another calculates something, a third enters it into a system that yet another department looks after. Each of these stations is a hiker in the line. Between two stations there is a handover, and work can pile up at every handover.

The picture below shows such an organisation. A made-up example, but built the way organisations typically are:

• The white boxes are teams, groups of people.
• The grey boxes are systems, the software people work with. A CRM manages customer data, an ERP manages orders, stock and invoices. The legacy system is an older program that is still needed.
• The dashed lines are the boundaries between departments, as drawn in the org chart.
• The green squares are work waiting in front of a handover.
• The arrows show how the work moves on until it reaches the customer on the right.

The picture plays one run with 50 work items. New work comes in on the left at the intake, and more work starts at Team 3 and in the CRM. Department C accepts at most two requests into the legacy system at a time. Above the picture you can follow how much work was put into the system, how much is in progress, how much is done for the customer and how many days have passed. The button below starts the run again.

Looking is not enough

Watch the run. The pile grows in front of Team 4, and Team 4 always has something in hand. Anyone looking takes Team 4 for the bottleneck. And Team 4 rightly reports that it is at its limit.

In knowledge work it is even harder, because the work sits in tickets and inboxes and you don’t see the piles at all. Everyone being busy is not a good sign, either. On the hike, the fast ones at the front were busy too. They had just run ahead.

First experiment: make Team 4 faster

The obvious move is to strengthen Team 4. Suppose that from tomorrow it works twice as fast, with a new tool or with more people. That looks like a big improvement. The picture runs with the same 50 work items as above. Compare the days at the end.

Team 4 is now done sooner, but the pile in front of it stays. The work doesn’t reach the customer any earlier, and the number of days stays the same. Only a measurement shows why.

Measure what the time goes on

Waiting time alone misleads here as well. Work waits longest in front of Team 4. So we also measure what each station spends its time on: working, waiting for the next station, or waiting for work.

The hike is no different. The hikers right behind Herbie look slow. But they are only stuck behind him. The bottleneck is the station that never waits. In the example, the legacy system works almost all the time. Team 4 works only about a third of the time and spends most of the rest waiting for the legacy system to take something off its hands.

Often this is already recorded in the tools people work with: when a ticket was created, when someone worked on it, when it was passed on and how long it sat there finished.

The next picture runs this measurement. As soon as the first 10 items have reached the customer, the waiting times at the handovers appear, and in every station a bar: green means working, orange waiting for the next station, grey waiting for work. A station with a green border is working right now; an orange border means it is done but cannot pass the work on. A little later the picture marks the bottleneck.

Second experiment: start at the bottleneck

The measurement shows: the legacy system works without a break, and Team 4 spends most of its time waiting for it. So we start at the legacy system, with much less effort than at Team 4: the legacy system handles 30 % more than before.

All 50 items reach the customer earlier. The smaller improvement in the right place achieves more than the big one in the wrong place. Goldratt put it this way: an hour saved at a non-bottleneck is a mirage.

The legacy system is still the bottleneck afterwards, just less so. That is why measuring continues.

What the Theory of Constraints prescribes next

Goldratt describes five steps. For the hiking troop they look like this:

1. Identify the constraint. Herbie is the slowest.
2. Exploit it. Herbie should not lose any time, for example by having to wait for others.
3. Subordinate everything else to it. Herbie walks at the front, and everyone else matches his pace. That feels slow to the fast ones, but the troop arrives earlier.
4. Elevate the constraint. His backpack gets lighter. Now Herbie himself walks faster.
5. Start again. Once Herbie is no longer the slowest, someone else is. The bottleneck has not disappeared. It has moved on.

In the example, exploiting means: no time at the legacy system is lost on work that won’t flow on afterwards. Subordinating means: Team 4 and everyone before it only pass on as much as the legacy system can process. More work in front of the bottleneck doesn’t make it faster. It just waits there longer.

The order matters. Elevating usually costs money or rebuilding. Steps 2 and 3 often cost almost nothing and already achieve a lot.

What Conway’s Law has to do with it

In 1968, Melvin Conway observed that an organisation that designs a system builds it to mirror its own communication structure. Where two groups rarely talk to each other, whatever they build has a seam in that very place.

You can see this in the picture with Team 4 and the legacy system. Team 4 belongs to Department B, the legacy system to Department C. A line in the org chart runs between them. Right at that line, IT has an interface: Team 4 needs data from the legacy system, but the system belongs to the other department. And right there the process has a handover: Team 4 is done and has to wait until Department C accepts the work.

So the org chart, the system landscape and the process draw the same line. In the example, the bottleneck sits right on it.

The boundary behind it

If exploiting and subordinating are not enough, the bottleneck is elevated. In the example, that means going to the boundary between Department B and Department C.

Goldratt says that most constraints are policies, not machines. He means things like: who is allowed to decide something, who has to approve something, what a team is measured on. In the example, the policy is who owns the legacy system. Team 4 needs it for its work, but may not change anything and has to ask Department C for every small thing.

Elevating the bottleneck then means changing the boundary, in three places together:

• Ownership: who may decide about and change the legacy system?
• Handover: how does work get from Team 4 to the legacy system, and who waits for whom?
• Interface: how do the legacy system and the other departments’ systems exchange their data?

If only one of these changes, the boundary stays in place in the other two. Afterwards the bottleneck sits somewhere else, as with Herbie, and measuring starts again.

In short

• Every organisation has at least one bottleneck. It determines how much reaches the customer.
• You find it by measuring what each station spends its time on. The bottleneck is the station that never waits. The biggest pile is often somewhere else.
• First exploit the bottleneck and align everything to it. Then elevate it.
• Often the bottleneck is a policy at a boundary between departments. That is where organisation, process and IT hang together.
• Once it is elevated, it moves on. Then you measure again.

Where is your bottleneck?

We start with a measurement. Afterwards you know where the bottleneck sits, where it comes from and what options you have. Write to us or book a meeting directly.

Further reading

• Eliyahu M. Goldratt, Jeff Cox: “The Goal” (1984). The novel with the hike and Herbie.
• Melvin E. Conway: “How Do Committees Invent?”, Datamation, April 1968. The paper Conway’s Law comes from.

Images and other credits!

• Cover image: Photo by Wolfgang Hasselmann on Unsplash