Distributed Veto Power (and the Death of Speed)
A one-day feature turned into eight because too many people had the power to slow it down. Speed isn’t lost in engineering. It leaks through organizational cracks.
I keep coming back to this one moment that still annoys me more than it should. We had a super simple feature - literally a one-day job. Clean scope, no heavy decisions, no dependency on anything cosmic. We were ready to ship.
Then the organism we call “the organization” woke up.
Suddenly, someone looped in legal. One of them even said, “Just a quick check, shouldn’t take long.”
Someone else said we should ask the client. “Let’s align expectations before we build anything.”
Another person added compliance “just to be safe.” Compliance replied, “We’ll need a short note on why this won’t affect data flows.”
Someone from ops wanted to confirm an edge case. “There was a similar ticket last year, let me find the thread.”
No one was wrong individually. But together they created a slow-moving traffic jam where a one-day feature stretched into eight.
By day four, the feature wasn’t stuck on engineering complexity. It was stuck on people waiting for people who were waiting for people. Eight days total. Not because of complexity, but because of how many same-level people injected themselves into the decision chain. Each one taking one step. Each step adding a full day of waiting.
Why Teams Slow Down as They Grow
This is the part that honestly breaks my brain. It’s not malice. It’s not incompetence. It’s structural. The system is designed in a way where momentum dies the moment too many people feel responsible for “being informed.” You don’t notice this when the company is small. But once headcount grows, timelines bloat automatically.
At scale, everyone is always partially available. 14% here, 12% there. Nobody owns anything fully, but everyone has veto power. And when you combine fragmented bandwidth with distributed veto power, you get this weird gravity where work just... slows. Not dramatically. Not in ways that trigger alarms. But in quiet ways, like how a river slows down when too many rocks appear.
It’s the same story everywhere. A startup team of three ships a feature in 11 days. A big team with fully staffed pods takes seven months for the exact same thing. Not because the feature magically became harder, but because the system created queueing at every step. Meetings. Reviews. Slack threads. Steering groups. Approvals.
When Process Becomes the Product
The crazy thing is how normal this feels inside large organizations. We’ve normalized delay. We call it "process" instead of admitting it’s drag. People stop questioning why a two-week feature is estimated at twelve. They assume it’s reasonable. Expected even.
But it’s not. It’s a symptom of a model that’s fundamentally broken. A model inherited from the 1990s that still believes more people equals more power. When in reality, more people equals more waiting.
To make this real, I once saw my team estimate eight weeks for a two-screen feature because three different leads needed to review the flow. None of them actually changed anything.
Legacy structures operate with a worldview where a project manager updates a Gantt chart and believes that equals progress. They add layers under the illusion of safety. More meetings means more alignment. More approvals means reduced risk. But these are illusions. None of them meaningfully move the product forward. They only multiply the number of blockers standing in the way.
The 8-Week Warning Sign
The harsh truth is this:
"Any feature that takes more than eight weeks has nothing to do with the feature and everything to do with the org."
If your team consistently ships in two months, it’s because the organisation is intentionally or unintentionally optimised for six-month shipping. The slowness isn’t accidental. It’s baked into how decisions are made, how responsibilities are distributed, and how many checkpoints exist by default.
Startups ship faster not because they’re smarter, but because survival forces clarity. It forces ownership. They cut nonsense out of necessity.
How to Break This Cycle
Here’s the part I’ve learned the hard way: waiting for the structure to fix itself is a fantasy. The only way to break this cycle is to step in and manually collapse the unnecessary layers.
When I see a one-day feature turning into an eight-day debate, I don’t call a meeting to discuss the delay. I remove the blockers myself. I tell the team: “We aren't waiting for that approval. I’ll take the heat if it goes wrong. Ship it.”
Your job as a leader isn’t to preserve the process. It’s to protect momentum. That often means absorbing the risk so the team doesn’t have to, making the decision in the room instead of waiting a week for consensus, and cutting the dependency chain before it grows fangs.
Speed is a choice. And sometimes that choice comes down to one simple question: Are you willing to be uncomfortable so the team can move fast?
If the answer is no, you haven't fixed the bottleneck. You've become one.