Facilitation, Consensus Building and Decision Driving Questions

Direct answer

Write an architecture decision record (ADR): a short, dated document stored next to the code that captures the situation, the choice, the alternatives rejected, the consequences and the conditions that should reopen the question. Michael Nygard's format has a title, status, context, decision and consequences; I would add alternatives, assumptions, revisit triggers and who was consulted, because the "why" and the "when to revisit" are what people forget.

Structure and why each field exists

• Title and number: short noun phrase, so the log is scannable.
• Status: proposed, accepted, deprecated or superseded. A superseded record points to its replacement, so history is never edited.
• Context: the forces at play (technical, organisational, deadline).
• Decision: stated in full sentences, active voice.
• Alternatives considered: with the reason each lost.
• Consequences: all of them, good and bad.
• Assumptions, risks, monitoring: what must stay true; what we watch.
• Revisit triggers and rollback criteria: measurable conditions.
• Stakeholders consulted.

Terms used in the record

• Full-text search: searching the words inside documents, not just matching exact titles.
• GIN index: a PostgreSQL lookup structure that makes full-text search fast, the way a book index lets you find a word without reading every page.
• Typo tolerance: still finding "recieve" when the user meant "receive".
• Corpus: the whole body of documents being searched.
• p95 latency: the response time that 95 out of 100 searches beat; it shows what slower-than-usual users experience, not just the average.
• Rollback: going back to the previous approach if the new one fails.
• Superseded: replaced by a newer record; the old one is kept, marked "Superseded by ADR 0012", so history stays readable.

A typical status flow is Proposed, then Accepted, and later either Deprecated (no longer recommended) or Superseded.

Worked example (illustrative values)

ADR 0007: Use PostgreSQL full-text search for in-app search
Status: Accepted   Date: 2026-10-05   Review by: 2027-04-05
Decision owner: Priya (Staff Engineer)
Consulted: Search PM, SRE on-call lead, Security

Context
Users search about 2 million support articles. We need results
within a week for the launch. The team runs PostgreSQL already and
has no one experienced with a separate search cluster.

Decision
We will use PostgreSQL's built-in full-text search with a GIN index
and will not deploy a dedicated search service now.

Alternatives considered
- Dedicated search cluster: better ranking features, but a new system
  to run and secure; rejected for the launch window.
- Third-party hosted search: fast to start, but sends customer text
  to a vendor; rejected pending a security review.

Consequences
+ No new infrastructure; one backup path.
- Weaker typo tolerance and ranking tuning.
- Search load shares the primary database.

Assumptions and risks
Corpus stays under 10 million rows; peak search rate stays low.

Monitoring
Search p95 latency; share of primary CPU used by search queries.

Revisit if (any one)
- p95 search latency above 300 ms for 7 consecutive days
- corpus above 10 million rows
- product requires typo-tolerant ranking

Rollback
Search sits behind one interface, so swapping the backend needs no
change in callers. Roll back to the previous approach if p95 search
latency is above 800 ms for 3 consecutive days after a release, or
if search queries use more than 30% of primary CPU for 7 days.

All numbers are illustrative placeholders to show the shape. The rollback line gives measurable criteria, as the field list above requires, not only a mechanism.

Why this survives a year

A new joiner can read the context, see which options were already rejected and why, and find a numeric trigger. If a trigger fires, a new ADR is written that supersedes this one.

Trade-offs and pitfalls

• Too long means nobody writes one: aim for one page.
• Writing it after the meeting from memory loses the rejected options; draft it before, and finalise it at the decision.
• A record with no revisit trigger invites relitigation by opinion; with a trigger the argument becomes "has the number crossed?".

Direct answer

I would run the Architecture Review Board (ARB, a standing group that reviews significant design proposals and records decisions) as an asynchronous-first process: proposals are read and commented on in writing before the meeting, so the live time is spent only on unresolved questions and on the decision. Remote and external participants get the same access to the discussion as people in the room (the same queue, the same comment channel and the same decision-making rules; for external stakeholders the record is the extract covering their own item), because the written record is the main channel; external stakeholders see only the version and the item relevant to them, so equal access means equal voice, not identical visibility. I would charter it with a clear chair, a short template, timeboxed slots, and a decision record created within a day.

Structured elaboration

