We added two people and nothing came out any faster

It is one of the most common complaints in operations, and it is usually reported as a mystery. Two more people were added to a team that was visibly overloaded, and a month later the output is the same. The people are busy. The work is not coming out faster.

There is no mystery. Capacity and throughput are different quantities, and only one of them was changed.

The two numbers

Capacity is what a step could process in an hour if it never waited for anything. It is a property of the step: the people, the machines, the hours they are staffed for.

Throughput is what actually comes out of the whole process in an hour. It is a property of the system, and it is set by the slowest step, not by the average of the steps.

Adding people adds capacity at one step. It adds throughput only if that step was the one setting the pace.

---

	Intake, capacity per hour	30
	Assessment, capacity per hour	12
	Review, was 20, now	34
	Despatch, capacity per hour	25
	Throughput, was 12, now	12

Illustrative figures. Review went from 20 an hour to 34 and the process still produces 12 an hour, because assessment produces 12 an hour and always did. The two people are real, they are working, and the output is unchanged.

The line did not get faster because the thing setting its speed was not touched. Everything else in the process can only run as fast as it is fed.

Why the busy signal is misleading

The reason the two people went to review is that review looked overloaded. It probably was, in the sense that people there were working flat out and a queue was sitting in front of them.

But a queue in front of a step does not mean that step is the constraint. It usually means the step upstream of it releases work in bursts, or that the step itself has variable handling times, or simply that the queue has nowhere else to accumulate. A constraint has a queue in front of it. So do plenty of steps that are not the constraint, and the difference is not visible from the size of the pile.

The constraint in the table above is assessment, at twelve an hour. It may have no visible queue at all if intake is releasing work slowly, and the people there may not be the ones complaining.

Finding the one that matters

You do not need a model to find it. You need the capacity of each step in the same units, per hour, over the same window, and then the smallest number wins.

The awkward part is that the units have to be honest. A step staffed for eight hours that is actually available for six, once breaks, handovers and the meeting are taken out, has a capacity of six hours’ worth. A step that is shared with another process only has the fraction of itself that this process gets. Most first attempts at this table are wrong because the availability was assumed rather than measured, and the effect is always in the same direction: real capacity is lower than stated capacity, everywhere.

What to do with it

Build the capacity table before adding anybody. Every step, per hour, on the same clock, with availability measured rather than assumed. It usually takes an afternoon and it usually surprises somebody.

Then add capacity only at the smallest number, and stop when it is no longer the smallest. Adding four people to a step that needed two just moves the constraint somewhere else and buys nothing for the extra two.

And expect the constraint to move. It is supposed to. Fix assessment at twelve and the process runs at twenty five, set by despatch, and the table you built is now out of date. That is not a failure of the exercise, it is the exercise working, and it is covered in why the constraint moves after you fix it.

The question is never how busy a step is. It is what the smallest number in the table is, and whether the money is being spent on that one.