Conflict Resolution and Difficult Conversations Questions

Direct answer

The first move is to stop treating the surface argument as the thing to resolve, and instead separate each person's stated position (what they're demanding) from their underlying interest (what they actually need or fear), because two people can hold incompatible positions while having compatible, even identical, underlying interests.

Structured elaboration

This is the positions-versus-interests distinction from negotiation practice: a position is what someone is asking for, an interest is why they're asking for it.

1. Talk to each side separately first, not together, while the surface disagreement is still hot. Ask not "what do you want" but "what happens to you if you don't get it" or "what are you actually worried about here," which surfaces the interest instead of relitigating the position.
2. Look for the mismatch. Often the two stated positions look mutually exclusive ("ship now" versus "don't ship now") while the interests underneath are compatible or unrelated ("I'm worried about a customer commitment" versus "I'm worried about a specific failure mode"), which means there's a solution neither position alone would have suggested.
3. Check your own read before acting on it: name the interest you think you're hearing back to the person ("it sounds like the real concern is X, is that right") rather than assuming you've diagnosed it correctly from the outside.
4. Only once you can state both interests accurately do you bring the two sides back together, now around the actual problem instead of the positions they opened with.

Worked example

Two stakeholders keep arguing about which vendor to select, and the conversation keeps circling back to feature comparisons that don't seem to be moving anyone. Talking to each separately, one turns out to be worried about a renewal timeline with the incumbent vendor that nobody else in the room knows about, and the other is worried about a specific integration risk they haven't clearly articulated because the conversation kept staying at the feature-comparison level. Once both interests are on the table, the feature debate turns out to be a proxy fight, and the actual decision hinges on two much narrower, more answerable questions.

When the conflict is specifically between a client's product owner and your own engineering lead, the same diagnosis holds but the three concrete steps look like this: first, a short separate conversation with each side to surface what's actually driving their position, the product owner's real driver is often a commitment already made to their own stakeholders, the engineering lead's is often a technical risk they haven't been able to quantify yet. Second, restate each interest back to its owner to confirm you've got it right before doing anything with it. Third, bring both interests, not both positions, into a joint conversation, framed as a shared problem to solve rather than a decision to make.

Trade-offs and pitfalls

• Jumping straight to a compromise on the stated positions, splitting the difference, usually satisfies neither underlying interest and just produces a worse version of the original disagreement later.
• Assuming you've correctly guessed the interest without checking it back can send you further from resolution, since you're now negotiating a made-up problem instead of the real one.
• This diagnosis takes time you may not have if the conflict is actively blocking something urgent. Sometimes the honest move is a short-term decision to unblock, with the interest-finding conversation happening in parallel, not gating everything.
• If one side's real interest is something they're not willing to say out loud, office politics, distrust of a specific person, you may not get a clean answer from asking directly, and you'll need to read between the lines of what they avoid saying, not just what they say.

Direct answer

Do not referee the argument as it is being stated. Replace it with an explicit, shared set of criteria both people would agree should decide it, then apply the current evidence against those criteria together. That turns "who is more convincing" into "what does the evidence say against what we already agreed matters."

Structured elaboration

The technique is to build a short evaluation rubric before evaluating either option.

1. Get both positions stated cleanly and confirm you actually understand each one: what specific evidence is each person relying on, and what specifically do they worry the other side is underweighting?
2. Before evaluating either option, agree explicitly on the criteria that should decide it. For a rollback question, that is typically current user-facing impact, confidence in the rollback path's own safety, time-to-mitigate for each option, and how reversible getting it wrong would be either way. Write the criteria down before scoring anything, so neither side can retroactively reweight them once they see how their preferred option scores.
3. Score each option against the criteria together using whatever evidence exists, metrics, logs, prior incident history, and be explicit about genuine uncertainty rather than picking a side just to look decisive.
4. If the evidence is genuinely close, favor the option that is more reversible or has a smaller blast radius (how much of the system, or how many users, would be affected if this choice turns out to be the wrong call) to try first, with a short timebox to check whether it is working, rather than staying stuck in the debate.
5. The same move applies well beyond rollback calls. Two senior engineers stuck on whether to keep one canonical schema versus letting each service own its own store, a polyglot-persistence approach, are having the identical shape of argument, both positions defensible, both citing real tradeoffs. The fix is the same: agree what you are actually optimizing for, consistency guarantees, query flexibility, operational overhead, migration cost, before either side argues their preferred architecture purely on its own merits.
6. Document the decision and the criteria used, not just the outcome, so the next disagreement does not have to restart from zero.

