Bottleneck

Complaints that a product ships slowly are old. A word for where it ships slowly is newer. Without one, the response was always the same: everyone moves faster. Engineers worked late, designers cut the number of mockups they produced, and the time it took for a single feature to reach customers did not change at all.

The weekly meeting kept landing in the same place. Someone asks why only three things shipped again this week. The engineer says their part was finished on Tuesday. The designer says the mockups went over on Monday. Nobody was late inside their own stage, and three things shipped. Nobody was lying, and nobody knew where to look.

Bottleneck is the name for that place. Instead of pushing evenly on everyone, it says to find the single slowest stage and work on that one. The word spread alongside Kanban, a way of working that draws the flow where everyone can see it and caps how much work sits in progress at once. Until the stages are drawn out separately, there is no way to measure which of them is slowest.

What a flow delivers equals what its slowest stage delivers. That holds no matter how fast everything on either side of it runs.

A feature at Pagedeck passes through planning, design, development, code review, and QA before it ships. Code review is the step where a colleague reads a change before it gets merged. Suppose the weekly capacity of each stage is eight for planning, six for design, five for development, and two for review. Two features ship that week. The surplus the first three stages produced just queues up in front of review. A bottle's body can be as wide as you like, and the neck still decides how fast the water comes out. That is where the word comes from.

Three symptoms show up together in a flow that has one.

1. Work piles up in front of the stage. On a Kanban board, where each item is a card sitting in a column for its current state, the "waiting for review" column swells to nine cards.
2. The stage behind it goes quiet. Whoever handles QA has nothing arriving and spends the time helping another team.
3. Speeding up any other stage changes nothing overall. Add two engineers and lift development capacity to eight, and two features still ship.

Finding the bottleneck is a measurement, not a hunch, and two measurements do it. The first is a gap between two clocks. Lead time runs from the moment a request arrives; cycle time runs from the moment someone actually starts on it. A lead time of nine days against a cycle time of two means seven days were spent standing in line. The share of those nine days that was real work — two of them — is flow efficiency. The second is a cumulative flow diagram, which stacks the number of cards in each state over time. When one band thickens day after day, more is entering that column than leaving it.

A bottleneck does not stay put. Once review handles six a week, development at five becomes the slowest stage and the whole flow settles at five. This is not something a team fixes once.

Any flow where something passes through several stages on its way out can have one. The word is not specific to building software.

In hiring, a team can screen forty applications a week and still meet only twenty-four candidates a month if interviewers have six slots a week. Sourcing more applicants does not produce more hires. In sales, thirty demo requests a day still convert at the speed of the one person reviewing contracts.

There are three broad ways to work on a bottleneck once it's identified.

1. Raise the capacity of that stage. Add people, automate something that was being done by hand, or split work that one person had been carrying alone.
2. Reduce what flows into it. Put a WIP limit — a cap on how many cards a column may hold at once — on the column before it. If that column tops out at three, someone with free hands helps clear the review queue instead of starting something new.
3. Arrange for work to skip it. If a one-line copy change goes through full review, change the rule so low-risk changes don't.

The first option comes to mind first and is usually the most expensive. The other two can be tried the same week without hiring anyone.

"Code review is the bottleneck right now. Hiring more engineers won't change how many features ship this quarter."

The place to add people is review, not development.

"Design is the bottleneck this week, so let's not pull more cards into development."

Pulling more work out of an earlier stage only makes the queue behind it longer.

"We added reviewers and the bottleneck moved to QA."

The old constraint is gone and the next slowest stage now sets the pace.

At Pagedeck, Theo was doing nearly all of the code review himself. Changes from five engineers all landed with him, and between his own development work he got through about two a day. When Mia put the cumulative flow diagram up in the weekly meeting, the review queue band had been thickening for three weeks.

It also explained something Noa kept saying, that the mockups always go over on Tuesday and ship much later. Two more people were given review duty, and the limit on the development column was dropped to three. With the cap in place, engineers with free hands cleared review instead of opening new work, and three weeks later the review band was thin. The QA band started thickening instead. The bottleneck had moved to the next stage.

The most common mistake is reading a bottleneck as a person's fault. The same name comes up every time the delay is discussed, so that person looks slow. In fact the flow is arranged so that work collects at that one point, and replacing them with someone faster leaves the same spot blocked again next month. Left alone, the person who keeps getting named burns out and leaves, and the flow stays exactly as it was.

Assuming every stage should be busy all the time is the other one. Idle hands look like waste, so more work gets pulled in to fill them. But filling the stages that aren't the bottleneck doesn't produce more output — it lengthens the queue in front of the one that is. Weekly throughput stays flat while the time any single item takes goes up.