Facilitation, Consensus Building and Decision Driving Questions

Direct answer

I would stop the escalation, reset the meeting to the decision we need, make each side's argument visible and testable, find the real crux, and end with either a decision or a named owner, a test and a date. I treat the 15 minutes as five timeboxed steps (each has a fixed time limit).

Terms: psychological safety means people believe they can speak up, disagree or admit a mistake without being punished or humiliated. Technical debt is the accumulated cost of earlier shortcuts in code or design. Parking lot is a visible list where off-topic points are written down to be handled later. Crux is the one point the disagreement actually turns on. Disagree and commit means voicing an objection, then backing the decision once it is made.

Step-by-step (15 minutes)

That is 2 + 2 + 5 + 3 + 3 = 15.

1. Pause and reset (2 min)
Interrupt calmly: "Let me pause us. I can hear that this matters to everyone." Slow the pace, lower my voice, and name the norm: "We're arguing about the design, not about each other." If a person is being personal, I address the behaviour briefly and privately later.

2. Restate the decision (2 min)
"We need to choose between A and B by the end of today, or agree how to find out." Put it on a shared screen. Anything else goes to a visible parking lot.

3. Structured positions (5 min)
Each side gets about two minutes, no interruptions: what they believe, the evidence, and what would change their mind. I write these on the board. Listening to a time-limited statement is safer than a free-for-all and reveals whether the dispute is about facts or priorities.

4. Find the crux and surface assumptions (3 min)
Ask: "What would have to be true for A to be right? For B?" Often the disagreement reduces to one assumption (expected traffic, how hard a migration is). Write it down. If it is a fact, assign someone to test it. If a value (speed versus long-term maintainability), it belongs to the decision owner.

5. Decide or define the next step (3 min)

• If the crux is resolved or the owner can decide: they decide, state the rationale, and anyone who disagrees states it for the record (disagree and commit).
• If not: write the outstanding uncertainty, an owner, a test (e.g. a prototype or benchmark), a date and a decision-maker. Never end with "let's think about it".

Worked example (the five steps on a real argument)
Two engineers argue: A wants to add a cache in front of a slow search endpoint this week; B wants to redesign the query and indexes. Step 3 on the board: A: claim a cache fixes latency in days; evidence most requests repeat; would change my mind if hit rates turn out to be low. B: claim the query is the real problem; evidence the slow part is one unindexed lookup; would change my mind if indexing does not help in a test. Step 4, the crux: "will the same requests really repeat?" That is a fact, so one engineer measures repeat rates by Thursday. A second question, whether to accept some technical debt (cache invalidation logic to maintain) in exchange for speed, is a value, so the owner decides it. Step 5: the owner records "measure first, decide Thursday" and who runs the measurement.

After the meeting
Send notes within a day: decision or next step, outstanding uncertainties, owners and dates. Check in privately with anyone who seemed hurt.

Why it works / what I would change
It protects safety through norms, equal time and a visible process, and it converts heat into a testable question. If the argument is clearly personal rather than technical, I end the meeting and handle that separately. If the owner is absent, the correct output is a scheduled decision, not a vote of those present.

Direct answer

With 30 minutes, I would spend the first minutes making the disagreement productive by restating the shared goal, having each side state what it needs and fears, and agreeing the decision rule. Then I would look at scope options and decide, ending with a visible recap of what was decided, who does what and by when.

Time structure (30 minutes)

Total: 30 minutes.

The first few minutes

• State the shared goal ("ship something customers value by the date, at a quality engineering can support").
• Name the decider (the product manager decides scope, engineering decides what is feasible and flags risk) and the timebox.
• In the 3 to 11 minute segment, once each side has stated its position, ask each person to say back the other's position in one sentence ("say it back"), for example: "So what I hear is that you need the export feature in this release because three customers are waiting, and you are worried about the date. Have I got that right?" It lowers heat and proves they have listened.
• In the same segment, ask each to name the one thing they cannot give up and one thing they can.

Scope options (10 minutes)

Write the scope as four lists on a shared screen: must have, should have, could have and won't have this time (the MoSCoW prioritisation convention, from the DSDM project method). The won't-have list is what makes "what is out" explicit. For a reporting feature, a filled version looks like: Must: export to CSV, date filter. Should: scheduled email of the report. Could: PDF layout options. Won't this time: saved report templates. Engineering gives a rough effort for each item (small, medium, large), Product gives the user value. Move items across lists with the reason recorded. This turns the argument about "scope" into a discussion of specific items.

Ending

Decide using the rule agreed: consent first ("can everyone live with this?"), the decider breaks ties. Recap aloud: what is in, what is out, what is deferred and when it will be revisited, who owns the next step. Send the recap within the hour.

The same method when the disagreement is about evaluation results

If two stakeholders give conflicting feedback on, say, a model's evaluation results, first ask what metric and data each is looking at; gather what is missing (the same test set and metric for both); then structure the decision: what threshold justifies shipping, and who decides. Example: Product quotes 94% accuracy (the share of predictions that are right) on its own sample; Engineering quotes 89% on the held-out test set (data the model has never seen, used only for scoring). Neither is wrong; they used different data. Agree one test set and one metric, then a threshold such as "ship if recall on fraud cases is at least 85% on that set", with the product lead deciding if the number lands within two points of it.

Trade-offs and pitfalls

• Letting each side talk for 15 minutes leaves no time to decide.
• Splitting every item in half produces a scope nobody wants.
• Without a recap, each side leaves with a different memory of the decision.