Worked example

After a release, one engineer sees a metrics dip and wants an immediate full rollback. Another argues the service's own rollback path has caused cascading failures before and prefers a narrower mitigation instead. Rather than debating who is right, you get both into a short session and agree the criteria are user impact, rollback safety, and time-to-mitigate. Looking at the current data together shows the impact is real but contained to one traffic segment. The team decides to reroute just that segment first rather than a full rollback, with a short window to confirm it resolves before deciding on the rest. Both engineers sign off, because the decision came from the criteria they had already agreed to, not from either one winning the argument.

Trade-offs and pitfalls

Building a rubric takes real time you may not have during a live incident. For genuinely time-critical calls, agree the criteria fast and verbally rather than trying to produce something polished, the discipline matters more than the artifact.
A rubric can quietly become a way to dress up a decision you had already made. Be honest with yourself about whether you are weighting criteria to justify a conclusion versus letting the evidence actually move you.
Not every disagreement is resolvable with more data. If the real disagreement is risk tolerance, how much uncertainty each person is comfortable holding, say that explicitly instead of pretending another round of data will settle it.

Direct answer

The core move is to contain the conflict where it's escalating, in public, and resolve it where it can actually be resolved, in private, fast, before positions calcify in front of an audience that's now watching and starting to take sides.

Structured elaboration

