Facilitation, Consensus Building and Decision Driving Questions

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

I would separate three things that usually get blurred: who must be heard, who may block, and who decides. Legal, privacy, operations and customer success get a defined input channel before the meeting, a defined scope in which they can stop a launch, and a seat in the decision meeting that is protected from technical airtime. Technical voices keep one place where they dominate: the separate deep-dive. I judge success by what changes in decisions and by late surprises, not by attendance.

Decision rights

I use DACI with exactly one Approver per decision. The Driver runs the process and makes sure a decision happens; the Approver is the single person who makes the final call; Contributors are asked for input before the decision but do not decide; Informed people are told afterwards. On top of that I add a short list of required reviews written down in advance. A required review means: "if privacy says this fails our data rules, we cannot ship until it is resolved", which is real influence, not a courtesy invite. The scope is narrow and written per decision type: legal, privacy, security-of-data and safety by default, plus the function that has to run the result when the change is operational (in the table, Operations holds the required review on the support escalation process). That keeps it from becoming a veto on everything. Customer success holds the Approver seat on that row; where it is only a contributor, it relies on its three pre-read lines and its protected speaking slot.

The three levels differ: a contributor is consulted and can be overruled; a required review can stop the launch within its written scope; the Approver decides everything else. If privacy and the business disagree, the rule is written in advance: on the listed legal or data-rule questions privacy's "fails" stands until fixed, and on anything outside that scope the Approver decides after hearing it, with the escalation going to a named executive within one working day. In the room privacy says: "I cannot approve storing this outside the region until a transfer agreement exists. A regional store meets my requirement, and so does a single region now with expansion later."

Pre-reads

• One page, plain language, written 48 hours ahead, with a section called "what this means for each function" in place of an architecture tour.
• Each non-engineering function returns three lines: "what I need to be true", "what worries me", "what I can accept".
• Jargon gets a one-line glossary in the pre-read. A technical appendix exists but is optional.

Meeting structure (50 minutes)

The rows sum to 50. The technical deep-dive is a separate session, so the decision meeting is not a design review.

How I tell whether it is working

• How many decisions changed because of input from a non-engineering function (read from the decision records).
• How many late objections or launch-time surprises occurred, compared with the previous quarter.
• Who spoke: a quick tally of speaking turns in a sample of meetings.
• A short pulse question to those functions: "was your input visible in the outcome?"

Worked example (illustrative)

Expanding a feature to a new region. Privacy flags in their three lines that the data would be stored outside the region. Under the old pattern this surfaced at launch week. Under the new process it appears in the pre-read, engineering offers two storage options, operations notes one needs extra on-call, and the Approver picks the regional one at a cost of two weeks, with the reason recorded.

Trade-offs and pitfalls

• Too many required reviews turn into a veto culture; keep the list short and revisit it twice a year.
• Giving people a seat without changing the order of speaking changes nothing.
• Measure outcomes, not attendance: a quiet room can mean agreement or silence.

Direct answer

I would reframe the debate from "how much to log" to "which decisions need which data, at what sensitivity, for how long, at what cost". I would get the facts from each function first, separate options by data type, propose privacy-respecting alternatives, and have a named owner decide with Legal's sign-off recorded.

Facilitating the conversation

1. Frame: the goal is enough data to make product decisions, with the minimum personal data, within budget and the law. A decision owner is named (usually Product with Privacy or Legal holding a veto on compliance: the right to block any option that breaks the law, whatever its other merits). Retention periods in the table below are illustrative.
2. Get the facts per function:
   • Product: the specific questions the data must answer (for example, funnel questions: at which step of sign-up or checkout users drop off, and which feature is used in what order), and how soon.
   • Infra: event volume, storage and processing cost, and what retention would cost.
   • Privacy/Legal: which fields are personal data, what consent was given (the permission users agreed to for specific uses of their data), which rules apply (data minimisation means collecting only what a stated purpose requires), and retention limits (how long data may be kept before it must be deleted).
3. Classify the data: anonymous aggregate counts, pseudonymous user IDs (a stable ID that is not a name; under GDPR such data is still personal data if it can be linked back to a person using other information, so Recital 26 treats it as personal data and it still needs a lawful purpose, retention limit and Legal's view), and direct personal data. The trade-off differs for each.
4. Offer alternatives that serve the need: aggregate counters instead of raw event streams; sampling a fraction of users; replacing identifiers with random IDs; keeping raw events short-lived and aggregates long-lived; or doing the aggregation on the device so raw data never leaves (the app counts locally, for example "opened export 3 times this week", and uploads only that count).

Cost arithmetic (illustrative)

Suppose 50 million events per day at about 1,500 bytes each: 75 GB per day. Thirty days of raw retention is 2,250 GB (2.25 TB). Sampling 10 percent of events cuts that to 225 GB. To turn this into money, assume (illustratively) 0.50 per GB for ingesting and indexing logs: 2,250 GB x 0.50 = 1,125 per month for full raw logging, against 225 GB x 0.50 = 112.50 per month at 10 percent sampling. Plain storage at an assumed 0.02 per GB-month is only 45 versus 4.50, so the real cost driver is ingestion and querying, which is worth knowing before arguing about retention. This turns "too expensive" into a number the group can weigh against what Product loses by sampling.

A proposed outcome

Product gets the funnel questions answered, Infra's cost drops, Privacy's risk is smaller.

Closing and documenting

Record the decision, the data collected, purpose, retention, owner, Legal's sign-off and a review date. Where Legal has the final word on compliance, make that explicit rather than negotiating it.

Trade-offs and pitfalls

• Treating the dispute as cost versus privacy hides the real question: what decisions the data supports.
• Do not accept "we might need it later" as a reason to collect personal data.
• Sampling can bias small segments; say so in the record.

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

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.