Why Teams That Know What to Do Still Won't Do It
Most execution problems aren't about clarity or skill. They're about teams who've learned that initiative gets punished, so they wait for permission they'll never get.
You’ve seen the pattern. Leadership announces ambitious goals. Product teams nod along in the all-hands. OKRs get written. Roadmaps get built. Then nothing happens at the pace anyone expected.
The post-mortems always blame the same things: unclear priorities, poor communication, misaligned stakeholders. So you add more planning ceremonies. More check-ins. More roadmap reviews. And execution gets worse, not better.
I’ve watched this play out at three different companies now, and the explanation everyone reaches for is always wrong. It’s not that teams don’t understand what needs doing. It’s that they’ve been trained, systematically and accidentally, to wait.
The thing everyone’s saying
Walk into any retrospective where execution lagged and you’ll hear the same diagnosis: teams need clearer direction. More context about the why. Better understanding of the strategy. Someone will inevitably suggest another offsite to align on vision.
This makes intuitive sense. Of course people execute better when they understand the strategy. Of course autonomy requires context. The problem is that most execution gaps don’t come from lack of understanding. They come from lack of permission.
Actually, that’s not quite right. It’s worse than lack of permission. It’s the learned behaviour that comes from having your initiative redirected often enough that you stop taking it.
What I’m actually seeing
Here’s the pattern I keep noticing: a PM spots something important that needs doing. They check with their lead. The lead says “good idea, but let’s run it past the VP first.” The VP says “interesting, can you put together a one-pager?” By the time approvals circle back, either the moment’s passed or someone else got told to own it instead.
The PM learns: don’t start things, propose things. Wait for the strategy deck that tells you what’s in scope. Execution becomes a game of reading tea leaves about what leadership actually wants versus what they said they wanted.
I saw this break completely at a mid-stage B2B company last year. They’d grown from 50 to 200 people and suddenly nobody could ship anything without three layers of review. A product designer told me she’d stopped proactively fixing UX issues because she’d learned that any unscheduled work got flagged as “lack of focus” in her next 1:1.
“We kept talking about autonomy in our values deck while training everyone to ask permission for everything that mattered.”
The execution gap wasn’t about skill or clarity. Everyone knew what good looked like. They just knew that doing it without explicit air cover was more dangerous than waiting.
The ownership paradox nobody mentions
Here’s what makes this hard: you can’t grant ownership. That’s not how it works. You can assign responsibility, but ownership is something people take. And they only take it when the environment proves it’s safe to do so.
Most companies try to close the execution gap by pushing ownership down. “You own this now,” leadership announces, as if saying it makes it real. But ownership without authority is just accountability with extra steps. You get all the blame when things go sideways, none of the room to make calls that might prevent it.
I’m reminded of a conversation with an engineering lead at a company that had just reorganised into squads. They’d copied Spotify’s model (everyone copies Spotify’s model) and declared teams fully autonomous. Except teams still couldn’t choose their own tooling. Or adjust their roadmap mid-quarter. Or decline features that made no sense for users. They had ownership of delivery, not decisions. Which meant they had neither.
The execution gap widened because now teams felt accountable for outcomes they couldn’t actually control.
What actually builds ownership (and why it’s uncomfortable)
The teams I’ve seen close execution gaps didn’t do it through better planning. They did it by making the space genuinely unsafe for inaction and genuinely safe for initiative.
That sounds contradictory because it is. You need both. Letting poor performance slide kills execution just as surely as punishing smart risks. But here’s what companies miss: most teams know the difference. They know when they’re being lazy versus when they’re being cautious. The problem is their management doesn’t trust them to know.
I watched a director at a fintech startup fix this in a way that felt almost reckless at the time. They told their product team: if you spot something broken that’ll take less than a week to fix, just do it. Don’t ask. Document the decision and the reasoning, but don’t wait for approval. They’ll argue about it in the next product review if it was wrong.
The first month was chaos. Teams shipped things that overlapped. A few initiatives went nowhere. But something shifted. People started taking responsibility for gaps they noticed instead of filing them under “someone should probably look at that eventually.”
The director got questioned in the exec meeting about why their team’s roadmap looked so messy. Their answer was perfect: “Because we’re solving problems as we find them instead of waiting for quarterly planning to tell us it’s okay to care.”
The artifact nobody looks at
Want to diagnose whether you’ve got an ownership problem? Look at your Slack threads. Not the public channels where people perform productivity. The DMs and private channels where actual work coordination happens.
If you see lots of “checking if it’s okay to...” or “who owns the decision on...” or “just want to make sure we’re aligned before...”, you’ve trained people that initiative requires permission. If you see people explaining decisions they’ve already made and asking for feedback on execution, you’ve built space for ownership.
The execution gap shows up in the questions people ask before they start, not in the work they do after.
What this reveals about how product teams actually work
Most execution frameworks assume rational actors operating in rational systems. You set clear goals, provide sufficient context, remove blockers, and teams execute. Except teams aren’t optimising for execution. They’re optimising for survival in whatever organisational environment they’re in.
If the environment punishes wrong bets more than it rewards right ones, teams won’t bet. If it rewards visible activity over meaningful progress, teams will perform busyness. If it requires consensus before action, teams will wait for consensus.
You can’t fix execution without fixing what the system is actually selecting for. And in most companies, the system is selecting for risk avoidance dressed up as alignment.
Part of me thinks this is why small teams move faster, and it’s not about communication overhead. It’s that there aren’t enough layers for initiative to get lost in. When you see a problem and the only person to check with is sitting next to you, ownership is the default state. Add three approval layers and waiting becomes the default.
The bit I’m still figuring out
Here’s where I get stuck: how do you scale genuine autonomy without descending into chaos? Because the companies I’ve seen pull off high ownership at scale all did it differently. Amazon’s written narratives create space for deep thinking before decisions. Stripe’s operational rigour means you can move fast because the rails are solid. Neither tried to copy the other.
Maybe that’s the point. You can’t template your way to ownership. You have to build the specific conditions where your teams stop waiting and start deciding. Which means the playbook everyone’s looking for doesn’t exist.
The execution gap closes when teams believe taking initiative is less risky than waiting for direction. Everything else is just coordination theatre.