1. In the channel, post a short, neutral, visible action, not a defense of either side: acknowledge you've seen it, say you're taking it to a smaller conversation, and give a timeframe for an update. This does two things at once: it stops the pile-on (there's now someone visibly handling it) and removes the audience effect that's pushing both people to perform for onlookers rather than actually listen to each other.
2. Move the actual disagreement to a private thread, call, or room with just the people directly involved, not the whole channel's worth of opinions.
3. In private, separate the technical or factual disagreement from how it was expressed. Deal with the substance first, what's actually true, what's the fix, the interpersonal repair second.
4. Close the loop publicly with a short, factual update, not a play-by-play of who said what, so the channel sees resolution instead of silence. Silence is exactly what lets speculation keep running while you're offline resolving it.

What stays private versus public: facts about the decision and next steps go in the open channel, so the team isn't left guessing. Anything about tone, how someone felt, or who owes an apology stays in the private conversation. An apology performed for an audience usually lands worse than no public apology at all.

Worked example

A disagreement over how to fix a failing deploy turns into a public thread where two engineers are sniping at each other, and three other people pile on with "yeah, I've said this before too" replies that have nothing to do with fixing the deploy. In the next hour you post: "pausing this thread, syncing with [names] directly, will post the resolution here shortly." You pull the two into a 15-minute call and get the actual fix agreed, which turns out to be uncontroversial once it's not being negotiated in front of an audience. You post back in the channel: "fix is in, deployed, thread is closed, happy to talk process separately if anyone wants to." The tone repair, one engineer feeling publicly undermined, happens in a separate 1:1, not in the channel.

Trade-offs and pitfalls

• Silently deleting or hiding the thread instead of acknowledging it reads as covering something up, and it erodes trust faster than the original argument did.
• Taking a side publicly, even implicitly by DMing only one of the two people first, restarts the conflict with you now inside it.
• Closing the public loop with no timeframe leaves the channel guessing, which is exactly the vacuum that produces more piling-on while you're offline resolving it privately.
• Turning every heated public exchange into a formal process, a mandatory retro, a documented incident, chills people from disagreeing at all in open channels, which are often exactly where useful technical debate should happen, just not once it's turned personal.

Direct answer

Correct the substance, not the person. Ask a genuine clarifying question that lets the gap surface on its own, rather than stating outright that the executive is wrong, then close the loop afterward in writing so the corrected number is the one that actually circulates.

Structured elaboration

The move is to ask instead of announce.

1. In the moment, resist supplying the correct number immediately. Ask a narrowing question instead: which time window, segment, or filter is that number reflecting? This puts the burden of specificity on the claim itself rather than on you contradicting a senior person.
2. If their answer reveals the gap, you can now supply the fuller picture collaboratively: "if we include the rest of the segment, the picture actually reads differently," framed as something you are both now looking at together, not as you overruling them.
3. Keep the tone oriented at getting the number right, not at who was right, the room should feel like you are both solving the same problem.
4. If you cannot resolve it live, say so plainly rather than letting the wrong number stand as settled fact: tell the room you will confirm and follow up right after, so nobody walks out repeating an unverified claim.
5. Afterward, close the loop deliberately with a short, factual follow-up sent to everyone who was in the room, not privately to the executive alone. A claim made publicly needs a correction visible to the same audience or the wrong number keeps circulating in hallway conversations.
6. If there was a structural reason the number misled someone (a confusing default view, an ambiguous label, a filter that silently persisted), fix that root cause so the same misreading does not happen to the next person who opens the same view.

Worked example

In a review meeting, an executive states confidently that a key metric is trending down, based on what is on screen. You notice the view has a filter applied that neither of you set out loud. You ask which segment or date range they mean, and as you both look at it, it becomes clear the view is filtered. You pull up the unfiltered number live, and it reads essentially flat rather than falling. Afterward you send a short note to everyone who was in the room showing both views side by side, explain briefly why the filtered view was misleading, and change the dashboard's default so the unfiltered view loads first for anyone who opens it next.

Trade-offs and pitfalls

Correcting too bluntly, especially in front of the executive's peers, can make them defensive, and people tend to remember the discomfort of being corrected more clearly than the actual number. The clarifying-question approach exists specifically to avoid that.
If you only follow up privately or only after the meeting and never nudge it live, the wrong number is the one that gets repeated in the meantime, in follow-up emails, in someone else's summary, before your correction ever reaches them.
Do not let "asking a clarifying question" become a stalling tactic when you already know the number is wrong and could resolve it in ten seconds. Manufactured vagueness reads as evasive rather than diplomatic once people notice the pattern.

Direct answer

Lead with a one-line factual headline, not a narrative buildup, then follow immediately with what you're doing about it. Leadership's first question is always "what happens next," and making them wait for it while you explain the backstory reads as stalling.

Structured elaboration

1. Headline first: what's late, by roughly how much, stated plainly, no hedging language that makes people wonder if you're minimizing it.
2. One or two sentences of cause, at a level leadership can act on, a dependency slipped, a scope surprise, not a blow-by-blow of every technical decision that led here.
3. The plan: concrete next steps with owners and rough timing, even if the timing itself isn't final. "Here's how we'll know more by Friday" is a plan; "we're working on it" is not.
4. Handling pointed questions: answer what you actually know, say plainly when you don't know something rather than guessing to sound in control, and commit to a specific follow-up instead of a vague "I'll keep you posted." Take the most senior or highest-stakes question first rather than letting the conversation drift to whoever's loudest.
5. Close with a cadence: when you'll update again, and through what channel, so the room isn't left wondering whether this becomes a pattern of surprises.

Worked example

A high-visibility platform migration is going to miss its committed date by three weeks. In the leadership update, you open with "the migration will land three weeks past the committed date," not with a summary of everything that's gone right so far. You give the cause: "a dependency on the vendor's new authentication API turned out to need more integration work than their documentation implied." You lay out the plan: a revised, phased timeline with the riskiest piece de-risked first, and an owner and date for each phase. When someone asks "why didn't we know this two weeks ago," you say plainly: "we suspected it a week ago and confirmed it Tuesday, that's a valid gap, and here's what we're changing about how we track vendor dependencies going forward," rather than getting defensive or deflecting.

Trade-offs and pitfalls

• Leading with justification instead of the headline, explaining everything that went right first, reads as avoidance and makes people tune out before they hear the actual news.
• Promising a specific new date under pressure before you've actually validated it is the single most common way this conversation creates a second, worse version of itself two weeks later.
• Answering "I don't know" honestly feels risky in the room but is almost always received better than a confident guess that turns out wrong. Confidence you can't back up erodes trust more than admitting a gap does.
• Treating every pointed question as an attack invites a defensive tone that reads worse than the delay itself. Most pointed questions from leadership are about risk to other commitments, not about assigning blame.