Facilitation, Consensus Building and Decision Driving Questions

Direct answer

I would not pick a side. Speed, inclusion and accountability are protected by deciding how each decision is made before it is argued about. I sort decisions into a few tiers by reversibility and blast radius, give each tier a decision mode (who decides, who is consulted, how long it can take), and reserve true consensus for the small set where everyone must live with the outcome.

Terms

• Consensus: everyone actively agrees. Consent: nobody has a reasoned objection (a lower bar than agreement). Consult-then-decide: one accountable person decides after hearing input.
• One-way door / two-way door: door language from Amazon's shareholder letters: a decision that is hard to reverse (one-way) versus one that can be undone cheaply (two-way). Bezos's 2016 letter says "Many decisions are reversible, two-way doors. Those decisions can use a light-weight process", that most decisions should be made with somewhere around 70% of the information you wish you had, and that "disagree and commit" can settle a decision without consensus.

1. Illustrative decision tiers for a mid-size engineering organisation

The SLA values are illustrative; set them from your own pace.

2. How I decide which tier
Ask: (a) How costly and slow is reversal? (b) How many teams carry the consequence, that is, how far the damage spreads if it goes wrong (the blast radius)? (c) Does execution depend on people's genuine buy-in? (d) Is there safety, legal or cost exposure? Start every decision at Tier 1. Two "yes" answers move it up one tier, to Tier 2; three or four move it to Tier 3. Traced on three decisions: a library choice inside one service is no, no, no, no, so it stays Tier 1. A new API versioning convention is yes on (b) and (c) only, so Tier 2. Moving the core data platform to another cloud provider is yes on (a), (b) and (d), three yes answers, so Tier 3. Full consensus is for decisions where buy-in itself is the success condition (a shared on-call model), not for ones where it merely feels polite. A decision with one yes answer or none stays in Tier 1. There is one override of the count, triggered by a fifth test: (e) does the decision change how individuals spend their own days or nights, in a way tooling cannot enforce and nobody could easily see being ignored? A yes on (e) means the decision is run in consensus mode with the deadline of the tier the count gave it. The on-call model is yes on (b), (c) and (e), so it is Tier 2 by the count but runs in consensus mode with a Tier 2 deadline, because people who must live with it daily will quietly not carry out a rota they were only consulted on. The API versioning convention is also yes on (b) and (c) but no on (e): a gateway or contract test can enforce it and a violation is visible, so it stays consult-then-decide.

3. Governance details

• Who votes: most tiers do not vote. Named stakeholders give input; one person is accountable. If a vote is used, the voters are those who will operate or build it, not everyone with an opinion.
• Recording alternatives and dissent: each decision gets a short record (an ADR, architecture decision record) listing options, rationale and who disagreed and why, so dissent (a recorded disagreement) is respected and can be revisited if its predicted risk appears.
• Who arbitrates: if the consult stage deadlocks past the SLA, the decision goes to the accountable person's manager. Everyone knows this in advance.

4. Centralised vs decentralised
Central decisions give consistency (security standards) but queue up; decentralised give speed but fragment. My default: decentralise Tier 1 fully (the tech lead decides alone); keep Tier 2 light, with one architecture lead (ideally a lead from one of the affected teams, by delegation) deciding after input from the affected teams, so cross-team conventions get a single arbiter rather than a committee and still do not queue behind the executive level; centralise only Tier 3 plus a few guardrails (shared rules that set the limits teams work within, such as an approved list of data stores). Pitfalls of switching model: a sudden centralisation reads as distrust and creates a bottleneck; a sudden decentralisation without guardrails produces ten incompatible answers. Switch one tier at a time and measure decision lead time (working days from a request being raised to a decision being made) and reversal rate (the share of decisions later undone, for example 2 reversed out of 40 made is 5%, an illustrative figure).

What would change my call: a regulated domain pushes more decisions to Tier 3; a high-trust small team can collapse to two tiers.

Direct answer

I would earn trust by making the board small in scope and fast by default. The charter says that most decisions stay with teams, and the board only sees changes that are hard to reverse or that cross team boundaries, with a published time limit on decisions. I would then measure four things for a quarter: how long decisions take, how much review happens asynchronously, rework avoided, and team sentiment, and show the results openly. (An Architecture Review Board is a group that reviews significant design proposals and records decisions.)

Structured elaboration

Charter (one page): purpose (reduce costly rework and conflicting designs), scope, decision rights (teams decide within published guardrails (written standards that mark what teams may do without asking); the board decides on the escalation triggers), membership (five rotating engineers from different teams plus a chair), and a service level (a promised response time, here a decision within 5 working days of a complete submission).

Intake and review tiers:

