Conflict Resolution and Difficult Conversations Questions

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.

I would start by diagnosing the problem before trying to fix it. I would interview both teams, review the timeline, and map every requirement change, handoff, and missed dependency. I would look for evidence of changing scope, unclear ownership, or missing acceptance criteria rather than assuming the issue is attitude.

Then I would reset the operating model. First, create a single source of truth for requirements and decisions. Second, define ownership for each deliverable and each handoff. Third, add a lightweight change-control step so new requirements are reviewed, sized, and approved before they disrupt the plan. I would also establish a regular checkpoint where both teams see the same risks and blockers.

If I found that the real problem was unclear handoffs, I would introduce a standard handoff template with the deliverable, due date, acceptance criteria, and owner. For example, if design changes a flow, engineering should see exactly what changed and what stayed stable. That shifts the teams from blame to shared execution and usually stabilizes delivery quickly.

For example, say the two teams are the Checkout team and the Fulfillment team, and the requirement that kept shifting was how a partial refund should be represented in the order-status payload. A filled-in handoff entry might read: deliverable: order-status payload v2 for partial refunds; due date: the 14th; acceptance criteria: refund_amount and refund_reason fields present and validated against three sample orders; owner: the Checkout API lead. With that entry in place, Fulfillment could build against a fixed contract instead of a moving target, and in the next release cycle the number of last-minute payload changes dropped to zero, because any change now had to go through the same template before it reached Fulfillment.

Direct answer

Open by naming the shared goal, a reliable outcome, not a battle over who is right, and ask for the senior engineer's reasoning before pushing your own. Then convert the disagreement from a debate you might lose on seniority into a testable question you can both agree to settle with evidence.

Structured elaboration

The move is to make the disagreement testable instead of rhetorical.

1. Acknowledge their point genuinely first. Their concern (usually speed, risk of an ill-understood fix breaking something else, or a bad past experience with a similar change) is almost always real, even if you disagree with the conclusion. Naming it lowers defensiveness before you say anything else.
2. Ask clarifying questions to find where the actual disagreement lives: is it about how big the risk is, how expensive the fix would be, or whether it matters at all for this code path? "Keep it as is" often hides a different worry than the one being argued.
3. Reframe from positions to a shared question: instead of arguing whether the code should change, agree on what evidence would tell you whether the risk is acceptable.
4. Propose a small, timeboxed, reversible experiment that answers that question, and offer to do the work yourself so the ask costs the other person as little as possible.
5. Agree in advance on what happens if the result is ambiguous or if you disagree on the interpretation, ideally a specific third person or the component's owner, rather than letting seniority alone decide after the fact.
6. If the conversation is getting heated in front of others, move it to a smaller setting. A public back-and-forth in review comments tends to entrench positions; a short call rarely does.

Worked example

A training pipeline you both worked on had occasional flaky runs. A senior engineer argued the variance was tolerable and that chasing it would slow the team down for little benefit. Instead of arguing the point directly, you asked what would change their mind, and they said seeing the flakiness actually caused by the non-determinism, not just correlated with it. You proposed pinning the random seed and a couple of other sources of variation for a week and comparing failure patterns against the unpinned baseline, and offered to make the change yourself behind a flag so it was trivial to revert. Over that week, the pinned runs were noticeably steadier and the flaky failures you'd both flagged before stopped recurring in the pinned runs. The senior engineer agreed to keep the change, in part because the test answered their actual question rather than yours.

Trade-offs and pitfalls

If you are not equally senior, arguing your position directly can look like you are pulling rank in reverse, insisting you're right because you feel strongly. Anchoring on a testable question sidesteps that, because the evidence decides it, not either person's standing.
The "run an experiment" move can be used in bad faith to stall indefinitely. If someone keeps moving the goalpost after a test resolves the original question, that is the moment to invoke the pre-agreed tiebreaker rather than repeating the same ask.
Watch the trap of optimizing for being right instead of being reliable. Sometimes the senior engineer's read on the risk is correct and you are the one who should update, that outcome is a success for the process even when it is not the outcome you expected.

Situation: I worked closely with a partner who was strong technically but often changed direction late, which was creating churn for the rest of the team.

Task: I needed to give difficult feedback without damaging trust.

Action: I chose a private conversation and used the SBI format, which means Situation, Behavior, Impact. I said, "In yesterday's planning meeting, when the scope changed after we had already aligned with design, it created rework and made the team less confident in the plan." I kept the tone factual, then asked what was driving the change. It turned out they were reacting to pressure from another stakeholder and had not surfaced it earlier. We agreed they would flag uncertainty sooner and bring changes through planning instead of in the middle of execution.

Result: The conversation was uncomfortable, but it improved our working relationship because it was specific and fair. Their behavior became more predictable, and the team trusted them more because expectations were clearer.

Situation: I was presenting a rollout plan, and I noticed the room was quiet in a way that felt like confusion, not agreement. People kept saying "looks fine," but decisions were slowing down afterward.

Task: I suspected my style was not landing, so I wanted honest feedback before the pattern hurt delivery.

Action: I asked my teammate for a direct read after the meeting and made it safe to be candid. I said, "I think I'm giving too much context and not enough clear recommendation. What part lost you?" They told me I was burying the decision in details. I changed my approach by leading with the recommendation first, then giving only the two or three facts needed to support it. I also started ending meetings with "here is the decision, here is the owner, here is the deadline."

Result: My follow-up meetings became shorter and decisions were clearer. The main thing I learned was that feedback is useful when I ask for it early, not after a pattern turns into a problem.