A system optimised in parts performs badly as a whole

Local optimisation, and why it reliably damages the whole.

A system optimised part by part very often performs badly as a whole because improving one piece in isolation almost always shifts cost, delay or friction onto whatever that piece happens to connect to, and a collection of individually excellent parts, each one optimised without any real reference to how it actually interacts with its neighbours, very often adds up to a noticeably worse system than a collection of merely adequate parts chosen with the whole arrangement in mind right from the outset.

The mechanism behind local optimisation

Optimising a single part of a larger system means making a decision that improves some measurable property of that part, speed, cost, efficiency, judged entirely on its own terms, without much reference at all to what the part is actually connected to on either side of it. That narrow judgement is exactly where the trouble starts, because almost nothing in a real system exists in isolation, and a change that genuinely improves one part in isolation frequently does so by demanding something extra from whatever sits next to it, a faster machine that produces work faster than the next station downstream can possibly absorb, a cheaper component that saves money at its own point of use while quietly making the next assembly step slower, fussier, or less reliable than before. The whole system's actual performance is set by how well the parts work together as a group, not by how well any one of them performs measured entirely alone, and local optimisation, by its very definition, never even asks that second, far more important question.

The shared-kitchen comparison

A house shared by several people demonstrates this same failure in miniature nearly every single week of the year. Each person, acting entirely reasonably from their own point of view, optimises their own routine by leaving dishes to soak rather than washing them immediately after cooking, since leaving them for later genuinely is the faster, easier option for whoever happens to be standing at the sink in that particular moment. Every individual decision is entirely locally sensible, saving that person a genuine few minutes exactly when they made it, and yet the kitchen, considered as a whole shared system rather than as a series of individual choices, ends up perpetually cluttered, with everyone spending more combined time working around a mess than the sum of the few minutes any single person ever actually saved. Nobody in the house made an obviously bad decision at the moment they made it, and the system still performs worse than it would have if even one person had optimised for the shared kitchen as a whole rather than for their own particular five minutes standing at the sink.

Why the connections matter more than the parts

Because a system's overall performance depends on how its parts hand work to one another, the connections between parts, an interface, a handoff, a shared resource everyone draws on, deserve at least as much design attention as the parts themselves, and very often receive far less, since a connection rarely shows up as clearly on anyone's list of responsibilities the way an individual part does. A factory floor, a piece of software, or a shared kitchen can each have every one of its individual components working exactly as intended and still perform poorly overall, because the actual bottleneck was never inside any single component, it was sitting quietly in the handoff between two components that nobody had been specifically assigned to optimise, and that nobody therefore ever thought to look at closely until the whole system's poor performance forced the question.

The number that matters here

A single station on a production line sped up to run a large amount faster than before, sometimes doubled in throughput at real cost in new equipment, can leave the line's overall output completely unchanged if a different station further along was already the limiting step, since the faster station simply produces a growing backlog of unfinished work waiting in front of whatever comes next, all the local improvement converted into idle inventory rather than into anything the finished system actually gains.

What this does not explain

None of this means that improving individual parts is always wasted effort, since a part that genuinely is the whole system's limiting constraint absolutely deserves every bit of attention that gets spent improving it, and the argument here is specifically about parts improved without checking whether they were the constraint in the first place. Telling the two situations apart, a part genuinely worth optimising because the whole system is waiting on it and a part not worth optimising because something else entirely is what the whole system is actually waiting on, requires looking at the system as a whole before deciding where to spend the next unit of effort, which is precisely the step local optimisation, by its very nature, always skips.

Why this matters in practice

Goldratt's The Goal builds an entire argument around exactly this insight, told through a struggling factory manager rather than through a textbook, that a factory's true output is set by its single slowest constraint rather than by the average efficiency of every station added together, and that improving anything other than that one constraint, however genuinely improved it becomes, changes the factory's overall output by nothing at all. Recognising local optimisation as a trap rather than a virtue changes where effort gets spent in any real system, moving attention away from whichever part is easiest to measure and improve in isolation and toward the actual constraint limiting the whole, along with the connections between parts that a purely part-by-part view of the system was never designed to notice in the first place, whether that system is a factory floor, a piece of shared software, or a kitchen with more than one name on the lease.