Facilitation, Consensus Building and Decision Driving Questions

Direct answer

Settle who decides before any debate starts, agree the criteria before anyone argues for an option, test the finalists against the team's own workload, record the decision with its dissent, and turn each minority concern into a measurable tripwire with an owner and a review date.

1. Decision rights first

Name one decision owner (for example the staff engineer or architect for the platform) and the consulted groups (application teams, operations, security, finance). Using the DACI idea (Driver, Approver, Contributors, Informed), one Approver means a debate ends in a decision rather than a stalemate.

2. Gather requirements as facts

Collect from each team: data size and growth, read/write mix (how many operations read data versus change it), consistency needs (whether every reader must see the latest write immediately, as with account balances), query shapes (the kinds of questions the application asks the data), availability target (how much downtime is tolerable), who will run it, and migration cost. Write them as numbered requirements so people can challenge a fact, not a preference.

3. Agree criteria and weights before naming options

Weights sum to 100. Fixing them first stops the weights drifting to favour whoever's option is on the table.

4. Structure the debate

• Each advocate writes a one-page proposal and also writes the strongest case against it.
• A time-boxed proof of concept (a small real trial, say two weeks) per finalist on the same dataset and same pinned test scripts (scripts fixed in advance so nobody can tune them for one option), so the results compare. Benchmarks that use a vendor's best-case setup do not count.
• A 60-minute decision meeting: 10 minutes per finalist, 20 minutes of questions, 10 to decide.

5. Capture the decision

Write a decision record (context, options, decision, consequences, revisit triggers), stored with the code.

6. Address minority concerns after the decision

Each concern becomes a row the dissenter helps own.

Then close the loop: tell the dissenters in person which of their concerns shaped the plan, and invite them to disagree and commit, meaning they support execution while their concern stays on record.

Worked example

Three finalists, 30 requirements, a 10-day proof of concept using one anonymised copy of production data. After the trial each finalist gets a 1 to 5 score per criterion (illustrative):

For each finalist, multiply every score by its weight and add the results. Finalist A: 30x4 + 25x3 + 15x5 + 15x3 + 15x4 = 120 + 75 + 75 + 45 + 60 = 375, which is 3.75 out of 5 after dividing by 100. Finalist B: 150 + 50 + 45 + 60 + 30 = 335, or 3.35. Finalist C: 90 + 125 + 60 + 45 + 45 = 365, or 3.65.

A wins narrowly over C (375 against 365), and the gap is small enough that the room should look at where C is stronger (operability) before deciding, which is why the score informs the decision and does not make it. The meeting ends with a written decision, one owner, and two tripwires, each with a date on the calendar.

Trade-offs and pitfalls

• A debate without a named decider turns into lobbying.
• Short proofs of concept favour the technology people already know; budget time for learning.
• Dissent that is only "noted" breeds quiet resistance; give it a measurable check.

Direct answer

Prepare the room before it starts, then run a five-phase hour that separates facts from feelings, looks at ownership as a design problem in the system (where did responsibility become ambiguous?) instead of a fault in a person, and ends with decisions that define who owns what and a small number of actions with names and dates.

Before the session

Speak privately for ten minutes with the two or three people most affected, to learn the facts as they see them and set the expectation of a constructive session. Collect the list of missed deliverables in advance.

Terms

• Decision rights: an explicit statement of who makes which kind of call, for example "the PM decides scope, the tech lead decides how it is built, QA can block a release for a severity-high bug". Defining them removes the ambiguity that causes missed deliverables.
• Timeline wall: a long sheet or digital board with time running left to right, on which people stick cards for events in order.
• Check-out: a one-word round at the end where each person says how they leave the room (for example "clear", "tired", "hopeful").
• Read-back: the facilitator reads the agreed actions and owners aloud so errors are fixed before people leave.

60-minute plan

Total: 5 + 15 + 20 + 15 + 5 = 60.

Prompts to use

