Don't Make Gates Optional, Make Them Flexible
When you need an approval checkpoint but don't want it everywhere, make the gate required but flexible in formality rather than optional but formal. A required gate lowers the stakes of misjudging risk.
The Problem with Optional but Formal Gates
Pam is a product manager driving her team's roadmap. Hopper, the Head of Product, is worried about investing too much into risky or unproven initiatives. A new policy is enacted: all large projects must have a Business Case drafted and presented to him before they land on the roadmap.
Pam sees this and wonders, "What is considered a large project?" Some things fall clearly on either side: a new product offering is large; a refresh of our Settings UI feels small. But then there is a whole list in the middle. Pam worries. "What if I spend time building a formal Business Case for projects that don't need them? Or worse, what if I move forward with a project that leadership decides should have had a Business Case? That seems very risky!"
This type of gate forces an impossible meta-decision on Pam. If she moves forward unilaterally, the risk is on her. If she plays it safe, the whole team slows down waiting for formal approval processes.
Flexible is Better
In an alternate universe, Hopper enacts a different policy: he has approval over all roadmaps but the format of that approval is flexible. For large, risky projects, a Business Case and discussion may still be needed. For smaller or safer projects, a quick DM conversation counts.
At a surface level, this sounds very similar, but consider it from Pam's perspective. The risk has shifted dramatically. Now, Hopper is in the loop even on the smaller decisions. Pam is safe to bias for speed. The worst case is Hopper responds "Actually, I think this warrants deeper discussion; can you set up a Business Case discussion?" And regardless of the nature of the approval, there is an approval. Pam can move forward with her roadmap with confidence.
The flexibility is not incidental here. It's what makes the requirement possible without Hopper becoming an approval bottleneck nor Pam spending long days polishing Business Case documents. Most approvals are lightweight and can be quick (and batched). Attention is reserved for the decisions where it is needed most. A thumbs-up on a DM costs seconds; a missed risky bet costs the team months.
Another Example: Code Review
Software Engineering teams see this approach all the time in a different context: code reviews. Most companies have a policy that any PR needs an approval before it can merge (not optional). The detail in that PR and depth of review is left flexible. Simple bug fixes or dependency updates may have very brief descriptions and a quick stamp ("LGTM!"). More complex PRs warrant more explanation, deeper examination. And if the author misjudges the complexity, the gate catches it: the reviewer says "Hey, can you say more about this change?" or leaves detailed comments, before the code ships.
"Doesn't this just become rubber-stamping?" If your team isn't properly reviewing even when the complexity warrants it, I'm not sure a process change will help. You need to speak to your humans! Alternatively, if the complexity is never high enough to warrant it, hot take: is the approval checkpoint really providing value at all?
There are multiple knobs; use them
The thing to remember is that when a required, formal approval checkpoint feels too heavy, there are multiple knobs you can play with, not just optionality. And in many cases, a required but lightweight checkpoint will help the team move faster and more confidently than removing a checkpoint which leaves the team in an ambiguous, risk-averse state.
Cheers!