# Flow and bottlenecks *Focus on the true constraint* --- How long work takes is set by how much work is in the system, not by how hard anyone is working. For any stable system: $W = \frac{L}{\lambda}$ Wait time equals work-in-progress divided by throughput, under remarkably general conditions. If throughput is roughly fixed - and in most organisations it effectively is - then every extra item started lengthens the wait for everything else. A new initiative feels costless on the day it's launched; the law says it taxes every other piece of work in the building. [[Execution trap]] builds its whole argument on this: forty-seven items in flight against six completions a month predicts eight-month lead times before you've looked at anyone's performance. The second half of the idea is Goldratt's: every system has one constraint that sets its output. Improve the constraint and everything improves; improve anything else and you've made no difference, however busy it looked. An hour lost at a bottleneck is an hour lost forever; an hour saved anywhere else is a mirage. Most systems are sequential and multiplicative, not additive, which is why improving everything by a little mostly improves things that were never the limit - [[Marginal gains, sometimes]] works that arithmetic. The fastest fixes usually amount to making the queue visible. In one business, the paperwork we needed to get paid sat in piles on desks, because completing it felt like an end-of-the-day job and nobody had connected it to the cash cycle. We set up a row of physical boxes, one per stage, and moved each piece of paper along as it was processed. Time to submission fell from over ninety days to under thirty. And when the constraint is a person rather than a process, the fix I keep returning to is a gate: put yourself in front of the load-bearing colleague and take the requests first. Some of the volume disappears as soon as someone with context pushes back or asks what it's for; the rest can be merged into bigger blocks and given honest delivery dates, which lets the people asking manage their own leaders' expectations. Two quieter corollaries. Running everything at full utilisation looks efficient and isn't: a system loaded past about three-quarters of capacity, with any real variability in it, hits failure modes - queues explode, quality drops, people burn out. Slack is not waste; it's what absorbs variance. And the same logic applies to change itself: an organisation can only digest work at some rate, so part of the leader's job is to sit on ideas and release them at a pace the machine can absorb, rather than lobbing in a new initiative while the last one is still half-swallowed. ---