• Gather data, first colour: "Silently write one card for each thing that happened, with the date. Facts only." Second colour: "Now, on a different colour, write how that moment felt to you." Reading the cards in time order shows where the facts and the feelings diverge.
• Generate insights: for each missed deliverable ask "What made this likely?" and then "Where did the work wait, and who was it waiting for?" The answers describe the system, such as a handoff nobody owned.
• Decide: "Who is willing to own this deliverable type from now on?" and then "Who has the final say if the owner and a stakeholder disagree?" The second answer is the decision right, written on the wiki next to the owner.

Ownership map: who each person believed owned each deliverable

For each missed deliverable, ask each person to write who they believed owned it. Overlaps and gaps appear.

Illustrative. The first row shows a real ownership gap (each side points to a different team and QA names nobody), which is a fixable cause that needs no blame. The second row shows a mismatch in expectations: PM and engineering both believe the PM owns release notes, but QA expects engineering to write them, so the people who verify the notes assume a different author than the one who thinks they own them. Neither side is careless; one named owner on the wiki resolves it.

Keeping it constructive

If someone makes a personal accusation, redirect: "What in how we work made that likely?" If it is a genuine interpersonal dispute, take it out of the room and handle it separately after the session.

Actions (example)

1. For each deliverable type, write one named owner on the team wiki (owner: PM, due Friday).
2. Add "owner named" to the ticket template (owner: Lee, next sprint).
3. Review the first two actions at the start of the next retrospective (owner: facilitator, date: the next retrospective).

Trade-offs and pitfalls

• Spending the whole hour on the story of what went wrong; time-box it.
• Letting senior people speak first and set the tone.
• Ending with twelve actions; choose three.

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.

Direct answer

Without formal authority, I would make decisions visible rather than add approvals. I would start with one shared, lightweight decision log, name a single owner on every entry, and pilot it for a limited period. The goal is that anyone can answer "who decided what, when, and why" in under a minute, with no extra meetings.

1. Diagnose first (one week)
List the last five or so decisions that caused confusion. For each, note who the real decider was, whether it was written down anywhere, and where people learned of it. That keeps the fix tied to actual pain.

2. The smallest useful system

• A decision log: one page or table the team already visits. Columns: decision, owner, date, options considered, rationale, status (proposed, decided, revisited). A filled row (illustrative): Decision: use the existing Postgres database for the reporting service. Owner: Dana (tech lead). Date: 12 March. Options considered: Postgres or a separate warehouse. Rationale: the team already runs Postgres and volume is small. Status: decided. For a large or hard-to-reverse choice, the row links to a full decision record, a longer write-up of the context, options and consequences.
• One named owner per decision (DACI's single Approver; DACI stands for Driver, Approver, Contributors, Informed). I ask the people in the room, "Who is the owner for this?" before the meeting ends.
• A 3-line summary posted within a day of any meeting that makes a decision: what, who owns it, why.

Because I lack authority, I offer it as a service: "I'll keep the log if people tell me the outcome."

3. Handle recurring disagreements
If the same arguments recur, add four small tools, each lightweight:

• Decision template: the log columns above, nothing more.
• Escalation ladder: a one-line rule such as "if undecided after two discussions, the owner decides within 48 hours; if the owner is blocked, escalate to X".
• Pre-mortem: before a big decision, ask "imagine this failed in six months; why?" to surface concerns early.
• Async forum: a written thread with a close date, for decisions that do not need the whole group.

4. Pilot and measure
Run it for about six weeks on one team's decisions. Measure (illustrative): the share of decisions with a named owner, the count of decisions re-opened because "nobody knew we'd decided", and a short pulse question (a one-question survey, here "I can tell who decided things"). Keep only what moves those.

Worked example: if the log shows 12 decisions in the pilot and 3 were re-opened for lack of clarity, then 25% (3 of 12) were re-opened. If the next period shows 1 of 10 re-opened (10%), the process is plausibly helping, though small counts are noisy and I would say so.

5. Pitfalls
Do not make the log a gate; if people feel it slows them, they will skip it. Do not retro-fill blame, meaning do not use the log afterwards to work out whose fault a past decision was; it records decisions going forward. Ask leaders to cite the log when asked "who decided?", which builds the habit without authority.

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.