An interviewer tells you this - thirty engineers in four squads keep relitigating the same choices in standups and in pull request threads, and the last message-bus argument ran for five weeks. Walk me through how a decision gets made in your team from proposal to written record, and tell me who can say no.

What the interviewer is testing

Not whether you like decision records. Whether you can describe a decision process with a named owner, a bounded consultation window and a definition of "no" - because relitigation is almost never a template problem. Five weeks of argument means nobody knew who was entitled to end it.

The clarifying questions that change the answer

• How many choices a month are we talking about? A 30-engineer organisation generates something like two to five decisions worth recording a month. If it is thirty, the bar for "architectural" is wrong and the process will collapse under volume.
• Is the dispute about facts or about priorities? Facts are settled by a spike. Priorities are settled by whoever owns the outcome, and no amount of evidence substitutes for that.
• Who carries the pager for the thing being decided? That usually names the decider.

A strong answer's arc

1. Proposal is a one-page brief, not a record. Context, the options, the one question in dispute, and a recommendation. It is written before the decision, so people argue with a document rather than across three threads.
2. A consultation window with a date on it - five working days is a reasonable default. Silence inside the window is consent; an objection after it reopens nothing unless new facts arrived.
3. One named decider per decision class. The owning team decides inside its own boundary; anything that changes a cross-team contract, a stored data shape or the operational surface goes to a named architect or a small group. Write the classes down once; they outlive any individual decision.
4. "No" has a cost of entry. The useful rule is the one the Apache Software Foundation applies to code changes: a veto must carry a technical justification, and a veto without one is void, with the project management committee judging whether the justification is valid. Borrow the shape - an objection names the failure mode it predicts, otherwise it is a preference.
5. The record is written at decision time and carries the objection and who raised it, plus the condition that would vindicate them. That sentence is what stops the same argument restarting in month four: the answer becomes "we predicted this - check the trigger" rather than "we discussed it".

Common weak answers

• "We make decisions by consensus." Consensus is a goal, not a mechanism. Without a decider and a deadline, consensus is indistinguishable from the loudest person winning slowly.
• "We write ADRs." The format is the easy part. Records with no decider and no window document the relitigation rather than ending it.
• "Escalate to the CTO." Works twice. It then becomes the path for everything and the queue in front of one person becomes the architecture's rate limit.

What a strong answer adds

Say what you would measure: the elapsed time from brief to accepted, and the number of decisions reopened without new facts. A median of under two weeks and near-zero unforced reopenings means the process works. Then name the limit: below about ten engineers this is overhead - one team in one room does not need a consultation window, and imposing one slows a group that was never blocked.