When two teams keep having the same fight, the cause is often in how the work was set up rather than in the people. One team is measured on something the other team’s work keeps breaking. Or both teams draw from the same pool and nobody ever decided who goes first. Or work changes hands at a point where no one was named as the owner. Cross-functional conflict tends to look like two reasonable leads defending their own teams. Nobody changes the setup, so the same problem keeps coming back.
This guide is for the lead in the middle of it. You can’t tell the other team what to do, and they can’t tell you. Most advice on conflict between teams says to bring in a mediator or senior leadership, which doesn’t help much when nobody neutral is coming. A dispute like this also calls for a different kind of conflict resolution from a falling-out between two colleagues. Research on this exact situation is thin, so treat what follows as a structured approach and not a research finding.
Why do two teams keep fighting about the same thing?
A dispute that keeps coming back is telling you something. If the two leads had simply misread each other, one good conversation would have fixed it. When the dispute returns after that conversation, the work is often arranged so that both teams can’t win at the same time.
This isn’t a new idea. In a 1985 paper on interdepartmental conflict as a neglected part of management, Bloch argued that departments clash because of a built-in tension: each one wants to run its own work, but each also depends on the others to get it done.
The examples below are invented to show how that tension plays out. The names are made up, and each pair of teams shows a different cause.
The first cause is opposed metrics. Each team is measured on a number, and doing well on one number hurts the other. Support and engineering often end up here over bugs. Support wants escalated bugs fixed fast because its resolution time depends on it. But engineering wants a predictable sprint, and every urgent bug breaks the plan. The two leads in our example had already sorted it out once over coffee.
The second cause is a shared resource. Two teams draw on the same limited thing, and nobody has decided the order. A recruiting team working through one queue of open roles is a common case. When a hiring lead’s role slips down that queue, it feels as if someone took it. The recruiting lead and a hiring lead in our second example had agreed an order once in a meeting.
The third cause is undecided ownership at a handoff. Work passes from one team to another, and nobody was named as the owner at the moment it changes hands. Sales and customer success often fight over this. A salesperson makes a promise to close a deal, and customer success inherits both the promise and the renewal number that depends on it.
How do you tell which cause you are dealing with before you talk to anyone?
Before you meet the other lead, spend twenty minutes on your own with three questions about the setup. You don’t need anyone’s permission for this, and it changes what you’ll say when you do meet.
The first question is whose number moves when the other team does its job well? Write down what each team is measured on, and ask what happens to your number when the other team hits theirs. If one goes up while the other goes down, you have opposed metrics. Neither lead is doing anything wrong, because each one is doing exactly what they’re measured on.
The second question is what are you both drawing from the same pool? It might be people or budget. It could also be a queue, a test environment or a slot in the release plan. If nobody has ever decided the order for that pool, you have a shared resource problem. Each request will feel like a grab, because there’s no rule that says it isn’t one.
The third question is who is named as the owner at the moment of handoff? Find the exact point where work leaves one team and lands with the other, and ask who owns it in the hour after. If both teams say “them”, the handoff has no owner. If both say “us”, it has two owners, and that causes the same fight.
A wrong guess is costly because you’ll walk into the meeting arguing about the wrong thing. Say the real cause is a shared queue but you open on metrics. The other lead will defend their numbers even though their numbers aren’t the problem, so the meeting goes nowhere and you both leave sure the other one is being difficult.
Sometimes you’ll find two causes at once. Disputes between sales and customer success are often like this, because the handoff has no owner and the renewal number sits with one team while the promise came from the other. If you find two, pick the easier one to fix and raise the other as a second item, since trying to solve both in one meeting usually means you solve neither.
What do you say to the other team’s lead, and what do you ask them to sign off on?
The first conversation has one job, which is to agree what the problem is. It isn’t the place to agree the fix. That feels slow, but there’s a reason for it. If you arrive with a solution, the other lead hears a plan written from your side. Even a fair fix will look like the answer that suits your team. They’ll spend the meeting finding holes in it.
Open by describing the setup instead of the other team’s behavior. You might say: “I think our teams are measured in a way that means we can’t both hit our numbers when a bug gets escalated. Can we write down what’s going on before we try to fix it?” That sentence blames the arrangement rather than the person, and it asks for something small. Describing a problem is easier to agree to than a fix, so it’s a yes the other lead can give.
What you’re asking them to sign off on is a one-page shared problem statement. It should hold five things:
- the situation as both of you recognize it, in plain words
- each team’s measure or constraint in that team’s own terms
- the decision that’s stuck
- what each side loses under the current setup
- a date by which the decision will be made
Each team’s measure goes in its own words because a description written by the other side always sounds slightly off. If the engineering lead writes down support’s target, support will argue with the wording before they get to the problem. The date matters too, because without one “we’ll decide” can turn into another month of the same fight.
The page is short because a longer document turns into a case for one side. It’s written down because a page can be forwarded without the argument attached. If this ends up with a shared executive, the page is what they’ll read, so it has to make sense to someone who wasn’t there.
This meeting is between two leads about how the work is set up. If what you need is a conversation with one colleague about how they’ve treated you, our guide to conflict resolution for individual contributors covers that. If you both want a neutral person to run a session, our guide to mediating conflict at work explains how that works. Both are different jobs from this one.
Who decides when neither of you can tell the other what to do?
“Every bug is urgent to support. That’s why none of them can be.” Daniel runs engineering in our first example. He said this in his first meeting with Megan, who runs support. He was right on the facts, but he said it as if it ended the discussion, which made him hard to work with.
Megan’s team is measured on how fast escalated tickets get resolved. Daniel’s team is measured on how much of each sprint’s planned work gets finished. Six months earlier they’d agreed over coffee that Daniel would take “the really bad ones” straight away. That held for about a month, until a big release came along and they spent three weeks arguing about what “really bad” meant.
When they sat down again, they wrote the one-page statement first. It took two meetings, but it showed them the stuck decision clearly: nobody had ever decided who gets to say a bug is urgent enough to break the sprint.
Who gets to decide between two peer leads?
You have four realistic options. Each one has a cost, so it helps to say the cost out loud before you choose.
| Option | When it works | What it costs |
|---|---|---|
| One named decider for this decision | One team carries most of the consequences | The other lead has to trust that person |
| Split by type of decision | The decision breaks cleanly into parts | The line between the parts blurs under pressure |
| A rule agreed in advance | The same call comes up again and again | Rules have edges, and people learn to game them |
| A shared executive | Only someone above both of you can make the trade-off | It’s slow, and it takes the decision out of your hands |
The first option draws on an idea from Bain & Company’s RAPID decision tool. Bain separates the person who recommends a decision from the person who decides it. Other people can give input, but one named person makes the call. Two peer leads can borrow that idea for a single decision, where one of you recommends and the other decides. That can feel strange between equals, but it’s often better than a decision that belongs to both of you and so to neither.
Whichever option you pick, someone has to write it down. That should be the lead with more to lose if it stays vague, because that person has the strongest reason to get the wording exact and will notice first when it stops being followed.
Megan and Daniel combined the second and third options. Megan decides how severe a bug is, using a written definition they agreed together. Daniel decides when in the sprint it gets fixed. They also agreed one rule: any bug that stops customers from logging in or paying jumps straight into the current sprint, and everything else waits for the next planning meeting. Megan wrote it down, because support takes the angry customer calls when the line is fuzzy.
It mostly worked, though not in the way either of them hoped. Daniel’s sprints became more predictable, but support’s resolution time for lower-severity bugs got worse because those bugs now wait for planning. Megan’s number took a hit, and she had to explain that to her own manager. Part of the calm that followed also had nothing to do with the rule, since the big release shipped and the pressure dropped.
When is it right to go to a shared executive?
There’s no fixed rule here, but three situations make a good case for going. The first is when the two of you can’t agree on the problem statement after a fair attempt. Two honest meetings is a reasonable test. The second is when the fix needs a trade-off only someone above both of you can make. That might be budget, a priority call or a metric neither of you can change. The third is when a fixed deadline is at risk and waiting will cost more than asking.
Megan hit the second one. Her resolution target was set by the head of customer operations, so she couldn’t change how it was measured. She and Daniel went together to the VP above them both, brought the page and asked whether lower-severity bugs could be measured separately this quarter. The VP said no, so that part is still open.
How you go matters as much as whether you go. Go jointly if you can, and bring the page. Ask for a decision, not a verdict on the other lead. “Daniel is blocking us” invites the executive to judge a person. “We can’t both hit these two targets, and we need you to choose” asks them to do the part of their job only they can do.
Some people see going upstairs as a failure, but it isn’t one if you go with a page and a question. It becomes one when you go alone with a complaint. If the other lead won’t come with you, tell them you’re going and send them the page first. A surprise escalation reads as going over their head. That costs the working relationship more than most single decisions are worth.
What if the other lead will not meet at all?
Try once more in writing: send the draft page, ask them to correct anything that’s wrong and suggest a date. If that gets no answer either, this is no longer a setup problem the two of you can fix together. The section on where this approach breaks covers what to do next.
What do you tell your own team while this is going on?
Your team already knows something is wrong, and if you say nothing they’ll fill the gap with guesses. Tell them plainly what you’re working on with the other team and when you expect a decision. You don’t need to share every detail, but “I’m meeting Daniel on Thursday to agree who decides which bugs are urgent” is far better than silence.
Ask them to drop the “them” language. If your team talks about the other team as the enemy, that talk travels. When it reaches the other team, it will make your next meeting with their lead harder. The other team is working to its own targets in the same setup that’s frustrating yours, and you can say that without pretending the frustration isn’t real.
Give your team a route for real problems. If a bug is hurting a customer today, they need to know whether to bring it to you or follow the current process. A clear route stops them from raising every case in a shared channel, where each one turns into another round of the argument. If the tension is now inside your own team, our guide to handling team tensions as a manager is a better place to start.
How do you stop the same dispute from coming back?
A settled dispute needs three things written down if you want it to stay settled.
The first is a named owner for the decision. That’s a person, not a team or “both leads”, because someone needs to answer when a new case comes up that the decision didn’t quite cover.
The second is a decision log. It records what was decided, who decided it, on what date and what each side gave up. The last part is the one people leave out, but it’s what stops the argument starting again from scratch. When the trade-off is on record, nobody can later claim they never agreed to it.
The third is a reopen trigger. This is a stated condition under which either lead can bring the decision back. Megan and Daniel’s trigger might be “if more than five lower-severity bugs wait over two weeks in a month”. The trigger matters because without it, reopening a decision looks like an attack on the person who made it. Once it exists, reopening is part of the agreement.
Look back at the first two examples in this guide. Megan and Daniel had settled their dispute once already over coffee. It held until the pressure came back, and then neither of them could say what they’d actually agreed. The recruiting lead and the hiring lead had agreed an order for the queue in a meeting, but the hiring lead moved to another team and the new lead had never heard of the agreement, so the fight started again.
In both cases the first conversation did its job, since the leads talked it through and reached a decision. What they skipped was writing the decision down. If you want the two teams to work well together before the next dispute starts, our guide to cross-functional collaboration covers that groundwork. A collaboration assessment can also show where your own habits help or get in the way.
Where does this approach break?
Everything above assumes the cause is in the setup, and sometimes it isn’t. A lead may simply be treating your team unfairly, or acting in bad faith. A one-page statement won’t fix that because the problem is a person. Keep a factual record of what’s happened and raise it with your own manager.
The approach also breaks when there’s no one to go to. The shared executive may be part of the dispute, or there may be no one above both leads who has time for it. That leaves the two of you to settle it alone or live with it.
It also breaks when the other lead won’t engage at all, or when the fix is outside both your powers, such as a metric set at company level. Megan’s case is partly stuck there now.
Sometimes the friction is healthy. Two teams pushing on each other’s priorities can surface problems neither would catch alone. Research on whether disagreement helps or hurts is contested. A review of more than 100 studies by de Wit, Greer and Jehn found the effect depends on the conditions. That review looked at conflict inside teams rather than between them, but it’s still a reason not to treat every disagreement as something to settle.
If you’re not sure which of these you’re facing, start by writing the page anyway. If the other lead won’t help you write it, the setup may not be the whole problem. If you’d like more worked examples, our conflict resolution scenarios cover other kinds of disputes at work.
The two things to decide before the first meeting
Before the first meeting, decide two things. The first is which of the three causes you think you’re facing, and what you’ll do if the other lead sees a different one. The second is the opening sentence you’ll use to describe the setup without blaming their team.
That first reply is where these meetings tend to go wrong. You describe the setup and they hear an accusation, so the pull to defend your team is strong. That’s why it’s worth rehearsing first. You can practice the conversation with Merlin, Risely’s AI coach, before you have it for real. Merlin runs full coaching conversations natively in Slack and Microsoft Teams, or on the web.