Interteam Conflicts

Old picture of a sea battle with many shipsDescription: The team is having severe or recurring differences with another team in the organization. To address the root causes, adopt a formal method for coordinating their activity such as agile programs and release planning. If that is not possible, in addition to the techniques below, consider those under the “Conflicts,” “Decision-Making,” “Solution Creativity,” and “Support for Decisions” topics in this section.


SLAs and SOWs


A service level agreement (SLA) or statement of work (SOW) is typically signed between a company and a client. But they also are effective tools for improving coordination between teams within an organization. Though experts differ on their definitions, I use SOWs for goods, including software or reports, and SLAs for ongoing services. For example, a software team might use an SOW with an internal client to deliver a database, while the IT support team sets up an SLA regarding availability of that database after it is delivered. Details on the contents of each follow the “Steps” section.


  1. As a team, meet with the other team or its representatives to reach the agreements listed below for the appropriate document.
    Note: Unless both teams are self-directed, include the team managers in the discussions.
  2. Set an action item for someone to create the document.
    Note: Include a signature block to be signed by the team managers.
  3. Obtain verbal approval of the teams and team managers for the document.
  4. Set an action item to collect signatures from the team managers, even if both teams are self-directed.
  5. When the document is signed and returned, create action items to:
    1. Implement the agreements.
    2. Monitor performance.
    3. Conduct three-month and six-month reviews with the other team, and annual reviews after that.
      Tip: Submit a copy of the SLA or SOW to the lowest-level manager who oversees both teams, in case of later disputes.


An SLA should include at least:

  • A description of the service.
  • Service hours.
  • Quality targets (frequency, availability or “uptime,” errors, etc.).
  • Support requirements.
  • Disaster plans.
  • Reporting methods.


An SOW should have at minimum:

  • Purpose of the work.
  • Description of the end product, such as features or use cases (User A can do x and y; User B can do z).
  • Quality targets.
  • Milestone dates to track progress.
  • Delivery date.
  • Costs (in labor hours if not money).
  • Client team responsibilities, with dates where appropriate.

Interface Conflict Resolving Model

Define the Relationship

  1. Choose three to four representatives of each team in conflict.[1]
  2. Have the team reps meet separately by team for 30 minutes and use flip charts to develop lists that answer this question: “What would the ideal relationship between our groups look like?”
    Note: You are looking for behaviors, shared goals, and/or shared performance measures.
  3. Bring the groups together and have a representative of each group explain the items on their group’s list, while the other reps listen without interrupting.
  4. Allow the other team’s reps to ask clarifying questions only—not challenging questions yet.
  5. Repeat steps 3 and 4 for the other team(s).
  6. Help the reps develop a single list.
  7. Have the groups go back into separate 30-minute meetings to develop lists that answer this question: “What does the actual relationship between our groups look like?”
  8. Repeat steps 3–6.

Address Differences

  1. Still working together, have the teams identify the differences between their actual and ideal lists.
  2. Help them create action items to address the differences, assigning members from each team to be responsible for each action item. That is, for each action item, a Group A rep and a Group B rep will be assigned.
  3. Establish a method for the responsible parties to report to both groups on their progress.
  4. Schedule a follow-up meeting for three months later to review progress, and keep meeting every three months for as long as the groups are working together.

Wants and Needs


This technique is useful when you have two or more groups with multiple demands, among which they are having trouble finding a compromise. We often confuse the words “want” and “need.” For example, in the business world you will often hear someone say, “I need your input on this report,” when the report will go forward whether or not you provide your input. So the speaker really meant, “I want your input on this report.” That is okay, but it can be helpful to recognize the difference.

