The Execution Trap
When results disappoint, the instinct is to blame execution. Usually, the problem is upstream.
The familiar diagnosis
A strategy stalls. A product launch slips. A transformation programme quietly dies.
The post-mortem arrives at a familiar verdict: execution failure. The team didn’t deliver. Discipline was lacking. People weren’t aligned.
This diagnosis feels right because it’s partly true. Someone, somewhere, didn’t do what they were supposed to do. But it misses the question that matters: why not?
Execution problems are rarely execution problems. They’re system problems that surface as execution failures.
The constraint isn’t effort. It’s the environment that effort operates in. Fix the system and execution improves without heroics. Leave the system alone and heroics become unsustainable.
This essay unpacks what’s actually happening when execution fails — and what to do about it.
The decision bottleneck
Start with the constraint that hides in plain sight: decision speed.
Modern teams can ship at pace. Agile boards move tickets daily, CI/CD pipelines deploy in minutes, cloud infrastructure scales overnight. The hands are fast.
Yet big initiatives still drag. Hidden Bottleneck identifies why. The constraint isn’t execution speed — it’s how long decisions take.
Weeks disappear waiting for someone, somewhere, to say yes. Leadership sign-off for a new pricing page: two to six weeks. Cross-function debate on CRM integration: three to five weeks. “Need more data” loops before a product bet: one to four weeks.
No backlog ticket shows “decision pending”. But months vanish. A feature worth significant revenue if launched before September might be irrelevant by Christmas.
The failure mode isn’t lack of effort. Teams are working. They’re just waiting — for clarity, for approval, for the next step to become unblocked.
This looks like execution failure from the outside. Inside, it’s decision latency. The system is slow; the people are waiting.
The invisible queue
Even when decisions flow, another system problem lurks: the hidden queue.
In knowledge work, queues don’t sit on factory floors. They pile up invisibly — in inboxes, contracts awaiting review, features half-built. Because they’re unseen, managers underestimate them.
A request lands. A project starts. A colleague asks for help. Saying yes feels incremental. Surely one more won’t make much difference?
But it does. Expensive Yes makes the maths concrete. Little’s Law states:
Lead time = Work in Process ÷ Throughput
Each extra item lengthens the wait for everything else. Delivery slows, stress builds, costs ripple out. The “cheap” yes isn’t cheap at all.
Teams carrying twice the work they can process efficiently aren’t lazy. They’re overloaded. The system keeps saying yes faster than they can say done.
From the outside, this looks like execution failure — missed deadlines, slipping quality, rising stress. Inside, it’s a capacity problem created by an approval problem. The system lacks the discipline to protect flow.
The starting bias
The queue grows because leaders optimise for the wrong thing: starting.
Stop Starting, Start Finishing captures the pattern. New ideas feel like progress — sharing the next initiative, launching the next project, kicking off the next piece of work. It looks like momentum. It feels decisive. It’s visible.
But the bottleneck isn’t generating ideas. It’s finishing them.
Start ten things and finish two, you learn less than starting three and finishing three. More items in flight means longer cycle times. Half-finished projects, blurred priorities, rising friction.
Manufacturing learned this long ago: feed material into a line faster than it can be processed and the line slows. Knowledge work is the same, only the raw material changed — ideas, requests, initiatives. Arrive too quickly and the system clogs.
From the outside, the team looks slow. Inside, they’re drowning in starts that never finish. The system rewards initiation over completion.
The trust gap
Suppose you fix decision speed and WIP discipline. Work flows faster. Cycle times drop. But there’s still a gap between boardroom and frontline.
You wrestle through a choice, align the room, leave with a decision — and months later, not much has changed. The call wasn’t wrong. The effort wasn’t lacking. Somewhere between decision and delivery, momentum drained away.
Two Halves Of Trust explains the gap. Trust isn’t one thing. Organisations need two distinct elements:
Interpersonal trust — the willingness to be vulnerable, raise awkward truths, challenge assumptions without fear. This produces better decisions. It brings in the market signal, the operational constraint, the customer feedback.
Organisational trust — confidence that the system itself is reliable. Accountability and authority are aligned. Decisions are made in the right place. The scaffolding holds.
Without interpersonal trust, meetings are tidy but shallow. Without organisational trust, decisions dissolve between intention and execution. People hedge, hold back, wait to see if management will reverse course.
This looks like execution failure. It’s actually a trust failure — and trust is a system property, not an individual trait.
The pattern
These four failures share a pattern:
| What it looks like | What’s actually broken |
|---|---|
| Slow delivery | Decision latency |
| Missed deadlines | Queue overload |
| Lack of focus | Starting bias |
| Poor follow-through | Trust gaps |
In each case, the visible symptom is execution. The actual cause is system design.
Blaming execution feels satisfying. It assigns responsibility, implies a fix (try harder), and protects the system from scrutiny. But it doesn’t work. You can’t execute your way out of a system that fights you.
The organisations that execute well aren’t the ones with the most disciplined people. They’re the ones whose systems enable discipline.
System fixes
If execution problems are system problems, the fixes are system fixes.
Codify decision logic. When criteria are explicit, teams prep the right evidence first time. Debate shifts from personalities to thresholds. Parallel prep accelerates. Hidden Bottleneck shows the payoff: approval time at one SaaS firm fell from six weeks to two once they codified their launch checklist.
Make WIP visible. Count active projects, open requests, in-flight deliveries. If it’s more than your team can process in a month, you have too much WIP. Before saying yes, ask what it does to the queue. The maths meets lived reality.
Measure completions, not starts. Track what finishes, not what begins. Completion rate is the signal. Starts are just motion. Most teams, when they start tracking this, discover their start-to-finish ratio is embarrassingly high.
Build both halves of trust. Create space for interpersonal trust — frank debate, awkward truths, vulnerable disagreement. And build organisational trust — clear accountability, aligned authority, reliable systems. One without the other doesn’t work. Candour without structure gives lively debate but little delivery. Structure without candour gives efficient silence.
The compound effect
These fixes reinforce each other.
Fast decisions reduce queue buildup. Lower queues mean faster cycle times. Faster cycle times mean quicker feedback. Quicker feedback improves decision quality. Better decisions build trust. More trust enables faster decisions.
The opposite is also true. Slow decisions create queues. Queues extend cycle times. Long cycle times delay feedback. Poor feedback undermines trust. Low trust slows decisions.
The system either reinforces discipline or erodes it. There’s no steady state.
Most organisations drift toward erosion. Decision latency creeps up, WIP expands, trust erodes. It happens gradually, then suddenly you’re in permanent firefighting mode.
Capacity and Flow makes this explicit: flow is a system property. No amount of individual effort compensates for a system that’s fighting you. The master lever is capacity discipline — but capacity discipline requires decision speed and trust to work.
The leadership implication
This reframes what leaders should focus on.
When execution falters, the instinct is to push harder. Tighten deadlines. Add reporting. Increase oversight. This makes the problem worse. More oversight slows decisions. Tighter deadlines increase WIP. More reporting erodes trust.
The better move is to ask: what’s the system doing?
- How long do decisions actually take? Map the approval chains. Time the loops.
- How much work is in flight? Count it. Make it visible. Compare to capacity.
- What’s the start-to-finish ratio? Are we generating options or completing them?
- Where does momentum drain? Is it trust — interpersonal or organisational?
These questions reveal system constraints. Fixing system constraints produces execution improvement without pushing people harder.
The diagnostic
Before blaming execution, run the diagnostic:
Decision latency — Pick three recent initiatives that stalled. Map how long each decision took. If any exceeded two weeks, you have a decision bottleneck.
Queue overload — Count active work across the team. Divide by monthly completion rate. If the result exceeds eight weeks, you’re overloaded.
Starting bias — Compare starts to finishes over the last quarter. If the ratio is worse than 2:1, you’re optimising for the wrong thing.
Trust gaps — Ask: do people raise hard truths in meetings? Do decisions travel intact from boardroom to frontline? If either answer is no, you have a trust problem.
Most teams that run this diagnostic find at least two system problems. Some find all four.
The good news: system problems are fixable. The fix is design, not effort. And once you see the system, you stop blaming the people.
The shift
Execution problems are system problems. This isn’t an excuse — it’s a diagnosis.
The organisations that execute well aren’t full of superhuman performers. They’re designed to enable ordinary effort to produce extraordinary results.
They make decisions fast because they’ve codified the logic. They protect flow because they’ve made WIP visible. They finish what they start because they measure completions. They turn decisions into action because they’ve built both halves of trust.
The constraint is rarely the people. It’s usually the system the people are operating in.
Fix the system, and execution follows.
This essay synthesises ideas from:
Connects to Library: Theory of Constraints · Little’s Law · Systems Thinking
See also: Reading Guide for the complete collection of Field Notes.