The Button Says Approve. Nothing in Your Organization Says What That Certifies.

Open any pull request in your organization and look at the button. It says Approve. That is the entire specification. Nothing in the interface, the template, or the process states what the word certifies: whether the reviewer read the tests, checked the migration, understood the blast radius, or only looked at the diff. Your organization routes releases through that click and compliance frameworks count it, and nobody ever wrote down what the person doing it is supposed to have done.

Then consider the volume. I have watched teams run roughly thirty pull requests a day against six people authorized to approve them. A five to one arrival ratio against a service point gets treated as an incident anywhere else in the system, and here it is just Tuesday. Nobody tracks that number, staffs against it, or reports it, because it has never been understood as a capacity figure.

The conventional response is to tune the practice. Require two approvers instead of one, cap pull request size, add a checklist, or point a model at the first pass. Every technical leader reading this has sat in a meeting where the fix on the table was a second approver, and nobody in the room asked what the first one was certifying. The debate is always how many and how fast, never what an approval asserts.

With nothing stating what approval means, every reviewer supplies a private definition. One checks the tests, one checks style, and one checks whether they trust the author; all three click the same button, and the organization reads the three clicks as identical. This is what I named Decision Clarity, failing at one specific point: the decision has a clear owner and an explicit point of resolution, and no defined inputs at all. An undefined standard also cannot be failed, so a reviewer is never wrong, and nothing improves. You cannot coach against a definition that does not exist, and you cannot audit a decision that was never stated.

Then volume arrives and the private definition drifts toward the cheapest version that still produces the click. That is a rational response to a queue with no stated floor, not a lapse in character, and nobody is ever out of compliance because there was no compliance. Approval throughput holds steady while what an approval means declines, so every metric confirms the system is healthy. The metric counts clicks. Effective review authority meanwhile collapses to whoever's private definition is still expensive, and cycle time on anything nontrivial routes to those few people.

I have watched all three ways that ends. Changes get routed to the cheap approvers on purpose, so the careful reviewers see only the work nobody was avoiding. Or the careful reviewers absorb the volume until their own definition degrades, and the floor drops everywhere at once. Or they are promoted out of reviewing, and the expensive definition leaves the building without anyone recording that it was the control. None of the three appears on a dashboard, and when something ships broken the post-mortem finds an approval on it and cannot fault the approver, because nothing said what they were supposed to do.

The leaders who get out of this are not more disciplined than you, and their engineers are not more careful. They stopped adding approvers to a control nobody had specified. The number of approvers was never the control; the specification is, and there is not one. Write down what a sign-off attests to, explicitly and per class of change, because what a reviewer certifies on a config change and on a schema migration are not the same thing. Do not assume they know it, and spell it out.

This is structural rather than procedural, because the expensive reviewer's private definition was already doing the work of a specification. It was held in a person, which is the only reason it can leave. Writing it down converts a standard living in someone's head into a property of the system, and a property can be taught, audited, argued with in public, and survives the person who held it. Your real span of control is not who is permitted to approve. It is how many people can meet a written standard, which is a number you can raise, because it is finally a capability you develop rather than a permission you grant.

The reason nobody does this is not difficulty. The vagueness is doing protective work for everyone in the building, including you, because when something ships broken today no one can be faulted and that ambiguity absorbs blame on your behalf. Writing the specification removes the cover deliberately, and the next incident becomes attributable: to the standard, to the reviewer who did not meet it, or to you for writing one that missed the case. Adding a parameter costs nothing, which is why every organization reaches for it first.

Take the last change that shipped and caused a problem. Find the approval on it, then go ask the person who approved it what they understood they were certifying when they clicked, as a genuine question rather than an accusation. The answer will be a private definition nobody wrote down, and it will differ from what you assumed it was. That is the whole diagnosis, delivered by your own team, in one conversation.

The LeadershipOS™ Inner Circle runs this depth every month in print, including the part this article has no room for: how to write the attestation itself, per class of change, without turning it into a checklist nobody reads. https://LeadershipOSInnerCircle.com

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want this depth every month in print, the LeadershipOS™ Inner Circle ships the first of every month. Reply “maybe” and I’ll send you details.