A 40-engineer platform organisation requires two approvals on every pull request. Median time from ready-for-review to merge is 26 hours. A staff engineer proposes one approval plus mandatory post-merge review for low-risk changes. What is gained, what is paid, and when does the bill arrive?

What is gained, quantified

The 26 hours is almost entirely waiting for a human, not reading. Reading a 200-line change takes tens of minutes; the rest is the gap until someone is free. Requiring a second approval roughly doubles that waiting term and adds the probability that one of the two nominated reviewers is on holiday, in a meeting block, or in another time zone.

Cutting it does more than shorten lead time. Cheap review makes small changes economic, and small changes are reviewed better: review effectiveness is commonly reported to fall off past a few hundred lines in a single sitting, so a 26-hour round trip pushes authors towards exactly the change size where review stops working.

What is paid

A second reader catches one specific class of defect: the one the author and the first reviewer share an assumption about. That class is small in ordinary code and large in a few places — authentication and authorisation, data migrations, anything that moves money, anything that changes a default for every tenant.

Post-merge review also only works if the queue is drained. An unread post-merge queue is not review, it is a log, and it degrades quietly because nothing fails when nobody reads it.

When the bill arrives

Not at the next incident. The visible cost arrives months later as concentrated knowledge: with one approver, the set of people who have read any given subsystem shrinks, and you discover the concentration when someone leaves. The second cost arrives at the first audit, if the second approval was implementing segregation of duties.

The design that keeps both

Make the number of approvals a function of blast radius, not a uniform policy. Path-based ownership rules give this directly: two approvals for auth, payments, migrations and infrastructure definitions; one for everything else. Then make post-merge review a named rotation with a service level and a measured drain rate, so it is a commitment rather than an aspiration.

Measure the trade honestly: change failure rate split by review class, for a quarter. If the one-approval class is not worse, the policy was buying nothing on that code.

When this is the wrong trade

In a regulated context where the second approval is the control an auditor tests, it is evidence, not quality, and you cannot trade it away by improving your testing — you would be changing a control, which is a different conversation with different people. And under about six engineers, both policies are theatre: everyone already knows what everyone is doing, and the useful review is the conversation before the code is written.