Conflict Resolution and Difficult Conversations Questions

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

Start private, and address the impact of the behavior rather than the person's character. Only introduce a visible, group-level norm if the private conversation doesn't hold, and only escalate further if the pattern continues after that.

The move: graduated response, impact before intent

1. Private conversation first, soon after a recent instance. Waiting until frustration has built up makes the conversation land as an accumulated grievance rather than specific, addressable feedback.
2. Describe the observed behavior and its concrete effect, not a character judgment. "In the last two design reviews, an idea got dropped because it was talked over before it was finished" is addressable; "you're dominating meetings" is not.
3. Ask an open question rather than assuming intent. They may not be aware, or something specific (time pressure, a cultural norm from a prior team) may be driving it.
4. Agree on a visible cue or norm together, rather than telling them what to do. A shared agreement they helped design is one they'll actually hold themselves to.
5. If it continues, make the norm visible to the whole group without naming the individual (a "parking lot", a visible running list where off-track or repeated points get noted and revisited later instead of argued in the moment; or a rotating facilitator), and only return to a private, documented conversation, with specific instances, before considering escalation beyond the two of you.

Worked example

A senior engineer repeatedly interrupts and dismisses ideas in planning meetings, and quieter teammates have stopped proposing alternatives. You raise it privately, citing two specific instances and what was lost each time, and ask if something's driving the pattern. They didn't realize the effect and agree to a shared cue: a raised hand or a "hold that thought, back to you after" from whoever's facilitating. The behavior improves within a couple of meetings once the norm is visible and mutual rather than a private correction only they know about.

The same graduated shape applies to a very different kind of friction: two peers who've been informally swapping on-call shifts in a way the rest of the team has started to perceive as unfair. There the first conversation isn't about correcting a behavior, it's about surfacing that the arrangement looks uneven from outside and asking the two of them how they'd want it made visible. It still ends the same way structurally, not with a cue this time, but with a durable, documented agreement: who's allowed to swap, how it gets logged, and how the rest of the team is notified, so the fairness question doesn't quietly resurface every few weeks.

Trade-offs and pitfalls

Correcting someone publicly on the first instance humiliates them in front of peers and tends to produce defensiveness rather than change, even when the feedback is accurate. A private conversation that stays vague ("try to be more mindful in meetings") doesn't give them anything concrete to change and often needs repeating. When the underlying friction is actually about status or unclear role boundaries rather than a communication habit, a meeting norm won't fix it; that needs a structural conversation about who owns what, not a cue card.

I would frame the discussion around user impact, risk, and reversibility. A workaround is a temporary fix that reduces pain now, while the root issue is the underlying cause we still need to solve. I would ask: how many users are affected, how severe is the problem, and how risky is the workaround itself?

If the workaround is low risk and reversible, I would lean toward shipping it now and scheduling the root fix immediately after. For example, if users are blocked by a broken validation rule and we can safely relax it, I would ship the workaround, monitor errors, and commit to the deeper fix in the next cycle. If the workaround could corrupt data or create a bigger support burden, I would slow down and fix the root issue first.

I would make the decision explicit, document the trade-off, and assign an owner for the follow-up fix. That way the team is not pretending the workaround is the final answer, and users get relief as soon as it is safe to do so.

Direct answer

Before you run any decision process, spend real effort diagnosing why the two engineers actually disagree, because a fight over "microservices versus a monolith" is often a stand-in for a difference in risk tolerance, incomplete shared context, or different assumptions about future load, not a genuine disagreement about the tradeoffs themselves. Skipping that step and jumping straight to a vote or a scoring matrix often just re-runs the same argument with more paperwork.

Structured elaboration

1. Diagnose before you facilitate. Talk to each engineer separately first: what do they believe is true that the other doesn't, and what would change their mind. This surfaces whether the disagreement is really about facts (do we know the actual load numbers), values (how much operational complexity is acceptable), or unstated assumptions (what does "critical release" actually require).
2. Set shared decision criteria that address the real disagreement. For a microservices-versus-monolith debate that's often delivery timeline, the operational overhead the team can realistically absorb right now, and how reversible the choice is.
3. Structure a joint session. Both engineers present against the same criteria, time-boxed, with ground rules that keep it about the tradeoffs rather than who proposed what.
4. Use cheap evidence where you can get it. A short spike, a load estimate, or a smaller reversible first step (start as a modular monolith with clear internal service boundaries, split out the highest-load piece first) beats an all-or-nothing vote when there's even a little time.
5. Make the call and protect the relationship. If evidence remains inconclusive, use a predefined tie-breaker (lowest risk to this specific release), announce the decision and reasoning, and give the engineer whose approach wasn't chosen real ownership of something in the outcome, like validating it performs as expected or leading the next phase.

Worked example

Two senior engineers blocking a critical release disagreed over whether a new service should be built as a set of microservices or as a monolith. Talking to each separately, I found the disagreement wasn't really about microservices as a concept: one was worried about a repeat of a past incident where a monolith's deploys had gotten slow and risky, the other was worried the team didn't have the operational maturity yet to run several independently deployed services reliably under the release deadline. That reframed the real question as how to get some of the benefits of clearer service boundaries without taking on full operational complexity before this release. I ran a joint session using those criteria (delivery timeline, operational load the team could absorb right now, and reversibility), and we agreed on a modular monolith with clearly separated internal boundaries for this release, with the highest-load component identified as the first candidate to split out afterward. Both engineers signed off because the decision addressed what each of them was actually worried about, not just the term they'd been arguing over.

Trade-offs and pitfalls

Diagnosing the root cause takes time you may not have if the release is truly hours away, in which case you sometimes have to make the call with the best information available and do the diagnostic work properly in the retro instead. Framing everything as a compromise can produce a design that satisfies neither engineer's actual concern just to look fair, a good resolution addresses the real underlying worries, it doesn't just split the difference. And rotating ownership to the engineer whose approach wasn't chosen only builds trust if the role is genuinely meaningful, a token consolation assignment reads as exactly that.

In the moment, I would stop the blame loop and focus on the shared outcome. I would acknowledge the miss, ask for the facts, and clarify the handoff point that failed. By handoff, I mean the moment one team passes work to another with clear expectations.

I would say something like, "Let's separate what happened from who to blame. What was the requirement, what was the agreed due date, and what did each side believe was done?" If our requirements were unclear, I would own that and propose the next concrete step, such as a revised spec, a quick review, or a smaller interim deliverable so the project does not stall completely.

For the next milestone, I would prevent repeat issues by adding written acceptance criteria, a short handoff checklist, and a scheduled signoff before work starts. For example, if an API needed three required fields and one edge-case behavior, I would list those explicitly in the ticket and get both teams to confirm them before implementation. That lowers ambiguity and makes accountability much easier.