How many approvals before you stop caring?

If you need approval for something, that something is already broken.

The argument is that approvals ensure quality and reduce risk. The reality is that they mostly just slow things down. The more approvals you add, the less people think for themselves. The less they think for themselves, the more approvals you need. Before you know it, the team is trudging through a swamp of bureaucracy, waiting for someone to nod sagely and let them continue.

This is how teams quietly lose momentum, lose their edge as it were, one approval at a time.

Approvals are just mistrust in fancy clothes

An approval step is never just a step. It is a statement about how much trust you actually have in your team.

If you need code reviews, it means we do not trust you to follow our standards. If you need approval for architecture decisions, it means we do not trust you to design something maintainable. If you need to ask before taking time off, it means we do not trust you to balance your workload. If you need expense approvals, it means we do not trust you to make reasonable financial decisions. If you need hiring approvals, it means we do not trust you to choose the right people.

The hiring one is particularly maddening. You hire a manager because you trust them to build a team, then force them to beg for every new hire. By the time they navigate the approval labyrinth, the best candidates have taken jobs elsewhere. A spectacular self own.

Individually, these all sound reasonable. Together, they create a culture where nothing moves without permission.

The numbers tell you everything

Before you defend your approval process, measure it.

How many approvals does it take to merge a one line change? How often do approvals actually change the outcome? How long does work sit in waiting for review? How long does hiring take because of approval delays?

If approvals are not stopping bad decisions, they are just slowing down good ones.

The best teams do not ask for permission, they all for context

Mature teams do not need approval for every step. They need information to make decisions themselves.

Instead of requiring code approvals, document clear standards and let engineers hold each other accountable. Instead of big architecture reviews, use open architectural decision records. Instead of vacation approvals, trust people to plan their time responsibly. Instead of expense approvals, set clear budgets and let people use them. Instead of hiring approvals, give managers a hiring budget and let them hire when needed.

The very existence of that approval step could also indicate something is broken in your system. Sure, you say you want approval from all the teams before making an architectural change. Why? Because you may unintentionally break some functionality somewhere. Is that then good design?

Approvals do not create strong teams. Trust does.

Approving wisely

This post is deliberately obtruse, pushing the point. Some approvals are useful. Some even save entire teams from disasters. But the question is which approvals actually help and which just exist because they always have.

Look at your approval processes.

If everything always gets approved instantly, why does the step even exist? If everything always gets rejected, your team is not aligned. If approvals take forever, the problem is not the work, it is the process.

If approvals must exist, they should be lightweight and intentional.

Only require approval for high risk decisions. Launching a security protocol might be a good idea. Changing a button color should not require a committee.

Push approvals down to the people closest to the work. If an engineer is blocked waiting for a director’s approval on a one line fix, something is very wrong.

Use disagree and commit instead of endless loops. If there is a real disagreement, hash it out, make a call, move forward.

Timebox approvals. If something sits waiting for approval for more than a day, default to yes unless someone actively intervenes.

Automate whatever you can. If small expenses require approvals, just give people prepaid budgets. If hiring approvals slow you down, allocate headcount budgets per quarter and let managers handle it.

If an approval does not add clarity or improve decisions, it is just a tax on momentum.

How many approvals before you stop thinking?

Some bureaucracy is inevitable. The world runs on checks and balances. But every approval step should be treated with suspicion. It is a tax on speed, trust, and ownership.

Does it actually prevent bad decisions or just delay good ones? Does it help people think more critically or just push responsibility up the chain? Does it ever change the outcome or is it just there for show?

I hope this post makes you measure the approvals in your system. If they make the team stronger, keep them. If they only add friction, kill them execution style.

Look at your processes. Count the steps. Count the wasted time. Count the moments where people stop thinking and start waiting.

And then ask yourself. At what point do we stop moving forward.