The productivity–reliability paradox

Concept one

Efficiency eats the buffers that were absorbing your faults

Between any two stations sits some slack — a queue of parts, a bank of work, an hour of finished stock. It looks like waste, and by one reading it is: it is capital sitting still.

But that slack has a second job nobody wrote down. It absorbs variation. When the upstream machine stops for four minutes and there are ten minutes of parts in front of the downstream one, the downstream station never notices. The fault happened and cost nothing.

Now remove the buffer, because it was waste. The same four-minute stop is now a four-minute stop everywhere downstream of it. Nothing about the machine got worse. The fault did not grow. What changed is that the organisation lost the thing that used to make small faults invisible.

This is why tightly-coupled plants report failures that seem wildly out of proportion to their causes. A sensor wipe takes ninety seconds and halts four stations, because each one is now directly connected to the last.

The lesson is not that buffers are good and lean is wrong. It is that a buffer is insurance, and removing insurance is only safe once you have removed the risk it was covering. Reliability first, then coupling. A plant that tightens coupling before it has fixed its six losses has not become efficient; it has become brittle, and it will find out on a Tuesday.

Concept two

The last few points of utilisation cost the most

There is a piece of arithmetic behind this, and it is worth knowing even approximately.

In the simplest queueing model — one machine, arrivals and job times that vary randomly — the average time a job spends waiting and being served is its service time multiplied by 1 ÷ (1 − utilisation).

At 50% utilisation that multiplier is 2. At 80% it is 5. At 90% it is 10. At 95% it is 20. At 98% it is 50.

Read those numbers again. Going from 90% to 95% utilisation feels like a five per cent improvement, and it doubles how long everything takes to get through. The curve is not a slope; it is a wall, and every plant that has ever been pushed to "sweat the assets" has walked into it.

The caveat matters, so here it is plainly: a real production line is not that simple model. Your exact multiplier will differ. What transfers is the shape — delay does not rise gently with utilisation, it accelerates, and near the top it becomes unbounded. Treat these as orders of magnitude, not as a prediction for your line.

The same shape governs recovery. If you lose an hour of output and you were running at 95% of capacity, the only spare you have to catch up with is that last 5% — so an hour lost takes about twenty hours to make back. At 70% utilisation the same hour takes about three. This is why highly loaded plants never seem to recover from anything: they genuinely cannot.

Concept three

The same paradox, now in work with no machines in it

A tool arrives that makes a knowledge task several times faster. Drafting, coding, analysis, correspondence. Output per person rises immediately and visibly.

What it consumed to do that is the same thing the plant consumed: the slack in which the work used to get checked. The time between producing something and sending it — when it was re-read, questioned, noticed to be wrong — was buffer. It looked like waste too.

So the arithmetic that decides whether the tool actually helped is not the speed-up. It is the speed-up minus the verification tax: how often the output needs correcting, and what a correction costs. A task cut from thirty minutes to five is a large gain until one output in four needs twenty minutes of repair, at which point you have gained almost nothing and added a failure mode.

And the failure mode is the dangerous half. A machine that breaks stops, loudly. Work that is subtly wrong ships. It is the rework problem from lesson five, at a scale where nobody is counting: fluent, confident, plausible output that is defective in ways the person accepting it is now moving too fast to notice. First pass yield falls and nothing in the reporting shows it.

Which is exactly why this is a TPM problem and not a technology problem. The discipline already exists. Measure the losses honestly, count rework as a loss, protect the conditions under which good output happens, and never tighten the coupling before you have earned the reliability. Lesson ten gives that discipline a name and applies it to capability itself.