• Pre-reads: the author submits a short design document (problem, proposal, alternatives, risks, rollback, the decision requested) by a fixed cutoff, at least 5 working days before. Reviewers add written comments in the document, each labelled blocking, suggestion or question. The chair (the person who runs the meeting and enforces the clock) triages comments before the meeting (sorts them by urgency) so only open blocking items go to discussion. Blocking means it must be resolved before approval, suggestion means the author may take it or leave it, and question means it needs an answer but is not an objection. External stakeholders receive an appropriate version and are asked to comment on their part.
• Facilitation for remote and mixed groups: the chair uses a visible speaker queue (an ordered list of who has asked to speak, shown to everyone including remote attendees), calls on remote participants first (they are the ones who struggle to interject), keeps one shared document on screen, and treats chat comments as speaking turns. Meeting times rotate across time zones when the group spans several, and recordings plus notes make attendance optional.
• Timeboxing (giving each item a fixed slice of time and deciding or deferring when it runs out): a weekly 60-minute session with two proposals at 25 minutes each and 10 minutes for actions. Within a slot, 5 minutes go to the author's summary, 10 to open blocking comments, 5 to remote or external input and 5 to the decision. If a blocking issue is still open when the slot ends, the outcome is "needs rework" with the specific question written down, and the discussion moves to the written thread instead of overrunning.
• Decision recording: an architecture decision record (ADR, a short document capturing context, decision, options considered and consequences) is written by the scribe (the person who records decisions, reasons and actions) within 24 hours and stored where engineers will find it.
• Action tracking: each action has an owner and a date in a tracker; the first minutes of the next meeting check them.

Worked example: one 60-minute session

The blocks sum to 60 minutes. Outcomes at the decision step are: approved, approved with conditions (each with an owner and date), or needs rework (with the specific blocking questions).

Candid critique without blame, across regions

• Critique the design, not the author: comments describe behaviour ("under a regional outage this design loses writes") rather than judging competence.
• The chair opens each session with a short reminder of the norms, a small ritual that sets tone, and starts feedback by asking the author what they were uncertain about.
• Written comment labels make tone explicit across cultures and languages where blunt wording may land differently.
• Documentation expectations are the same for everyone: the same template, the same record structure (external stakeholders receive the extract for their item), no side agreements.

Trade-offs and pitfalls

• Async-first can slow things if comments arrive at the last hour. Set a comment deadline a day before the meeting.
• External stakeholders should attend only their item and see only what they need.
• If the board begins to approve everything or reject everything, review the criteria for what comes to the board at all.

Direct answer

I would tell this as a story with a specific decision, my own actions to draw out and respect the dissent, the explicit moment I made the call, and what I did to keep the team together. The decision here: centralize the deployment and monitoring platform that six product teams were each building themselves, against teams that valued autonomy. I owned the decision as the engineering manager, so my role was to make it well, not to win a vote.

Structure for telling it

Use situation, task, actions, result, and reflection, with most of the time on actions. State the decision rule you used (who decided, how input was gathered) because interviewers listen for whether the call was fair and whether it was actually made.

Worked example: the story

Situation. Six teams each ran their own deployment scripts, alerting and on-call tooling (the on-call rotation is the schedule on which engineers take turns being paged when production breaks). Incidents took longer to diagnose because each system looked different, and the cost of duplicate tooling kept growing. Leadership's longer-term goal was a platform engineers could move between teams on without relearning everything.

Task. Decide whether to centralize on one shared platform maintained by a small platform group, or keep team autonomy and publish standards. Several senior engineers strongly opposed centralization; they feared a slow platform team and loss of control.

Actions.

1. I wrote a short proposal stating the problem, two options (central platform, or standards with team-owned tools) and the criteria: incident response time, engineer mobility, cost, and team speed.
2. I met the three loudest dissenters one-to-one before any group meeting and asked what would make the central option fail. Their answers became a written list of conditions: self-service for common tasks, escape hatches (documented ways for a team to step outside the standard platform for a special case), and an on-call rotation shared with the platform group. In that meeting I said: "I am not asking you to agree. I am asking what would make this fail, so I can build it into the plan."
3. In a working session, I asked each team to present their strongest objection and the platform group to respond. I said at the start that I would decide after the session and not by vote, and I named the date.
4. I decided to centralize, with the conditions built in, and told the dissenters first and personally: "I decided to centralize. Your three conditions are in the plan, and your objection to a slow platform team is written down with a measure that will show whether you were right. I need you to argue this at the 90-day review, not around it." The wider announcement said the same in two sentences: what was decided, and which conditions and review date came from the objections. I used "disagree and commit": they could keep arguing until the decision, but after it everyone owned the outcome. The written log of objections and measures was the agreed test of whether the dissenters were right.
5. I gave one team a time-limited exception (it keeps its own tooling until a stated date, then reviews again) and tied it to a review date, so the policy was not treated as absolute.

Result. The 90-day review was the first checkpoint; teams finished adopting the platform over the following two quarters. Incident diagnosis became more consistent, and engineers moved between teams more easily. Two teams requested exceptions at the review; one was granted. The measures I tracked were time to diagnose incidents and how many engineers moved teams, and both moved in the right direction at the review. With illustrative figures: median time to diagnose an incident fell from about 50 minutes to about 35 (a 30% reduction), and 9 engineers moved between teams that quarter, against 2 in the quarter before. Quote your own measured numbers, or say plainly that you tracked the direction only.

What I would do differently. I would involve the senior engineers in designing the self-service interface from the start, instead of consulting them after the proposal. That would have made them co-owners earlier.

Trade-offs and pitfalls

• Do not pretend you had consensus. The senior answer is "we did not agree, and here is how I decided and how people still committed".
• Avoid a story where you were simply right. Show what you changed because of dissent.
• Avoid inflating the result with numbers you cannot defend.

