Facilitation, Consensus Building and Decision Driving Questions

Direct answer

Pre-work decides most of the outcome. Before the meeting I interview both stakeholders, ask each to define their metric precisely and bring a sample query or demo on the same data, and agree a decision rule. In the 30 minutes I compare the candidates against that rule, decide, and publish the agreed definition as a short written artifact both can see themselves in. (The lead metric is the one headline KPI, a key performance indicator, that the team is judged on; other metrics play supporting roles.)

Pre-work

1. 1:1 with each stakeholder: what decision does your KPI drive, and what would convince you the other metric is better?
2. Write the candidate definitions in the same format: name, formula, time window, data source.
3. Evidence on the same data: each brings a sample query or dashboard demo. For retention, a historical check is useful: which candidate best predicts customers still active 90 days later? To run it, take customers who joined six months ago, compute each candidate for their first 30 days, and compare against whether they were still active at day 90. Illustratively, if 150 of 200 customers with 3 or more active weeks in month one were still active at day 90 (75%) versus 30 of 100 with fewer (30%), that candidate separates retained customers well.
4. Decision rule (proposed in advance): the lead metric must be (a) tied to retention, (b) movable by the team within a quarter, and (c) hard to game (it cannot be pushed up by actions that do not help customers, such as discounting or relabelling accounts). Each criterion needs a minimum score of 2 out of 5, and then the higher total leads; where a candidate scores low on one criterion, the other metric covers the gap (for 90-day retention, which reads out late, weekly usage is the early signal). The other metric becomes a guardrail (a metric that must not get worse) instead of being dropped.

Agenda (30 minutes)

Total: 30 minutes.

Illustrative scoring during the 8 to 20 slot, each criterion scored 1 to 5 aloud, with the stakeholders agreeing each number:

The totals are close, so the group reads the result as: retention is the lead metric because it measures the outcome itself, and weekly active usage becomes the guardrail and the early-warning signal.

Facilitation techniques: "say it back" before rebutting; scoring each candidate against the three criteria aloud; naming what each person gains (their metric becomes the guardrail).

Example conflicts and how the data decides

• Revenue versus long-term engagement as the lead KPI: revenue moves fast but can rise by discounting and lose customers later; engagement moves slower but tracks retention. A common outcome is engagement or retention as the lead metric with revenue retention as a guardrail.
• Last-click versus first-touch conversion: suppose a customer clicks an ad on Monday, an email on Wednesday and buys on Friday. Last-click credits the email; first-touch credits the ad. Run both definitions on the same quarter's data, show how credit shifts between channels, and pick one for the stated purpose (acquisition decisions favour first-touch; closing-funnel optimisation favours last-click), keeping the other as a reported secondary.

Documenting the decision

A one-page definition. A filled example: Name: 90-day customer retention rate. Meaning: the share of customers who are still active 90 days after they sign up. Formula: customers active on day 90 / customers who signed up in the cohort (for example 180 / 300 = 60%, a cohort in which the 200 customers with 3 or more active weeks in month one and the 100 with fewer were pooled). Window: day 90 after signup, cohorts by signup month. Source: the billing and product events tables. Owner: named person. Known limits: ignores customers who left and returned. Review date: next quarter. In general the page holds: metric name, plain-English meaning, exact formula, time window, data source, owner, known limits, and review date. Both stakeholders get a line recording what they contributed and the guardrail they own.

Trade-offs and pitfalls

• Choosing a metric without agreeing a rule first becomes a vote on personalities.
• A lead metric that no team can influence invites gaming or apathy.
• Skipping the written definition lets each team compute it differently.

Direct answer

Treat the meeting as the last step of a decision process, not the process itself. Before the meeting: name one decision owner, agree the criteria, and get written evidence in advance. In the meeting: walk the criteria, surface concerns from each function, decide with a stated mode, and write the record in the room. Afterwards: circulate the record within a day and track the actions.

Before the meeting (what I do and why)