This is not to suggest we have to speak perfectly all the time. But this particular mix-up sometimes causes problems for us when we are trying to reach common ground on an issue. We decide we must have our way on something, when in fact we could live without that action. This belief makes compromise difficult. The steps below help to clarify the core issues of the disagreement.


  1. Have the different teams break into separate meetings and do the following steps in fifty minutes (followed by a 10-minute break), giving them copies of this technique if needed:
    1. List each of your requests related to this issue on a board or flip chart in one column.
    2. Add two blank columns and label them:
      • Wants
      • Wishes
    3. One by one, review each request and try to have the team move it to one of the other columns if it can, using these definitions:
      • “Wants” are requests you can live without, but they would greatly improve your work day if you had them and probably give a lot of benefit for their costs (not just money costs).
      • “Wishes” are requests that would be nice to have, but would not make a big impact on your work day, or would cost a lot relative to the amount of benefit they gave.
    4. When you have moved all the requests you can, write “Needs” above the requests that have not been moved.
    5. Review each “Need” to see if it meets this definition: “You or your company must have this to continue doing your or the company’s work; if you cannot get this, the cost of the related work will likely exceed the benefits.”
  2. Move any items that do not meet that definition into the Wants column.
    Note: It is okay to break up an item into multiple levels for separate columns. For example, maybe the request on the table is for a 10% improvement in productivity. Is 10% a Need, or is it more accurate to say 5% is a Need, 7.5% a Want, and 10% a Wish? If so, split the item that way.
  3. When the teams regather, list the items:
    1. Write “Needs,” “Wants,” and “Wishes” across the top of the board.
    2. Say: “We are going to list these from each team, one item at a time, taking turns. I will also ask for an explanation about why each item was placed where it was. This will not be a time for discussion. Instead, the job of the people in the other teams is to practice active listening. If you do not understand the person’s explanation, let me know, and I will work with the speaker to restate it.”
    3. Have one team read off its first Need and explain why it decided the item fit the definition of a Need, as you write the item under Needs.
      Note: Do not keep track of which team each Need belongs to.
    4. Have the next team do the same thing with its first Need, and continue the process until all teams have provided all of their Needs, Wants, and Wishes.
  4. Say: “From this point forward in our discussions, we are going to focus only on finding compromises regarding Needs. The following rules apply:
    • “Assume all Needs must be met, perhaps with minor adjustments, whether or not you as an individual believe each is a Need.
    • “Use Wants and Wishes as trade-offs for compromise.”
  5. For each Need, build consensus for a wording everyone can agree to implement.
  6. When all Needs have been met, have the team consider whether any Wants can be met, then any Wishes.
  7. Write up the agreement and distribute it for final approval by each team’s normal means.



If an impasse has been reached on a particular issue despite trying other techniques in this section, a formal trial:

  • Forces the teams to carefully review their facts and arguments,
  • Controls the emotion in their interactions, and
  • Introduces an element of play that can relieve tensions.

A manager with oversight of both teams, or a panel of neutral managers, make the decision, and that decision is binding. The teams’ jobs at that point is to move forward with implementing the decision.


  1. Schedule a location and a date with the teams, allowing at least a week for preparation.
  2. Provide a copy of this technique to a representative of each team, and tell them they can make copies for their team members.
    Note: You are free to modify the process that follows as desired, but if you do so, inform the representatives at this point so they can prepare. Do not make further changes unless absolutely necessary.
  3. The teams should prepare drafts of their opening and closing arguments (see below) before the trial date—essentially, position papers that will guide their cases. Limit these to 10 minutes for the opening and five minutes for the closing.
  4. Identify a manager responsible for both teams or one from another division to serve as a judge, or three people at any level to serve as a judicial panel.
    Tip: A panel is especially effective if multiple organizations will be affected by the decision. If you go this route, make sure you have an odd number of people to avoid ties, and that each judge keeps a backup informed in case of absence on trial day. Obviously, choose people with equal or no links to each team in the trial.

Start the Trial

  1. On trial day, prepare a room in courtroom fashion:
    • A table at one end with chairs for each judge.
    • Two tables facing the “bench” for each team’s “lawyers,” no more than three per team.
    • Rows of chairs behind for spectators.
  2. When everyone has gathered, review the rules out loud:
    • No interruptions during opening or closing arguments.
    • No interruptions ever from the spectators. If they wish to provide information, they should pass it quietly to one of their lawyers.
    • Lawyers may interrupt to object to statements made by witnesses or other lawyers on three specific grounds:
      • Speculation—The person is speculating outside of known facts.
      • Hearsay—The person is reporting something they heard secondhand.
      • Leading the witness—The lawyer is phrasing the question in a way to get the witness to give a particular answer.
  3. If the teams cannot agree on who goes first, flip a coin.

Conduct the Trial

  1. Have each legal team make its “opening argument,” a formal presentation regarding that team’s position.
  2. Allow each team to call up to three witnesses to support the team’s position, such as:
    • People in or outside of the company acknowledged as experts in the field in question;
    • The team members who did the research that unearthed particular facts; or
    • People who have faced that particular issue before.
  3. After each witness has testified, allow the other legal team to cross-examine if desired.
    Note: For the sake of time, do not allow a continuing exchange of cross-examinations; the lawyers can address any other issues raised in their closing arguments.
  4. Before a witness steps down, allow the judge(s) to ask questions.
  5. When all witnesses are done, break for 15 minutes to allow each team to edit its closing arguments.
  6. Reconvene and allow each legal team to make its closing argument.
  7. Allow the judge(s) to ask the lawyers questions.

Enter a Judgment

  1. Recess for no longer than one business day for the judge(s) to make a decision.
  2. Once a decision is made, have the judge or panel prepare a short statement explaining why they made that decision.
  3. Reconvene with all participants.
  4. Disclose and explain the decision, noting that it is final.
  5. Give the teams a deadline for creating together an implementation plan for the decision.


Full citations for the footnotes are here.

[1] Technique based on Zander 1993.

Tell the world: