Every review step an organisation adds gets justified the same way: it's cheap insurance against a mistake that would cost more than the review does. Taken one at a time, that's usually true. Taken together, across every team that has independently reached for the same justification, it produces something nobody actually decided on purpose — a queue.
Free at the point of decision, expensive in aggregate
The trouble with "this review is basically free" is that it's evaluated locally, by the person adding it, against the cost they can see: a bit of extra latency on this one change, in exchange for catching a class of mistake they've personally been burned by before. That's a reasonable trade from where they're standing. What they can't see, because it isn't their job to see it, is every other team that made the identical reasonable trade, and what all of those trades add up to for anyone whose work now has to pass through five separate approval gates instead of one.
Nobody sat down and decided the platform team should require four sign-offs to ship a config change. It accumulated: a security review added after one incident, an architecture review added after a different one, a compliance check-in added when a regulator asked a hard question, a senior engineer sign-off added because a junior engineer once shipped something that shouldn't have gone out. Four decisions, four different meetings, four different people, each one locally correct and each one blind to the other three.
A queue isn't a policy. It's the residue of every review anyone ever added and nobody ever removed.
Mistaking the queue for the standard
Here's where it gets expensive in a way that's easy to miss: once the queue exists, people start treating its length as evidence of rigor. "We have a thorough review process" becomes a sentence about how many gates a change has to pass, not about whether any given gate is actually catching the class of problem it was built for. Those are different claims, and conflating them is how an organisation ends up with a five-step approval chain that still lets real problems through, because the gates were sized for defensibility — "we can point to the process" — rather than for actually catching the failure mode each one was originally added to catch.
I watched a team spend three weeks getting a low-risk config change through review, not because anyone thought it was genuinely risky, but because it had to pass through every gate that had accumulated over two years regardless of what it actually touched. Meanwhile a much riskier change, in an area none of those gates had been built for, sailed through in two days because it happened not to trip any of the specific triggers the queue was built around. The queue wasn't measuring risk. It was measuring which historical incident the change happened to resemble on paper.
Pricing review instead of assuming it's free
The fix isn't "remove all the gates" — some of them are catching exactly what they were built to catch, and removing them blind just reintroduces the original incident. The fix is treating review capacity as a budget rather than a bottomless resource that costs nothing to draw on, the same way you'd treat any other scarce thing a team relies on.
Concretely, that means auditing what each gate actually catches against what it costs in calendar time, at least once a year, and being willing to remove or merge gates that have stopped paying for themselves. It means routing changes by actual risk rather than by category — a one-line copy change and a database migration should not default to the same four approvals just because they both touch the platform team's codebase. And it means making whoever wants to add a new review step also own its removal criteria up front: under what condition would we take this gate back out. Most gates that get added never get asked that question, which is exactly why they never leave once the incident that justified them has been forgotten.
Review isn't free, and every team that treats it as free while adding one more gate is making a locally sensible decision that collectively produces a queue nobody designed and nobody's accountable for shortening. Pricing it explicitly is the only way I've found to stop the queue from quietly becoming the standard.