Across an estate of single-owner internal services, code review is a rubber stamp. What do you change?
answer
- an approval is not a reading
- reviewer understanding is the scarce resource
- rank by runtime authority
- compensate where you cannot review
- measure self-approval on the short list
basics
~20 sStop treating the approval as review. Rank services by what their code can reach, buy genuine reviewer capacity only for that short list, and replace review elsewhere with detective controls and narrower runtime authority — then correct the compliance claim.
solid answer
~50 sThe failure here is social, not configurable: a required approval from someone who cannot understand the code reports success while inspecting nothing, and that is worse than a documented gap because it consumes your answer to an auditor. I would do three things. Rank services by blast radius — production data, money, credentials, released artifacts — and accept that the list is short. For that list, create real review capacity: a rotating second owner who is actually onboarded, pairing on privileged paths, or a named reviewer outside the team for a defined path list. For the long tail, stop pretending; allow self-merge, and compensate with things that do not need a second human — narrow short-lived runtime credentials, an audit trail you trust, and alerting on merges to sensitive paths. Then measure the right thing: self-approved merges on the high-blast list, not global review coverage. And fix the compliance claim to describe the control that actually operates.
go deeper
Understand what the control is for: an approval is meant to be evidence that another person read and understood the change, so an approval given without that is not review at all.
Be able to argue why requiring more approvals does not create more scrutiny, and name compensating controls that work without a second human, such as narrow short-lived credentials and alerting on sensitive paths.
Show how you would classify services by runtime authority and defend a short mandatory list, including the escape hatch and the latency budget that stops teams routing around the rule.
Own the budget and the external story: what reviewer capacity costs, which risk you are consciously accepting in the long tail, and how you correct a compliance claim that overstates what the organisation actually does.
## Name the failure honestly The organisation has a control that produces evidence and no assurance. Someone clicks approve on code they could not evaluate, because they are unblocking a colleague and the alternative is that nothing ships. Every artefact an auditor wants exists. The inspection the control was created to perform does not happen. This is worse than an acknowledged gap, and the reason is worth saying plainly in an interview: an acknowledged gap gets compensating controls and a plan. A control that looks operative absorbs the attention that would have gone to compensating controls, and it becomes the sentence in your security questionnaire that a customer relies on. When it fails, you have also made a false statement. ## Why the obvious fixes do not work **Require two approvals globally.** Reviewer understanding is the scarce resource, and approvals are not. Doubling the requirement doubles the rubber stamping and adds latency that pushes teams toward exceptions and emergency routes. Coverage rises, assurance does not. **Mandate that everyone learn everyone's service.** This is a real ambition and a poor control. It pays out over quarters, cannot be verified, and does nothing this week. **Buy a tool.** Static analysis, secret detection and dependency alerts are worth having and they answer a different question. None of them evaluates whether a change to a payment path should exist. ## The approach that survives contact **Rank by what the code can reach, not by who owns it.** The classification that matters is runtime authority: services that write production data, move money, issue or hold credentials, or produce artifacts other people run. In most estates this is a small minority of repositories, and naming it converts an impossible universal rule into a fundable one. **Buy genuine capacity for that list, and only that list.** Options, roughly in ascending cost: a rotating second owner who is deliberately onboarded rather than nominally assigned; pairing on changes to privileged paths so the review happens during authorship; a small central group of reviewers who take a defined path list across teams; and, at the top end, a standing second engineer on the highest-consequence services because bus-factor one there is an availability risk as much as a security one. Each of these has a headcount cost, and saying that out loud is part of the answer — this is a budget decision dressed as a policy decision. **For the long tail, replace the control rather than fake it.** Permit self-merge, and lean on measures that need no second human: short-lived, narrowly scoped runtime credentials so an unreviewed change inherits little; no standing production write access for humans or services; an audit trail you would be willing to rely on in an investigation; alerting when a change lands in a sensitive path; and independent recomputation or reconciliation where correctness of output can be checked from outside. **Change what you measure.** Global review coverage is the metric that produced the rubber stamp — it is satisfiable by clicking. Track instead: the share of merges on the high-blast list that were self-approved; how long a change on that list waits for a qualified reviewer, since latency is what drives the workaround; and how many services still have exactly one person able to reach production alone. Those numbers move only when something real changes. **Sequence it.** Quarter one: classify, and instrument self-approval on the classified list. Quarter two: stand up the reviewer capacity for that list and cut human standing production access. Quarter three: extend by consequence, and re-derive the classification, because services move between tiers as the business changes. ## Say the true thing to the outside If the questionnaire or control narrative claims universal peer review, correct it. Describe the control that actually operates — independent review on a defined high-consequence list, self-merge with named compensating controls elsewhere — and put the remainder on a dated plan. A scoped, accurate control with compensations is a defensible position with an auditor and a customer. A universal claim that does not hold is a finding about your integrity as well as your engineering, and it is the sort of thing that surfaces at the worst possible moment. ## The tradeoff you are actually making You are trading breadth of a fake control for depth of a real one, and accepting known unreviewed change in the long tail as a deliberate, documented decision with compensating controls attached. That is the principal-level move: not eliminating the risk, but relocating it to where you can see it, bound it, and defend the choice.
- Your security questionnaire currently claims all code receives peer review. What do you do about that sentence?Correct it, deliberately and on your own timing. Describe the control that operates — independent review on a defined high-consequence list, self-merge with named compensating controls elsewhere — and attach a dated plan for the rest. A scoped accurate claim is defensible; a universal one that does not hold is both a control finding and a credibility finding, and it surfaces when you can least afford it.
- A team argues their service is low risk and should stay outside the reviewed list. How do you adjudicate?Decide it on runtime authority rather than the team's self-assessment: what credentials the service holds, what it can write, and whether anything downstream runs what it produces. If those are genuinely small, agree — and then keep them small, because the classification is only true while the authority is. Re-derive the list on a schedule, since services acquire access quietly.
- How would you know in a year whether this worked?Three numbers. Self-approved merges on the high-consequence list should approach zero. Time-to-qualified-reviewer on that list should be short enough that nobody routes around it. And the count of services where one person alone can reach production should be falling. Global review percentage should be ignored — it was high throughout the period the control was doing nothing.
Two signatures on a form neither person can read is not four eyes; it is two pens. Better to send the accountant to the accounts that matter.
saying these in an interview costs you the question
- Mandates two approvals everywhere without adding reviewer capacity
- Treats the audit checkbox as the objective
- Assumes automated analysis substitutes for understanding the change
- Says hire more engineers, with no prioritisation
- Leaves an inaccurate universal review claim in place