Navigating Conflict with a Partner Team
Turning a disagreement with a partner team or PM into a decision — without spending the relationship.
This question tests how you handle friction with people you depend on and can’t command. Every senior leader hits roadmap disagreements, ownership disputes, and clashes with a partner PM over what to build. The interviewer isn’t looking for someone who avoids conflict or someone who wins it — they want someone who resolves it on the merits and comes out with the relationship intact, because you’ll be working with that team again next quarter. The answer follows the CARL shape and is judged on maturity: separating positions from interests, letting data decide, escalating cleanly, and genuinely disagreeing-and-committing.
What this question is really testing
Can you disagree hard on substance while staying easy on the person — getting to a sound decision without turning a colleague into an adversary?
How to answer- Separate positions from interests. The position is what they’re asking for; the interest is why. Two teams demanding opposite things often share an interest — ship on time, protect reliability — and once you find it, a third option usually appears.
- Anchor on the shared goal. Move from “my proposal vs yours” to “us vs the problem.” Name the outcome you both answer to and frame the disagreement as a joint search for how to get there.
- Let data decide. Where you can, convert an argument into an experiment or a measurement — a benchmark, a prototype, a cost model. Data depersonalizes the disagreement and moves it off ego and onto evidence.
- Escalate cleanly when genuinely stuck. If it’s a real priority conflict with no data tiebreak, take it up together — a joint, one-page “here are two reasonable options, we need a call” — never a one-sided complaint that ambushes the other party.
- Disagree and commit, and protect the relationship. Once a decision is made — your way or theirs — get fully behind it and say so publicly. Throughout, keep it about the work, assume good intent, and end on terms that make the next hard conversation possible.
- Interests surfaced beneath positions — not a battle of demands.
- Disagreement reframed as a shared problem, resolved on the merits.
- Data used to depersonalize and settle the technical question.
- Clean, joint escalation as a last resort — and genuine disagree-and-commit.
- The working relationship explicitly preserved or strengthened.
A worked example (CARL)
Context. A partner PM on an ads measurement team wanted my storage team to add a new low-latency read path for a launch on an aggressive timeline. I believed the design they were pushing — a synchronous fan-out read against our hot store — would risk our write-path reliability under peak load and put an SLA we owned at risk. They saw my pushback as infra slowing their launch; I saw their ask as trading my reliability budget for their deadline. It was getting tense in reviews.
Actions. I first took the heat out of it by getting off the position and onto the interest. In a 1:1 with the PM, I asked what they actually needed — and it turned out the true requirement wasn’t “synchronous reads,” it was “measurement fresh enough that the launch dashboard looks right within a few minutes.” That reframed everything: their interest was freshness, not the specific mechanism, and our interest was protecting the write path. Those two interests weren’t actually in conflict. Then I made the disagreement about data instead of opinion. Rather than argue the reliability risk in the abstract, my team ran a quick load test of their proposed synchronous path in a shadow environment and pulled the projected write-path latency degradation from Scuba — it showed the p99 regression I was worried about was real. But we also prototyped a second option: an async materialized view that refreshed every couple of minutes, which met their freshness bar without touching the hot write path. I brought both options, with the numbers, to a joint review framed as “here’s what we both need and here are two ways to get there.” The data made the choice obvious to everyone in the room, including the PM — the async view. On the one point where we still disagreed (they wanted a tighter refresh SLA than I thought was safe for the half), I didn’t dig in; we took that single sub-question to our shared director as a crisp either/or, got a call in a day, and I committed to it fully even though it wasn’t my first choice.
Results. The launch shipped on its original timeline on the async path, our write-path SLA held with no regression, and we avoided a synchronous dependency that would have been a reliability liability for years. Just as important, the PM and I came out as closer partners — they brought the next two designs to my team early, in the design phase, instead of arriving with a fixed solution.
Learnings. Most “conflicts” are really two correct interests hidden behind two incompatible positions — find the interests and a third option usually exists. Data resolves the technical half; disagree-and-commit resolves the rest. And how you handle the disagreement determines whether the next one starts from trust or from scar tissue.
Common follow-ups
What if the other person makes it personal or negotiates in bad faith?
How to answer- Stay on the merits. Refuse to mirror it — keep bringing the conversation back to the shared goal and the data.
- Address the behavior privately. Name the pattern directly in a 1:1, calmly and with specifics, rather than fighting it in public.
- Put it in writing. Summarize decisions and commitments in a doc so good-faith is the recorded default and drift is visible.
- Escalate the pattern if it persists. Bad-faith partnership is a leadership problem worth surfacing — with examples, not adjectives.
You disagreed and committed — and it turned out you were right. Now what?
How to answer- Don’t gloat. “I told you so” buys nothing and costs the relationship — skip it.
- Run a blameless review. Focus on what signal was missed and how the decision process can improve, not on who was wrong.
- Bank the credibility quietly. Being right and gracious is what makes your next disagreement carry more weight.
- Fix the system. If the wrong call was avoidable, add the check or data that would have surfaced it earlier.
How do you decide when to escalate versus keep working it?
How to answer- Escalate on genuine deadlock, not discomfort. If more discussion won’t change the inputs and the delay has real cost, it’s time.
- Exhaust data first. Escalate only once you’ve tried to settle it on evidence — leaders shouldn’t arbitrate what a benchmark could.
- Escalate together, with options. A joint, framed decision request gets a fast, durable call; a one-sided complaint gets a mess.
- Set a clock. Agree on a decision deadline so “keep working it” doesn’t become a silent stall.
- Design-review notes — pull the record of the disagreement, the options considered, and the decision that resolved it.
- Scuba / Unidash — pull the benchmark, load-test, or cost numbers you used to move the argument off opinion and onto data.
- GSD — pull from the project or milestone the conflict was blocking, and the unblock once it resolved.
- Phabricator — pull the prototype or shadow diff that let you test the two options instead of debating them.
- The internal wiki — pull from the decision doc that framed the escalation as a clean either/or.