Too Many Cooks: How Approval Culture Is Quietly Neutering Your Engineering Team

Here's a scenario that'll feel familiar to anyone who's worked at a software company past Series B: a senior engineer — someone you hired specifically for their judgment — spots a performance bottleneck that's been degrading the user experience for weeks. They know exactly how to fix it. They've fixed things like this a dozen times. But before they can touch production, they need a ticket approved by a product manager, reviewed by a security lead, cleared by the VP of Engineering, and scheduled into the next sprint cycle.

Two weeks later, the fix ships. The engineer has moved on emotionally. And somewhere in that gap, they quietly updated their LinkedIn.

This is the permission problem. And it's eating your product from the inside out.

When Risk Management Becomes Risk Theater

Organizations don't build bloated approval hierarchies out of malice. They build them out of fear — usually after something went wrong. A bad deploy took down the site. A rogue feature confused customers. A rushed release introduced a compliance gap. So leadership adds a checkpoint. Then another. Then a committee to oversee the checkpoints.

Before long, the governance structure designed to prevent bad outcomes is actively preventing good ones.

The irony is brutal: the same risk-averse culture that's supposed to protect the product is often what's causing it to fall behind. Every week your release cycle slows down is a week your competitor — the one with a leaner process — is shipping, learning, and iterating. You're not reducing risk. You're transferring it from the known (a bad deploy) to the invisible (losing ground in the market).

And the market doesn't grade on a curve.

What This Actually Costs You

Let's get concrete, because this isn't just a morale issue — though it is absolutely a morale issue.

Velocity drag. Studies on software delivery performance, including the annual DORA (DevOps Research and Assessment) reports, consistently show that elite-performing engineering teams deploy to production multiple times per day with change failure rates lower than low-performing teams that deploy monthly. More checkpoints don't mean fewer failures. They mean slower recovery and less learning.

Talent bleed. The engineers who can tolerate a fifteen-step deployment process are, almost by definition, not your best engineers. Your best engineers have options. They'll spend about six months in a permission-heavy environment before they start taking recruiter calls. You hired them to solve hard problems, and instead you've handed them a bureaucratic obstacle course.

Missed windows. Software markets move fast. The window for a feature to be competitively differentiated can be measured in months, sometimes weeks. When your internal approval process outlasts the market opportunity, you're not shipping features — you're shipping history.

The Companies That Got This Right

The good news is that some organizations have actively dismantled these structures and lived to tell about it.

Spotify's infamous "squad model" — love it or critique it — was fundamentally an experiment in distributed ownership. The idea was that small, autonomous teams should have the authority to make decisions within their domain without escalating every judgment call upward. When it worked, it worked because engineers felt genuine ownership over outcomes, not just tasks.

Amazon's "two-pizza team" philosophy operates on a similar principle: if a team can't be fed by two pizzas, it's too big to move fast. Smaller teams with clear mandates and real autonomy ship better work because they're not spending half their cognitive bandwidth navigating internal politics.

Neither model is perfect, and both require a cultural foundation of trust and accountability that doesn't appear overnight. But the directional lesson is consistent: autonomy, paired with clear guardrails, outperforms approval chains every time.

So What Does a Better System Look Like?

Dismantling approval culture doesn't mean going full cowboy. It means replacing permission-based systems with accountability-based ones. Here's the practical difference:

• Permission-based: You need three approvals before you can deploy.
• Accountability-based: You can deploy, and you own the outcome.

That second model only works if you have the infrastructure to support it — feature flags, automated testing, fast rollback capabilities, and real-time observability. For SaaS companies, this is table stakes. If your platform can't detect and revert a bad deploy within minutes, you haven't earned the right to move fast. Fix the infrastructure, then loosen the process.

You also need to recalibrate what "risk" means at your organization. Not every change carries the same risk profile. A copy tweak on a marketing page is not the same as a schema migration on your payments database. Treating them identically — running both through the same approval gauntlet — is how you end up with engineers spending thirty minutes in Slack trying to get a button color changed.

The Real Question

Here's what leaders at software companies need to sit with: if your best engineers are shipping mediocre work, is it because they're mediocre? Or is it because you've built a system that rewards caution over craft?

Most of the time, it's the system.

Smart software companies understand that their competitive advantage lives in the people who build the product. Protecting that advantage means protecting those people's ability to do meaningful work — not shielding them from responsibility, but trusting them with it.

The permission problem isn't unsolvable. But it does require leadership to look honestly at the processes they've built and ask a hard question: are these systems here to protect the company, or to protect the people who created them?

Usually, it's a little of both. And that's exactly where the work starts.