Facilitation, Consensus Building and Decision Driving Questions

Direct answer

I would not open with a big debate. I would (1) interview each side privately first, (2) agree in the room on who decides and how, (3) turn the vague priorities into written criteria, (4) separate disagreements about facts from disagreements about values, (5) convert the factual, uncertain ones into small experiments, (6) rank what is left under a fixed budget, and (7) close with a written decision record. I stop a technique when it no longer produces new information or movement, and then I change technique, call the decider, or park the question with a trigger date.

Facilitation means shaping how a group talks so it can reach a decision, without being the one who picks the answer.

Techniques, in order, and why

1. Pre-interviews (one-to-one, 20 minutes each). Ask each leader what they are protecting and what would make them wrong. This shows whether the conflict is about facts ("will the new data pipeline hold?"), goals ("reliability vs. speed of research"), or authority ("who gets to say?"). The right technique differs for each.
2. Name the decision and the decision rule. Before any content, state: what is being decided, by when, and who decides (for example one accountable executive, after hearing both). Also state whether the group is aiming for consensus (everyone actively agrees) or consent (nobody has a strong objection they can defend). On a high-uncertainty initiative, consent is usually the realistic bar. Contrast: on "run the reliability work first", consensus needs both leaders to say "yes, I want this"; consent only needs each to say "I can live with it and I cannot show it would cause harm". Said aloud: "We are deciding the Q1 split of platform capacity by Friday. Maria decides after hearing both of you. I am asking for consent, not unanimity."
3. Silent writing, then read-out. Everyone writes their top three priorities and the assumption each depends on, before anyone speaks. This stops the loudest voice anchoring the room (anchoring means the first number or opinion voiced pulls everyone else's thinking towards it) and puts infra and data science on equal footing.
4. Assumption map. Plot the written assumptions on two axes: how much the plan depends on it (impact), and how unsure we are (uncertainty). For example: "the platform will fall over under the new workload" sits high impact, high uncertainty (top right, needs a test); "the team can add a dashboard in a week" sits low impact, low uncertainty (low priority to test; just proceed). Disagreements about high-impact, high-uncertainty assumptions are not settled by debate.
5. Turn uncertainty into an experiment. For each such assumption, agree a spike (a short, timeboxed investigation) with a kill criterion (a pre-agreed result that means we stop or drop the option) written down: "if the pilot job cannot read the feature table (the shared table of model inputs data science uses) under the agreed latency in two weeks, we drop plan B." Both sides sign the test before seeing the result.
6. Constrained ranking. For the priorities that remain, use dot voting with a hard budget so trade-offs are forced. Dot voting means each person gets a fixed number of dots to spend on options.
7. Close with a written decision record: decision, owner, the dissent, and the date it will be revisited. Example: "Decision: reliability work gets 60% of Q1 platform capacity. Owner: Maria. Dissent: data science believes 40% delays the experimentation feature by a quarter. Revisit: after the load test, in two weeks."

Worked example (illustrative)

Infra wants a quarter on reliability work for a shared training platform. Data science wants that capacity for a new experimentation feature. A 90-minute workshop: 10 minutes decision rule, 15 silent writing and read-out, 20 assumption map, 25 experiment design, 15 dot vote, 5 decision recorded (10+15+20+25+15+5 = 90). With 6 participants and 5 dots each, 30 dots are spent. The assumption map shows the real dispute is one belief: "the platform will fall over under the new workload." That is a testable fact, so the group agrees a two-week load test (running the platform under simulated traffic at the new workload's size) instead of voting on it. Dots then rank the remaining items, and the 5-minute decision record names the load test result as the trigger for revisiting the split, so the decision is made on time without pretending the factual question is settled.

When a technique has stopped helping

Watch for these signals, then switch rather than push harder:

• The same argument is repeated with new wording and nothing new is learned in a round.
• Positions get more extreme, or people go quiet and disengage.
• A timeboxed round ends with no movement on the ranking.
• The disagreement type has changed (a fact became a values clash).

Responses: change method (debate to experiment, or open discussion to silent writing), narrow the question, hand it to the named decider with both views written up, or park it with an explicit revisit trigger.

Trade-offs and pitfalls

• Pre-interviews cost time but prevent a surprise fight in the room.
• Voting on a factual question gives a popularity answer, not a true one.
• Experiments delay the decision; use them only where the answer is cheap to learn and expensive to get wrong.
• Never let consensus-seeking become an unspoken veto. If the rule is "decider decides after input", say so on slide one.

Direct answer

I would invite everyone whose knowledge shapes what the model must do, not only the builders: fraud operations, risk and policy, legal and compliance, support, data science, data engineering, payments engineering and product. I would run a three-hour working session that starts from real fraud cases and decisions rather than model ideas, and I would leave with a requirements document that fixes the action the model triggers, the cost of each kind of mistake, how labels are defined, what data exists at decision time, and who owns what.

Who and why

• Fraud analysts: know how fraud actually looks and how it is caught today.
• Risk/policy and legal/compliance: set limits on automated decisions and explanations.
• Support: hear from customers wrongly blocked.
• Data science and data engineering: know what can be predicted, how labels are produced and what is available at decision time.
• Payments engineering and product: where the score is called and what the customer sees.

Session (180 minutes)

The segments sum to 180 minutes.

What we hold at the end

A one-page requirements record: the decision and action; latency budget; the error-cost table; label definition and delay; data available at decision time; explainability needs; a success measure agreed by risk and data science; fallback behaviour; named owners; and open questions with dates. Filled-in rows look like this (illustrative):

The error-cost table the session fills in:

Cost of each outcome to the business (no fraud and no block is the zero point):

Read the table this way and the break-even compares the expected cost of blocking, (1 - p) x 8, with the expected cost of approving, p x 120. The worked example below uses exactly that comparison.

Worked example: why risk must be in the room (illustrative numbers)

Suppose a missed fraud costs $120 on average and wrongly blocking a good customer costs $8 in support and lost margin. Blocking pays off when p x 120 is greater than (1 - p) x 8, where p is the model's fraud probability. That gives p > 8 / 128 = 0.0625. Only the business can supply those two dollar figures, and they set the threshold the model team must tune to. Without them, data science would choose a threshold by an accuracy metric that ignores the money.

How I would know it worked

• Data science and engineering can start the design without returning with new requirements questions.
• Risk signs off the success measure in writing.
• The open-questions list has owners and dates, and after two weeks most are closed.

Trade-offs and pitfalls

• Inviting everyone makes a long meeting; keep the core group small and consult others in advance.
• Do not let the session drift into model choice; ownership of options belongs to the design phase.
• Labels are the hidden risk: if confirmed fraud is only known weeks later, the team must plan for that delay from the start.

Direct answer (a story skeleton to adapt with your own details)

I led a decision on a shared service's retry and timeout behaviour (how long a caller waits for a reply, and how often it tries again when there is none) across four teams in three time zones, where no single meeting time worked. I structured it as a written, staged process: a short proposal document, a fixed comment window, a recorded decision rule, a narrow live call only for what stayed unresolved, and a decision record at the end. Disagreements were resolved by tying each objection to a written criterion, not by who argued best.

Situation. Four teams (checkout, payments, notifications, platform) each wrote their own retry logic against one internal API, and a retry storm had caused a partial outage. (A retry storm is what happens when many clients, all failing, retry at once, so the extra traffic keeps the struggling service down.) The platform team wanted one shared client library with standard behaviour. Two teams objected: one feared losing control of its latency budget (the time it allows for each call before its own page becomes too slow), another feared a migration cost. I was the engineering lead coordinating, and I had no authority over the other teams.

Task. Reach a decision all four would implement, within three weeks, with no hope of a common meeting slot.

What I did, step by step

1. Wrote a one-page proposal with: the problem and the incident evidence, three options (shared library, per-team guidelines, a gateway-level retry policy, meaning one central entry point retries on behalf of every caller), the criteria (reliability under load, migration effort, team autonomy, time to ship), and who decides. The decision rule: the platform director decides after the comment window, with a named owner per team consulted.
2. Ran a 5-business-day comment window. All comments went in the document, each on a specific section. Teams in later time zones lost nothing because nobody needed to attend anything.
3. Kept a visible objections table: objection, who raised it, which criterion it touches, status (addressed, accepted as risk, or open). Seeing the table kept the debate on the criteria.
4. Resolved disagreements in writing first. The latency-budget concern was answered by making per-call timeouts configurable in the proposal. The migration-cost concern was answered by an adoption schedule plus an adapter (a thin wrapper that lets old call sites keep working unchanged on the new shared client library) for old call sites. Only one disagreement stayed open: mandatory versus recommended adoption.
5. Held one 30-minute call with the two owners on that single item, with a pre-read, at a time chosen to be awkward for me rather than for either owner's region. The other two teams were not on that call, so its outcome went into the document and was shared with everyone immediately for comment.
6. Wrote the decision record (below) and posted it where all teams watch.

Decision record excerpt

Result. All four teams implemented it, and the dissenting team's concern was met by the configurable timeouts. In a real answer, state the outcome you measured. Its shape, with illustrative figures: "In the two quarters before, retry-related incidents paged us 5 times; in the two quarters after adoption, 0 times, and median checkout latency during incidents stayed within its target." Only quote figures you can back.

What I would do differently. The proposal did name the decider, but in one line at the bottom, and one lead asked in week one who actually decided; answering it late cost two days of mistrust. I would put the decision rule in the first paragraph and get the platform director to confirm it in writing before circulating the draft. I would also ask each owner for a one-line "what would make you change your mind" up front.

Pitfalls to avoid in the telling

• Do not claim everyone agreed. Say who dissented, and how the dissent was handled.
• Name what you wrote down; "we aligned asynchronously" without an artefact is not evidence.

Direct answer

I would pick a story where the disagreement was real, I did not own the outcome by title, and I can show a decision rule I introduced. The shape: I separated the people from the positions, made each side state what it was protecting, got the group to agree on how the decision would be made before debating options, and ended with a named owner, a date and a written record. The story below is an illustrative skeleton; swap in your own specifics.

Situation and task

A high-risk launch (moving existing customers onto a new billing system) had four senior stakeholders in conflict: Engineering wanted a phased rollout, Finance wanted a single cutover date (one day when every customer switches to the new system at once) aligned with quarter-end, Support wanted a freeze on their busiest weeks, and Legal wanted invoice-wording changes reviewed first. Nobody reported to me. I was asked to get a decision in two weeks because the vendor contract date was fixed.

Actions I took

1. Pre-conversations (1:1s). I asked the Engineering, Finance and Support leads: "What is the worst outcome you are trying to prevent?" (I did not hold this conversation with Legal beforehand, which is the mistake I describe in the reflection.) That turned positions ("single cutover") into interests ("no reconciliation mess at quarter-end", where reconciliation means matching the books to the billing records so the totals agree).
2. Agreed the decision rule first. In the group session I proposed: the launch owner (a named VP) decides if we do not reach consent by the end of the meeting, and every decision is judged against three shared criteria: customer harm, financial accuracy, and ability to roll back. Consent here means "I can live with it and will not block it", which is a lower bar than consensus, where everyone actively agrees with the outcome.
3. Facilitated the compromise. I put the options on a whiteboard and asked each side to name one thing they could give up. The outcome was a phased rollout in two waves (two groups of customers moved on different dates), with the finance-critical accounts moved in wave two after quarter-end close, a support freeze in the two busiest weeks, and Legal's wording review as an explicit gate before wave one.
4. Handled the people who disagreed. The Finance lead still preferred a single cutover. I asked her to write the condition under which she would revisit (for example, reconciliation errors above an agreed limit) so her concern became a monitored trigger, not a lost argument.

What the group committed to, and accountability after launch

The decision record (a short written note) named: the decision, the owner (the VP), the two wave dates, the rollback trigger, and who reports the reconciliation check at a 1-week and 4-week review. At the reviews I presented the data and the group confirmed or changed course. An example record, illustratively: Decision: phased billing migration in two waves. Owner: the launch VP. Wave one: standard accounts. Wave two: finance-critical accounts, after quarter-end close. Rollback trigger: reconciliation errors above the agreed limit. Reviews: 1 week and 4 weeks.

Result and reflection

Both waves shipped on the planned dates and the Finance concern was checked at the reviews instead of re-litigated. What I would do differently: I held the Legal conversation too late; next time Legal joins the pre-conversations, not the group session.

Trade-offs and pitfalls

• Splitting the difference can produce a plan nobody believes in. Test the compromise against the shared criteria.
• Do not claim the whole group "agreed" if it was consent; say who was uneasy and what you did about it.
• Avoid invented numbers in a story; use the real, qualitative outcome you can defend.

Direct answer

The goal of the half-day (240 minutes) is to leave with one written definition, one canonical query and one named owner for each contested metric, plus a lightweight process for changing them later. I would make the disagreement concrete before debating it: have all 8 teams compute the metric on the same handful of sample accounts and compare answers. Definitions argued in the abstract produce vague compromises; definitions tested against real cases expose exactly where teams differ. A canonical query is the one agreed piece of code or logic that every report must reuse for that metric.

Structured elaboration

Pre-work (one week before): each team submits the definition and query it uses for its top 3 metrics and nominates one person with authority to agree for that team. The facilitator then groups the up to 24 submissions (8 teams x 3 metrics) by metric name and picks the six to resolve live: the ones where at least two teams give different definitions and the number reaches executives or customers. The rest are settled in writing afterwards, using whatever the session decides.

The blocks sum to 240 minutes.

Worked example: "churned customer" on six sample accounts, as of 31 March

Three definitions are in use: Finance counts a customer as churned if the subscription ended in March; Product counts a customer as churned if there has been no login for 30 days or more; Customer Success counts customers who gave notice in March.

Finance counts 3 (A, D, E), Product counts 2 (A, C), CS counts 3 (A, B, D). Totals alone hide that the sets differ. The agreed outcome: churn = subscription end date within the month, owned by Finance; "dormant" (no login 30 days) and "notice given" become separately named leading indicators owned by Product and CS. The disagreement is resolved by giving each idea its own name.

Escalation policy: if a metric is not agreed within its 10 minutes, the named metric owner decides at the end of the session; if the owner is contested, the head of data governance (the person accountable for company-wide data rules) decides within 48 hours.

Governance so decisions stick

• Every metric has one owner, a version number and a change request (a short form asking to change a definition). A filled-in example:

Metric: churned customer          Current version: v1.0
Requested change: count a customer as churned when the subscription end date falls in the month (v2.0)
Why: Finance and Product report different churn counts for the same month
Affected: board dashboard, CS weekly report, 2 forecasting models
Expected effect: March count moves from 2 (login-based) to 3
Owner: Finance      Decision date: 15 April

• Changes are reviewed on a fixed monthly cadence. A breaking change is one that moves a number people already publish (like the churn example above), so it gets a notice period and the old name is kept as a labelled alias: the old metric name still works but is tagged "deprecated, now means v2.0" until dashboards are migrated.
• Enforcement in the pipelines: dashboards read from the canonical query or a shared metrics layer (one governed place where each metric is defined once, so every dashboard asks that place instead of writing its own query). An automated reconciliation test recomputes the metric from the canonical query each night and compares it with the number each report shows. Example result: canonical churn for March is 3; the Product retention dashboard shows 2 (it uses the login-based definition, which the six-account table counts as A and C), so the test flags that dashboard as drifted and names its owner. The CS report, which counts notices given, also shows 3, the same total as canonical churn, so a test that compares only the totals would pass it even though its set (A, B, D) differs from the canonical set (A, D, E). That is why the test should also compare the account lists (which accounts are counted), not just the totals: it would then flag the CS report as measuring a different thing and it would be renamed to the "notice given" indicator.
• The glossary lives next to the code, with the six-account table above kept as the worked example.

Trade-offs and pitfalls

• Eight teams means eight vetoes. Pre-agree the decision rule or the day becomes a negotiation.
• Do not redefine metrics silently afterward; restated history needs an announcement.
• Skipping the sample-case step produces definitions that read fine and still disagree on edge cases.