Decision Restatement

Six weeks after a design is agreed, three of its four key decisions have been implemented differently and nobody raised it. The document has approvals. The retro concludes that everyone agreed. Nobody behaved badly, and the process could not have detected the divergence.

The reason is that approval measures the wrong thing. A click, or silence, records an absence of objection, which is consistent with trusting the author, with skimming, and with not having formed an opinion. Restatement inverts the direction: the receiver produces a short statement of what they will build and why, and the sender checks it.

Why it matters

An engineer who never held a decision cannot notice departing from it. They reach the relevant point in code, find the described approach awkward, pick the option that fits what is in front of them, and do not raise it because from their side nothing has been contradicted. The divergence is therefore invisible to everyone until integration, a review, or an incident.

This is the same problem aviation solved with mandatory read-back of clearances and surgery solved with the pre-incision brief. In both, the sender's confidence that the message was understood turned out to be worthless, and the only reliable evidence was the receiver reproducing it. A design decision handed across a team boundary has the same property and is treated with far less care.

Implementation patterns

• State each decision as a numbered claim with the option rejected and the reason, so there is a specific sentence to disagree with. Four decisions produce four numbered lines.
• Require one or two sentences per decision from each implementer, in their own words, before work starts. Roughly ten minutes per person.
• Check for paraphrase, not agreement. A restatement that repeats your words verbatim is a copy, not a read-back.
• Treat a restatement that differs as information, not error. The implementer is often right, and a corrected decision at this point costs one edit.
• Make divergence cheap to report later: a one-line amendment on the decision record rather than a re-review. If reporting a change costs a meeting, it will not be reported.
• Add a first-pull-request checkpoint: the first change in the area references the decision numbers it implements, and a reviewer checks the match.
• Count distinct substantive commenters on the design document, not comments. Fewer than three is an unreviewed document whatever its approval state.

Industry example

The strongest documented case for restatement is outside software. International air-traffic practice requires a pilot to read a clearance back to the controller, and the surgical safety checklists now used in operating theatres worldwide require the team to state the patient, the site and the procedure aloud before incision. Both replaced a sender-side assumption of understanding with receiver-side evidence, after decades of incidents in which the message had been transmitted correctly and understood wrongly.

Software has the same evidence in a less flattering form. A recurring shape in public incident postmortem write-ups published since 2015 is a written hand-off between two teams that did not state which identifier type or which mode was meant, and an executing team that ran it literally. A restatement of the effect and the count before execution costs one message. An archetype at design time: a logistics platform's four-decision design was approved by 11 engineers and implemented three ways; after restatement was introduced the first cycle surfaced two misreadings inside 30 minutes, against a cost of about 10 minutes per engineer.

Failure scenarios

• Restatement becomes a form to fill in, producing "will implement decision 3 as described", which carries no information.
• The author reads restatements without checking them, so the ritual exists and the control does not.
• It is required for every decision, including reversible ones inside one team, and the team learns to treat the whole practice as bureaucracy.
• The restatement is verbal in a meeting and unrecorded, so a later divergence is a memory dispute.
• Only the tech lead restates, which reproduces the original problem one level down.

Trade-offs

The practice costs roughly ten to twenty minutes per implementer per decision, and it delays the start of work by a day. It also surfaces disagreement at a moment when the author has just finished arguing for the design and would rather not reopen it. That discomfort is the mechanism working: the objection exists either way, and the choice is whether it arrives now or in week six.

Against that, the saving when it catches something is large and asymmetric. Three diverged decisions discovered at integration cost rework, a retro and the credibility of the design process.

When not to use it

Skip it for a reversible decision inside one team's own code, where review catches divergence cheaply and the ceremony is pure overhead. Skip it when the implementer wrote the design. It earns its cost when the decision crosses a team boundary, is expensive to reverse, or will be implemented by people who were not in the discussion — which is the same condition that justified writing the decision down at all.

Interview question

Q: A design you wrote was approved by everyone and implemented differently in three places, and nobody raised it. Walk me through what you would change about the process, and tell me what signal in the original review should have warned you.

What a strong answer covers: approval as absence of objection; restatement as a receiver-side proof; numbered decisions with rejected options so there is something to disagree with; the first-pull-request checkpoint as the early alarm; distinct commenters rather than comment count as the review signal; and a stated threshold below which none of this is worth doing.

Quick check

Quiz: What does an approval on a design document actually measure? Absence of objection, which is consistent with trust, with skimming and with no opinion — not with understanding.

Flashcard: What replaces an approval when a decision crosses a team boundary? A restatement: the implementer writes one or two sentences on what they will build and why, in their own words, before work starts.