1. One decision owner. Use DACI (Driver, Approver, Contributors, Informed): I am the Driver who runs the process, one Approver (the engineering lead) decides, Product, Operations and Legal are Contributors who have a voice but not a vote. One Approver prevents "everyone owns it, so nobody does".
2. Criteria agreed before options. For a real-time analytics data store: query latency, operating effort, cost, compliance (Legal's data-residency needs, meaning rules about which country the data may be stored in, and retention needs, meaning how long records must be kept or deleted) and team familiarity.
3. Who presents which evidence. Engineering presents a benchmark plan and results on realistic data; Operations presents on-call and backup effort; Product presents the feature's latency need; Legal presents the compliance constraints. Each sends a one-page pre-read two days ahead.
4. A small prototype or benchmark. A timeboxed test (a fixed, short slot such as a few days) and a benchmark (a repeatable measurement of speed or cost) on a sample of real queries, so the room argues about results, not opinion.

Running the 90-minute meeting

Total: 90 minutes.

Facilitation moves I use in the room:

• Round-robin: go around the table in a fixed order so each person speaks once before anyone speaks twice, which lets quiet voices go early.
• Parking lot: a visible list on the board of off-topic items, each given an owner so it is not lost.
• Say it back: before rebutting, a person restates the previous speaker's point in their own words and gets a "yes, that's it".
• Silent writing: everyone writes concerns on cards for two minutes before discussion, so the first speaker does not set the agenda.
• "What would change your mind?": asked of each person, it turns a position into a testable condition, for example "if the benchmark shows under 200 ms at 10x load I would accept the managed store".

A decision matrix (illustrative scores)

Weights sum to 100. Scores are 1 to 5.

Each score is the sum of weight x score divided by 100. Managed analytics store: 30x5 + 20x2 + 20x3 + 20x4 + 10x2 = 150 + 40 + 60 + 80 + 20 = 350, so 3.5. Existing database plus replica: 30x3 + 20x4 + 20x4 + 20x5 + 10x5 = 90 + 80 + 80 + 100 + 50 = 400, so 4.0.

The matrix informs the decision; it does not make it. It is sensitive: raise latency's weight from 30 to 45 and reset operating effort to 15, cost to 15, compliance to 15 and familiarity to 10 (the weights still sum to 100). Managed store: 45x5 + 15x2 + 15x3 + 15x4 + 10x2 = 225 + 30 + 45 + 60 + 20 = 380. Existing database: 45x3 + 15x4 + 15x4 + 15x5 + 10x5 = 135 + 60 + 60 + 75 + 50 = 380. Both are 3.8, a tie. That tells the room the real debate is how much latency matters, and Product must answer that.

Close: the recorded decision

The record (an architecture decision record, or ADR, is a short document in the form Title, Status, Context, Decision, Consequences) states the choice, the owner, the rejected option and why, the risks, the rollback plan (what we do and by when if the benchmark in production misses the latency target), and the concerns from the side that lost, with a review date.

The same process applied to choosing a machine-learning model architecture

The same process works with a different trade-off: latency and cost against accuracy. Agree the evaluation set (a fixed set of test examples) and the metric first, run each candidate on it, and set a latency budget per request that Product agrees to. For example (illustrative): budget 100 ms per request; Model X scores 0.91 accuracy at 80 ms, Model Y scores 0.94 at 140 ms. Y misses the budget, so X is the only candidate that qualifies, unless Product agrees to move the budget. The decision owner then chooses from candidates meeting the budget.

Trade-offs and pitfalls

• Do not let a matrix become false precision: show the sensitivity.
• A 90-minute meeting with unseen evidence turns into a reading session. Require pre-reads.
• If the meeting fails to decide, name what is missing and a date, instead of rescheduling blindly.

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.

Direct answer

Consensus is the right goal when the group must carry out the decision together and their genuine buy-in is part of what makes it work. It is the wrong goal for most other decisions, especially reversible ones or ones with a clear expert owner. I fix the slowdown by labelling each decision with a mode up front.

Terms

• Consensus: everyone actively supports the choice.
• Consent: nobody has a reasoned objection they can state; people need not love it.
• Consult-then-decide: an owner gathers input, then decides.
• Disagree and commit: someone who disagrees agrees to back the decision and execute it fully. Amazon lists it as a leadership principle ("Have Backbone; Disagree and Commit"), and Bezos's 2016 shareholder letter describes asking a person "will you gamble with me on it?" when there is no consensus.

When consensus is the right goal

• The group will live with the result daily (a team working agreement, an on-call rotation).
• Buy-in is the main risk: a technically fine decision people quietly undermine fails.
• The decision is hard to reverse and affects everyone similarly (for some of these, consent, meaning no one has a reasoned objection, is a lower bar that is enough; true consensus is for when everyone must actively do the work).

When it is the wrong goal

• The decision is reversible and cheap to change.
• One person has the expertise or accountability.
• The deadline is short or the cost of delay is high.
• Positions are driven by different interests that cannot all be satisfied; then waiting for agreement just rewards the most stubborn.

How I tell the team which mode applies
At the start of each decision I state in one sentence: "This one is owner decides after input: Priya decides by Friday, and I want your concerns by Wednesday." Other labels: "we need consent: raise objections that would make this unworkable," or "we need consensus: all of us have to be able to say yes." I post the label in the decision doc so it is not renegotiated mid-way.

Worked example of disagree-and-commit
A team debates two logging libraries, with 5 engineers split 3 to 2. The change is reversible within a sprint, the on-call lead wants to start migrating this week, and each further week of debate delays the migration for all five engineers. Debate has already run for a week without converging, so the lead consults for two more days, decides, and asks the two dissenters to state their concerns for the record. They agree to commit, and the team agrees to review in a month. Moving ahead is right because the decision is reversible and the cost of continued debate exceeds the cost of a wrong guess.

Did the consensus process succeed?
Judge it by outcomes, not unanimity: Was the decision made on time? Did people execute without relitigating it? Were important objections heard and recorded? Did it get reopened? A consensus nobody follows through on failed, however warm the meeting was.

Direct answer

A kickoff meeting exists to turn a brief into shared commitments: everyone leaves knowing what is being built, who owns each decision, what the first milestones are, and how progress will be checked. I would send a short brief beforehand, spend the meeting on risks and decisions instead of presentations, assign three roles explicitly, and follow up in writing within a day. ("Cross-functional" means the people come from different functions such as product, engineering, design and support, so they usually report through different functional managers and no single team lead controls everyone's priorities.)

Terms

• Round robin: going around the group in a fixed order so each function speaks in turn.
• Timebox: a fixed limit on how long an item gets; when the time is up the group decides or defers.
• Dependency: something one team needs from another before its work can finish.
• Green (risk status): on track; amber means at risk and red means blocked.
• Status theatre: a meeting where people read out updates for show and nothing is decided or changed.

Structured elaboration

• Pre-reads (sent two working days ahead, about 15 minutes to read): a one-page brief (problem, target users, the one metric that defines success, explicit non-goals, which means things we are deliberately not doing), a draft timeline, and a list of known risks and open questions. Ask people to comment in the document before the meeting so the live time goes to what is still unresolved.
• Roles: the facilitator runs the agenda and timeboxes (a neutral person such as the technical program manager or a peer, not the loudest stakeholder). The decision owner is the single person who makes the call if the room does not converge: one named person per decision. Here the product manager is the decision owner for scope and the tech lead is the decision owner for how it is built; each decision type has exactly one owner, both are named in the invite, and if a question straddles the two the product manager decides after hearing the tech lead. The scribe captures decisions, actions and open questions live (rotate this among engineers so it is not always the same person).
• Success criteria for the meeting itself: scope and non-goals confirmed; every open question has an owner and a due date; milestone dates agreed or a dated plan to agree them; the follow-up cadence accepted.

Worked example: a 60-minute agenda for a "saved searches" feature

The blocks sum to 60 minutes. Two decision checkpoints are built in: at the end of the scope block (is scope confirmed, yes or no) and in the 12-minute block (which decisions are made today and which are deferred with an owner and date).

Sample decision-checkpoint wording from the decision owner: "I have heard from engineering, design and support. The decision is email alerts only for version 1; push comes later. Maya owns the scope document, and I will confirm the milestone dates by Friday. If anyone sees a reason this fails, say it now; otherwise we move on." The same wording works when the room has not converged: "We are not going to agree on this today, so I will decide after hearing everyone. Here is my call and why."

Follow-up cadence

• Within 24 hours: the scribe sends a recap with decisions, actions (owner and date each) and open questions.
• Weeks 1 to 4: a 25-minute weekly sync reviewing only the action list and risks, plus an asynchronous written status update on a fixed weekday.
• A milestone check at the end of week 2 and week 4 against the success metric. After that, move to every two weeks if risks are green.

Trade-offs and pitfalls

• A kickoff packed with presentations leaves no time for risks. Keep the author's talk to a summary and use the pre-read for detail.
• Too many invitees dilutes ownership. Invite the people who decide or do the work; send the recap to everyone else.
• A decision owner who is not named in the invite means the meeting ends in "let's take this offline". Name them, and say what happens if consensus fails (the owner decides after hearing the room).
• If the pre-read is unread, spend the first ten minutes reading silently instead of re-presenting.