I picked up Eliyahu Goldratt's The Goal expecting to dislike it. It's a business novel from the 1980s about a man trying to save a manufacturing plant, and it has the prose of a training video. I read it because three different engineers I respect had told me to, and they're not the sort to recommend airport management books for fun.
The plot is forgettable. The idea isn't. Goldratt's whole argument is that a system's throughput is governed by exactly one thing at a time: its constraint, the slowest station on the line. Improving anything that isn't the constraint feels productive and does nothing. You can make every other machine twice as fast and ship not one extra unit, because the work still piles up in front of the bottleneck. Worse, local efficiency drives often make things worse, because they fill the floor with inventory that the constraint can't absorb.
I read it on a train in late December, which is a good time of year to think about why a year went the way it did.
The reason it stuck is that our world is full of people optimising the wrong machine. A team spends a quarter shaving milliseconds off a service that was never on the critical path. A pipeline gets a faster build step while everyone still waits forty minutes for a flaky integration suite at the end. We measure utilisation and reward people for keeping every box busy, which in Goldratt's terms is precisely the failure mode: a busy non-constraint is just manufacturing work-in-progress for the bottleneck to choke on.
The discipline the book gives you is dull and useful. Find the constraint. Make sure it's never idle and never starved. Subordinate everything else to keeping it fed. Only when you've genuinely exhausted that do you spend money widening it. And then, crucially, the constraint moves, and you start again, because there is always a new slowest thing.
It maps almost too neatly onto incident work and capacity planning. The on-call engineer is a constraint. The one person who understands the billing service is a constraint, a terrifying one, and "let's make them more efficient" is the wrong instinct: the right one is to stop pouring all the work through them. Code review can be a constraint. The single staging environment everyone queues for is a constraint dressed up as a cost saving.
None of this is subtle once you've seen it, and that's rather the point. The Goal didn't teach me a technique. It gave me a question I now ask before I let anyone, including myself, start optimising something: is this actually the slow bit, or does it just feel good to fix? Most of the time it's the second one. For a paperback that thinks "the cloud" is weather, that's held up remarkably well.