Interview prompt. Three teams have escalated the same disagreement to you in a month: the team says a design is ready, a staff engineer in another team says it is not, and nobody can say who decides. Tell me how you would resolve this, and how you would make it not happen again.
Show the full answer Hide the answer
What the interviewer is testing
Whether you reach for process or for decision rights. Most candidates propose a better review meeting, a template, or a stronger architecture group. The question is about who holds the pen, and the tell is whether you can state a rule that tells a team, in advance and without you in the room, whether they need anyone's agreement.
The second thing being tested is whether you understand what you are spending. Every escalation that reaches you is lead time the team paid, and a reviewer who can block without owning the consequence will keep blocking.
The clarifying questions that change the answer
- Is the objecting engineer downstream of the decision? If the design changes a contract their service depends on, they hold a real veto and the process is working badly. If it does not, they hold an opinion and the process is confusing an opinion with a veto.
- Is the decision reversible? A choice that can be undone in a sprint deserves a test, not a debate. One that cannot — a data model, a public API, a vendor commitment — deserves the escalation.
- Who carries the pager? The team that will be woken up by this system has a claim that a reviewer in another team does not.
- Has this happened 3 times with the same two teams? Then the boundary, not the design, is the problem, and you are looking at a Conway's Law symptom rather than a governance one.
A strong answer's arc
Resolve the instance by naming the decision class out loud: "this changes a contract two teams depend on, so it is a joint decision and I am the tiebreak" or "this is internal to your service and reversible, so it is yours and the objection is advice". Say which, say why, and write it down.
Then prevent it with a published decision-rights rule, not a review step. The shape that works is three classes:
- Team-local and reversible — the team decides, no review, recorded in a decision record so it is findable later.
- Crosses a contract others depend on — the affected teams decide jointly; the architect arbitrates only if they cannot, with a deadline of 5 working days after which the architect decides.
- Hard to reverse or binds the organisation — data models, public APIs, vendor commitments, anything with a security or regulatory footprint. The architect owns it and is accountable for it.
The load-bearing detail is the deadline. Without it, "decide jointly" becomes an unbounded wait, which is the state the three teams are already in.
Common weak answers
- "Set up an architecture review board." It converts an ambiguous blocker into a scheduled one. Median wait goes up, and the teams that can ship without review will.
- "The architect decides, that is the job." It makes every design wait on one person and guarantees the queue. The measure of an architecture function is how few decisions reach it.
- "Build consensus." Consensus on a reversible decision is waste; on an irreversible one it is often unreachable. Either way, somebody still has to decide, and refusing to name them is the original problem.
What a strong answer adds
The failure mode of the rule itself, which is the part candidates miss. A decision-rights rule fails by reclassification: a team that does not want to wait records an irreversible decision as team-local, ships it, and nobody notices until the first incident or the first external review. Conway described this dynamic in 1968 in organisational terms, and the modern version is visible in decision records that have no "alternatives considered" section. The guard is cheap: the rule names the classes, and the decision record names which class was claimed, so the claim is auditable after the fact rather than negotiated before it.
The cost side. Quantify it: 3 escalations a month, each adding a week to one team's lead time, is roughly a team-month of delay a quarter purchased for no improvement in design quality — because the design outcome was the same in all three cases once someone decided. And the organisational read: if the same two teams generate every escalation, the cheapest fix is moving the boundary or merging the teams, not improving the arbitration.