With our intuitions we are often wrong. Here is a small case from the bottleneck theory, where I myself felt this way again. The background is that during the development of our Online Kanban Simulation we have intensively explored the bottleneck theory [1], which is also used in Kanban [2]. Keyword: “Manage the Flow, not the People”. One of its most important statements is “The throughput of the entire system is determined only by its bottleneck”. Sandbox. Funnel. That somehow sounds very logical. I was even more surprised when, during the initial analysis of our test data, we had a case where this principle failed at first sight. But let’s look at it in detail.

Die Ausgangssituation

Here you find a system in which tasks are processed by 4 sequential steps at 4 specialized workstations. There is no limit to the amount of work started. Each station processes as many tasks as it can handle. Between the stations you will find the tasks that are waiting to be processed by the next workstation. 

The throughput of the entire system is “8 completed jobs per minute”. Station 3 is apparently the bottleneck in the system, because it still has 4 things waiting to be processed by it. When we look at the data for Station 3, we notice that this station is processing 9 jobs per minute. So more than the throughput of 8 of the whole system. Is Kanban broken?!? So let’s take a closer look again and get the data for the throughput of each individual workstation in addition.

Detailed analysis

Throughput15 per minute15 per minute9 per minute8 per minute8 per minute

Oops. Station 4 has a lower throughput of 8 jobs per minute than station 3 with 9 jobs per minute. Furthermore, the throughput of Station 4 even corresponds exactly to the throughput of the entire system. Fortunately: Bottleneck theory rescued after all. But what is the reason why work is stacking before station 3 and not before station 4, the actual bottleneck?

A brief consideration about how to determine the amount of waiting work at a workstation may help here. From a station’s point of view, this is the difference between the work that arrives at the station and the work that it processes itself. And if you consider all stations in front of that station as one system, then the well-known principle applies again: “The stations in front of it deliver exactly as much work to it as the bottleneck of this (sub)system can complete”. For our example this looks like this:

Throughput15 per minute15 per minute9 per minute8per minute8 per minute
Growth of
Backlog15 minus 15
0 per minute
15 minus 9
6 per minute
9 minus 8
1 per minute

Even though station 4 is the bottleneck of the whole system, most of the work is stacked up in front of station 3. If someone would offer support to this station or make optimizations here (so that the station manages e.g. 10 instead of 9 tasks per minute), this would have no effect on the throughput of the entire system for the moment. There would still be 8 things “tumbling out” at the end.

Some of the implications

Of course I am aware that these are all very theoretical considerations. But all right, you have read up to this point, after all. For practical purposes, in future I’ll take a second look at it when I think I’ve identified the supposed “bottleneck”. And of course: “Manage the flow, not the people”. I remember some practical examples where there was an intensive focus on specific teams or departments of an organization. Because that is where most of the work was “stacked up”. In retrospect, I am no longer sure whether this was really always the spot with the lowest throughput.


The bottleneck of a system is not necessarily where most of the work stacks up. It is only the workstation that has the highest difference between its own throughput and the throughput of all stations in front of it. There may still be stations in the system with lower throughput, to which this criterion does not apply. If you really want to find the bottleneck, you have to look more closely.


[1] https://en.wikipedia.org/wiki/Theory_of_constraints
[2] https://en.wikipedia.org/wiki/Kanban_(development)

3 Menschen hat das inspiriert