Approval rules are only useful if they improve judgment. If they merely add friction, people route around them. If they are too loose, they become theater.
The minimum useful rules
- No self-approval on changes that affect permissions, payments, or infrastructure.
- At least one reviewer who understands the relevant subsystem.
- All required checks green at the same commit that is about to merge.
- No stale approvals after major follow-up edits.
When stricter rules help
Stronger rules make sense when the cost of a bad merge is high. Security-sensitive services, release branches, and anything that touches customer data deserve more than a casual thumbs-up.
When stricter rules hurt
- Small fixes get stuck waiting on unnecessary sign-off.
- Reviewers approve without reading because the process is too repetitive.
- Teams learn to optimize for passing the gate, not improving the code.
The balance
Good approval rules act like guardrails. They keep the obvious mistakes out while still letting real work move. If people complain about the rules, that is useful signal. It usually means the policy is either too broad or too vague.