# Execution trap _When results disappoint, look at the system before you blame the people._ --- You've just taken over an operations team. Forty people, good talent, strong individual track records. The board's verdict is blunt: execution failure. Deadlines slip, quality is inconsistent, two product launches came in late last quarter. Your predecessor responded by tightening reporting cadence and adding weekly status reviews. It didn't help. Your instinct is to push harder. Shorter deadlines, more oversight, clearer accountability. The team needs discipline. Before you do, count something. --- You ask each team lead to list every active commitment: projects in flight, requests being worked, items waiting for someone's input. You expect fifteen or twenty. The list comes back at forty-seven. Forty-seven active items across a team that, based on last quarter's completion data, finishes about six things a month. | | | |---|---| | Active items (WIP) | 47 | | Monthly completions (throughput) | 6 | | Implied lead time | 7.8 months | The arithmetic is straightforward. If you have forty-seven things in flight and you finish six a month, everything takes nearly eight months on average, purely because the queue is that long. [[Little's Law]] formalises the relationship: lead time equals work in process divided by throughput. The maths doesn't care whether the work is manufacturing parts or reviewing contracts. More items in the system means longer waits for all of them. The two late product launches weren't execution failures. They entered a queue of forty-seven and took roughly as long as the maths predicted. --- You dig into where the forty-seven came from. Not all at once. They accumulated. A board member requested a competitive analysis. Marketing kicked off a positioning refresh. Sales needed a new demo environment. Finance asked for a revised forecast model. Each request, individually, seemed reasonable. Nobody tallied the running total. You pull up the last quarter's data and count starts versus finishes. | | Q3 | |---|---| | New items started | 19 | | Items completed | 6 | | Net WIP increase | +13 | Nineteen new commitments entered the system. Six left. The queue grew by thirteen in a single quarter. The organisation was starting work faster than anyone could finish it. --- You trace three of the stalled items back to their origin. Each one hit the same wall: a decision that needed sign-off from someone senior, and that sign-off took weeks to arrive. The competitive analysis needed a VP to confirm the scope before the team could begin. The request sat in her inbox for eleven days. The positioning refresh required the CMO to choose between two directions. He asked for more data. The team prepared a follow-up deck. Diaries aligned two weeks later. He picked a direction in the meeting within ten minutes. The forecast model needed the CFO to agree the assumptions. She was travelling. Three weeks passed. None of these delays show up in any project tracker. No ticket says "waiting for decision." But across three items, seven weeks of elapsed time were consumed by decisions, not work. The team prepared what they thought was needed, guessed wrong on emphasis or format, and burned another cycle getting clarity. The bottleneck was decision speed, not execution speed. --- The team you inherited isn't undisciplined. They're working inside a system that fights them. Too much work in flight, so everything takes longer than it should. More starting than finishing, so the queue grows every quarter. Decisions that require weeks of waiting, so even the work that does get attention stalls partway through. Each problem feeds the others: slow decisions create partially blocked work that sits in the queue, inflating WIP, which lengthens lead times, which makes everything feel late, which triggers more status meetings and tighter reporting, which consumes the time that could have been spent finishing things. The response your predecessor chose, more oversight and shorter deadlines, made every one of these dynamics worse. More reporting consumed hours that could have gone to completions. Shorter deadlines didn't change the queue length; they just meant more things were officially overdue. --- The fix starts with the queue, not the people. You cap active work at fifteen items. That means saying no, or more precisely "not yet," to thirty-two existing commitments. Some go to a backlog. Some get killed. The team leads push back at first because every item has a sponsor who thinks theirs matters most. But [[Theory of Constraints|the constraint]] is the same regardless of who's sponsoring the work: the team finishes six things a month, and forty-seven in flight means nothing moves quickly. Within a month the effects are visible: | | Before | After (month 2) | |---|---|---| | Active items | 47 | 14 | | Monthly completions | 6 | 8 | | Implied lead time | 7.8 months | 1.8 months | Completions actually increased. People spent less time switching between tasks, less time waiting for inputs across too many workstreams, and less time sitting in status meetings about items that weren't moving. The implied lead time dropped from nearly eight months to under two. --- The decision bottleneck needs a different fix. You sit with the three senior leaders whose approvals were creating the longest delays and ask a version of the same question: what would you need to see to say yes? The CFO describes the three assumptions she checks in any forecast. The VP explains the scoping criteria she applies. The CMO lists the two questions that determine his positioning calls. None of this was secret. They'd just never written it down. Their teams were guessing at the criteria, preparing materials that were close but not quite right, and burning cycles on revision. Once the logic is explicit, codified into short documents the teams can reference, most of these decisions stop requiring sign-off at all. The team applies the criteria themselves and escalates only the genuine exceptions. Decision speed goes from weeks to days, sometimes hours. Their time shifts from reviewing routine decisions to handling the ones that genuinely require judgement. [[Two halves of trust]] matters here too. The team needs to trust that applying the codified criteria won't get them punished for acting without permission, and the leaders need to trust that the team will escalate the right exceptions. Both sides of that trust have to be built deliberately. Without it, the codified criteria sit in a shared drive and nobody uses them. --- Six months in, the board reviews the same team. Two product launches shipped early. The backlog is shorter than it has been in two years. Quality complaints have dropped. Nobody was fired. Nobody was hired. The same forty people, producing different results, because the system around them changed. The board's original diagnosis was execution failure. Push harder, hold people accountable, demand more discipline. Every element of that response would have deepened the problem it was trying to solve. What the team needed was less work in flight, faster decisions, and a system that rewarded finishing over starting. When you inherit a team that can't execute, count the queue before you tighten the screws. ---