Direct answer

I treat the review as a decision meeting, not a presentation. Beforehand I circulate a pre-read that frames the decision and the trade-offs, in the room I spend the time on the disagreements, and afterwards I publish a decision record with owners and dates and check back on it.

1. Preparation: pre-reads and artifacts (sent 2 working days ahead)

• One-page proposal: the problem, the options (two or three), the recommendation, and the specific decision being asked for.
• Trade-off table with the same criteria for every option, e.g. cost, delivery time, security posture, operational burden, reversibility. A filled excerpt for the question "where do we store audit logs?":

The numbers are illustrative; the point is that every option is judged on the same rows.

• Constraints and commitments: the target availability or latency (SLO, service-level objective, the internal target for a measured level of service, such as 99.9% of requests succeeding; an SLA, service-level agreement, is the external promise to customers), a rough cost estimate, and an estimated delivery date (ETA).
• Risk register: a short list of risks, each with owner, likelihood, impact and mitigation. One filled row: Risk: audit trail lost if the primary region goes down. Owner: infrastructure lead. Likelihood: low. Impact: high. Mitigation: replicate logs to a second region and rehearse failover each quarter.
• Attendee asks: I tell security "we need your yes/no on data handling", infrastructure "we need your view on operating it", product "we need the priority call". Everyone knows their role before they arrive.

2. Agenda that surfaces trade-offs (60 minutes)

That sums to 60. If I am the presenter in a 15-minute design review instead: 5 minutes presenting, 7 minutes questions, 3 minutes for decision and actions, which is 15, with the pre-read carrying the detail.

3. Managing strong opinions

• Ask each person to state a concern as a criterion ("I need the audit trail to survive a region failover", meaning the automatic switch to a backup region when the main one fails) rather than a verdict ("this is insecure").
• Use a parking lot for off-topic points, and capture them visibly so they are not lost.
• Hear the quietest function first on the sensitive topic, and the senior person last, to avoid anchoring (the first opinion stated pulling everyone else toward it).
• If two people loop, restate each position in one sentence, name the real crux, and either assign a test or hand it to the decision owner.

4. Recording, actioning and following up

Within 24 hours I publish a decision record: decision, options considered, rationale, dissent, conditions, and a status (proposed, accepted, superseded). Illustrative action table:

For follow-up I put a 15-minute check-in on the calendar for the week after the earliest due date, and I ask for sign-off (a clear, stated approval) from product, security and infrastructure explicitly (a stakeholder who did not say yes did not agree).

Trade-off

A heavy pre-read costs author time; a lighter version is fine for reversible choices. If someone arrives without reading, I do not re-present; I use the first five minutes for a silent read.

Direct answer

A design critique is a structured session where peers examine a proposed design for flaws before it is built. With two senior engineers split on a core component, I run it in steps: set the decision rule, let each person present, test with evidence, choose vote or defer based on the type of decision, and write the record before leaving.

Step by step (a 60-minute session)

Total: 60 minutes.

What evidence I ask for

A benchmark or prototype result on the same workload; failure modes (the ways each design can break, and what users see when it does) and how each design degrades; operational cost (who runs it); and migration cost from today. Opinions are welcome, labelled as opinions.

When to vote and when to defer

• Vote when the options are both acceptable, the group are peers with equal stake, and the choice is cheap to reverse. A vote (or a "fist of five", where everyone shows 0 to 5 fingers at once: a fist means "I will block this", 1 or 2 means "I have real concerns", 3 means "I can live with it", 4 or 5 means "I support it") is fast and visible. Any 2 or below triggers a short conversation: "what would it take to move you to a 3?"
• Defer to a single decider when one person is accountable for running the system, when the group is split evenly, or when the decision is costly to reverse. A vote between two strong seniors can leave a losing camp and a muddled mandate.
• Defer for more evidence when a specific unknown (for example load behaviour) would change the answer and can be tested within a few days. I set the test, the owner and the date.

For this scenario I would defer to the engineer accountable for the component (if that person is one of the two proposers, a neutral lead decides instead), after the challenge round, with the other's disagreement (the dissent, meaning the minority view) recorded in the decision record, so the decider has the mandate (the authority to proceed) and the dissent is not lost.

Documenting and communicating

An architecture decision record (ADR; Michael Nygard's template has Title, Status, Context, Decision, Consequences) written in the room: the chosen component, the alternatives and why not, the evidence, the consequences including the downside accepted, and a review date. Example excerpt: "Status: accepted. Context: order events must be replayable after an outage. Decision: use the managed queue. Alternatives: self-hosted broker (more control, we would run it). Consequences: lower operations load; we accept vendor limits on message size. Dissent: A prefers the broker for cost at scale. Review: 1 March or when volume passes the agreed limit." Send it to all stakeholders within a day with a two-line summary and where to raise objections by a stated deadline.

Trade-offs and pitfalls

• Letting the loudest engineer present last biases the room; fix the order.
• Moving to a vote too early skips the evidence round.
• Skipping the record means the argument returns in three months.