Escalation triggers to Tier 2: introducing a new data store or core technology; a new externally exposed API; a change that crosses a security or data boundary; a shared library or contract used by several teams; a cost above an agreed threshold. These are things that are expensive to undo.

Lightweight design-review template (one to two pages): the problem; the proposed design; alternatives considered; what is hard to reverse; risks and rollback; which triggers apply. Decisions are recorded as short ADRs (architecture decision records: context, decision, consequences) in the repository.

Enforcement: the pull-request template asks for the ADR link when a trigger applies, and a quarterly sample audit checks whether Tier 2 changes were reviewed. Enforcement is by visibility, not by blocking.

Worked example: four requests

(a) A team adds an internal endpoint using the standard framework: Tier 0, no wait. (b) A team wants to use a different logging library from the standard for its own service, touching no trigger: Tier 1, two reviewers answer within 3 working days. (c) A team wants to adopt a new database: Tier 2, goes to the board. (d) A team changes a function in a shared authentication library used by four teams: that matches the trigger for shared libraries used by several teams (and crosses a security boundary), so it is Tier 2, not Tier 1.

Showing it is worth having within a few months

Measure a baseline before launch, then track:

• Time to decision: median working days from complete submission to decision, target at most 5.
• Share decided asynchronously: how many were resolved without a live slot.
• Avoided rework: reviews where a reviewer found an issue that would have forced a redesign, with the author's estimate in engineer-days (label it as an estimate).
• Team sentiment: a one-question survey: "did the review help or slow you?"

Illustrative sample: seven decisions took 2, 3, 3, 4, 5, 5 and 9 working days. The median is 4 (the middle value once sorted), and 6 of 7 met the 5-day target (2, 3, 3, 4, 5 and 5 all fit; only the 9-day decision missed). Seven is too few to claim success. I would report the trend over the full quarter, and compare against the baseline.

Trade-offs and pitfalls

• A board that cannot say no to scope creep becomes the bottleneck. Review the trigger list each quarter and remove items that were never changed by review.
• Do not claim avoided rework without the author confirming it.
• Celebrate teams that used Tier 0 correctly; fast paths are the proof the board is not a toll gate.

Direct answer

For a go/no-go meeting with executives, sales, legal and engineering, I would do most of the persuading before the meeting and use the 60 minutes to test the risks and take the decision. I would send a one-page decision brief and written go/no-go criteria in advance, speak to each executive for a few minutes beforehand, and run a tight agenda that ends with the named decider saying go, no-go or go with conditions. The risk of a "risky" migration is usually in the cutover (the moment traffic switches from the old system to the new one) and the rollback (switching back to the old system if the new one fails), so the criteria focus there. "C-level" means the chief officers, such as the CEO, CTO and CFO. ("Go/no-go" means a single decision to proceed or stop.)

Structured elaboration: prep materials

• One-page decision brief: what is being migrated, why now, what happens if we wait, the decision requested, and the decider named.
• Top risks: the five most serious, each with likelihood and impact in plain words (high, medium, low), mitigation and residual risk (what is still left after the mitigation).
• Before-and-after architecture diagram on one page, a rollback plan summary, and a customer impact list prepared with sales.
• Legal checklist: data location, contract commitments, regulatory notices.
• Pre-wiring (talking to people one-to-one before the meeting so nothing in it is a surprise): a short one-to-one with each executive to hear objections early.

Minute-by-minute plan

The blocks sum to 60 minutes.

Go/no-go criteria (written beforehand)

1. The rollback has been rehearsed in a non-production environment, and it can restore service within the downtime window the business accepted (for example, 4 hours on a Sunday night; the rehearsal restored service in 2 hours 40 minutes).
2. Legal has confirmed data location and contractual obligations are satisfied.
3. The migration window does not collide with committed customer events, and sales has the list of customers to notify.
4. The cutover team and on-call coverage are staffed and named.
5. The cost stays within the approved range (for example, forecast $370,000 against an approved $400,000; illustrative figures).

Decision rule and worked example of the outcome

Rule agreed in advance: any criterion marked Not met means no-go for this window; Conditional is allowed only when the condition has an owner, a date and a default of no-go if it fails.

Four criteria are Met and the first, the rollback rehearsal, is Conditional because it ran once. The decider says "go, on condition that a second rehearsal passes by Thursday; the engineering lead verifies and reports to me". The conditions, owner and date are read back and recorded, and if the condition fails the default is no-go for that window.

Trade-offs and pitfalls

• In urgent meetings the temptation is to go straight to a decision. Written criteria stop the loudest voice from setting the bar in real time.
• A migration that can be reversed cheaply deserves a faster decision than one with an irreversible step. Name which steps are irreversible and add checks there.
• Agree before the meeting what happens if the decider is missing: no decision is itself a decision, so the default should be written down.