Overrule Threshold

An engineer proposes a design that works and is not the one you would have chosen. Every reviewer faces this weekly, and most resolve it by instinct, which produces two failure modes in different teams: the reviewer who always defers, and the reviewer whose preferences are requirements.

An overrule threshold makes the rule explicit. Two properties decide it: how reversible the choice is, and how far its failure travels. A dedupe table in one service, replaceable in days, is the engineer's call even if you would have used the broker's idempotent producer. A message format three teams will consume, a shared schema, a retention decision, a security boundary — those are yours, because the cost of being wrong is not the engineer's to carry.

Why it matters

The purpose of review is not to produce the design the reviewer would have written. It is to keep bad outcomes out of production while building the judgement that makes review less necessary. Overruling a workable design costs both: the reasoning is discarded, and the next proposal is an attempt to guess the reviewer's preference rather than a piece of engineering. That is how a team acquires the habit of designing for approval.

The reverse failure is quieter and more expensive. A reviewer who defers on an irreversible decision because it felt like a mentoring moment has confused the engineer's growth with the company's risk. The threshold exists so that both calls are made on a stated basis rather than by mood.

Implementation patterns

• Ask the two questions out loud: how long would reversing this take, and does the failure stay inside this service? Under a fortnight and locally contained is the engineer's call.
• When you approve, write the boundary with a number. "Revisit if the dedupe table passes 50 million rows, or if p99 enqueue latency passes 40 ms, or the first time a second service needs this." A trigger with a threshold is a control; "revisit if it becomes a problem" is a sentiment.
• State your preference without attaching a requirement to it. "I would have used the broker's producer, because the dedupe state stays with the broker and there is no table to grow. I do not think it is worth changing here." The mechanism transfers and the authorship does not move.
• When you do overrule, say that you are doing it and why the asymmetry applies. Silent overruling, or asking leading questions until the engineer capitulates, teaches that review is a negotiation with a predetermined outcome.
• Never approve while planning to change it later. The worst option available: the work is done twice and the engineer learns that review was theatre.
• Do not escalate a design disagreement to a manager. It is normal work between an engineer and a reviewer, and escalating it reframes the engineer's judgement as a management matter.

Industry example

The threshold is the individual-scale version of the reversibility distinction that organisations apply to decisions generally: separating the choices that can be undone from the few that cannot, and spending review capacity on the latter. Amazon's articulation of one-way and two-way doors, public from about 2016, is the best-known framing, and the operational point is identical at both scales — a two-way door should be decided by the person closest to the work, quickly, and a one-way door should be decided deliberately and higher up.

Teams that keep architecture decision records notice the same split in their own history: the records that mattered are the ones about interfaces, data models and retention, not the ones about implementation choices inside a service.

Failure scenarios

• Proposals converging on the reviewer's taste, after which reviews find nothing because nothing unexpected is ever proposed.
• Two-way doors litigated for weeks while a one-way door ships in a pull request nobody flagged.
• A silent refactor that replaces an approved design, which is the most corrosive version because it is invisible until it lands.
• Deference on an irreversible choice — a shared schema or an external contract — because it was framed as a growth opportunity.
• A reviewer who is the only person who can approve anything, which is what happens when the threshold lives in one person's head rather than in a written rule.

Trade-offs

Approving designs you would not have chosen means the codebase contains variety you find inelegant, and occasionally a design you disliked will need replacing at a cost you predicted. That is the price, and it is real.

What it buys is engineers who make and own decisions, which is the only mechanism that scales architectural judgement beyond the reviewer's own throughput. The alternative buys consistency and creates a bottleneck, and the bottleneck is usually the person complaining that nobody else thinks architecturally.

When not to use it

Where the choice is irreversible for the company and reversible for the team, the threshold says overrule, and it should be obeyed: public API shapes, message formats other teams consume, data models many services read, retention of personal data, security boundaries, anything writing data you will still hold in three years. The threshold is also the wrong instrument when the design does not actually work — then it is not a matter of authorship but of correctness, and the reviewer's job is to say so plainly. And in a genuine emergency, the rule is suspended: incidents are not mentoring opportunities.

Interview question

Q: You are reviewing a design from someone you mentor. It will work, and you would have done it differently. When do you impose your version, and what do you do when you decide not to?

What a strong answer covers: the two properties — reversal cost and blast radius — with examples on each side; the boundary condition written with a number as the artefact of approval; stating a preference without making it a requirement, so the mechanism transfers; why the silent later refactor is the worst option and why escalation is not appropriate; and the exceptions, irreversible-for-the-company choices, designs that do not work, and live incidents.

Quick check

Quiz: Which two properties decide whether a reviewer should overrule a workable design? Reversal cost and blast radius — days to undo and contained in one service means the engineer's call.

Flashcard: What must accompany approval of a design you would not have chosen? — A written revisit trigger with a number in it, plus your preference stated as information rather than as a requirement.