PMI-ACP Conflict Management: Levels of Conflict, Root Causes and Collaborative Resolution

Facilitating conflict management means helping the people in a conflict understand what it is really about and how far it has escalated, then guiding them to a solution they work out together, rather than ruling on it for them or letting it grow unattended. On an agile team the agile practitioner is a facilitator and coach in conflict, not a judge: the team owns its disagreements, and the practitioner's job is to keep them productive and to step in with the right kind of help when they stop being so.

The PMI-ACP Examination Content Outline lists Facilitate conflict management as a task in the Leadership domain, with two enablers that give this lesson its structure:

1. Identify the root cause and the level of the conflict. Before acting, find out what the conflict is really about (often something structural, not personal) and how intense it has become.
2. Promote a collaborative approach to solve the conflict. Help the parties solve it together, choosing a different approach only when the situation calls for one.

Two ideas run through both enablers. First, not all conflict is bad: open disagreement about the work is how teams find better solutions, so the aim is to manage conflict, not to eliminate it. Second, the response must fit the situation: a calm technical debate, a guarded stand-off, an outage-time disagreement and a case of harassment each need something different from the practitioner.

Scope note: general problem solving with root cause tools such as Five Whys and Ishikawa diagrams is covered under the Leadership task Facilitate problem resolution; emotional intelligence and reading non-verbal cues sit under Empower teams; creating psychological safety and the team's initial working agreements belong to the Mindset domain; and the enabler Commit to the team's decisions even in disagreement belongs to the Mindset task Promote collaborative team environment, which the Leadership domain's introduction echoes. This lesson uses those ideas only where conflict needs them.

Healthy conflict is disagreement about the work, such as designs, priorities or approaches, that people argue openly and that ends in a decision; harmful conflict is when the disagreement turns into a contest between people, or goes underground. Agile teams depend on the first kind. Self-organizing teams make better decisions when members challenge ideas, surface risks and test each other's assumptions.

The warning sign is often too little visible conflict, not too much. Patrick Lencioni called this artificial harmony in The Five Dysfunctions of a Team: meetings are smooth and polite, but concerns surface only in corridors, decisions quietly fail to stick and problems the team could have caught are found later. Silence of this kind is not consensus. It means people do not feel safe, or do not see the point, in disagreeing out loud.

The practitioner's job with healthy conflict is to protect it. Lively debate can look like dysfunction to people who are not used to it, such as a stakeholder sitting in on a design session for the first time. When the debate stays on the work, attacks no one and ends in decisions, the practitioner explains why it is a strength and leaves the team to it, while continuing to watch for the signs of escalation described in the next section.

With a team that avoids debate, the practitioner makes challenge routine and safe, so that disagreeing no longer depends on someone's courage. Examples include rotating a "challenger" role whose job in a refinement session is to find the weak spot in the leading option, inviting quieter or newer members to speak before senior ones, and agreeing as a team that ideas are tested while people are respected. The test of any technique is whether it brings disagreement into the open where the team can use it. Anything that lets status settle the question, or moves disagreement out of the team's view, keeps the conflict hidden instead of making it productive.

Speed Leas' model describes five levels of conflict, from a problem people are solving together to a fight in which they want to harm each other, and each level can be recognised from the language and behaviour of the people involved. Leas developed the model for congregations; Lyssa Adkins brought it to agile teams in Coaching Agile Teams, and it is a widely used way for agile practitioners to gauge how intense a conflict is before deciding how to respond.

Telling neighbouring levels apart is what most questions on this model require:

• Level 1 vs level 2: at level 1 people still say what they think and why. At level 2 they have become self-protective and cautious. A designer who used to explain her reasoning in detail and now answers a developer's questions with "whatever works" and copies her manager on every reply has moved past level 1, even though nobody has attacked anyone.
• Level 2 vs level 3: keeping records to protect yourself is level 2; keeping score of who won, and overgeneralising about the other person, is level 3. The shift is from self-protection to wanting to win.
• Level 3 vs level 4: at level 3 individuals compete; at level 4 they have formed factions around a principle. Talking to others for advice is not the same as recruiting a side.
• Level 4 vs level 5: hardened factions, even ones that will no longer work together, are still level 4. Level 5 needs the intent to harm: threats, reverting or sabotaging the other side's work, total breakdown of communication.

The absence of threats or personal attacks does not mean a conflict is low-level. Diagnose from all the signals together, and remember that a conflict can move up or down the levels over time.

The right response depends on the level: the higher the conflict, the more structure the agile practitioner provides, from simply observing at level 1 to acting to prevent harm at level 5. Using a level-1 response on a level-4 conflict achieves nothing, and using a level-4 response on a level-1 disagreement takes the problem away from people who could have solved it themselves.

Two traps appear often. The first is staying hands-off too long: observing is right at level 1, but once people have become guarded and the working relationship is visibly suffering, trusting them to self-organise is no longer a reason to wait. The second is over-escalating the response: at level 3 the parties still share a goal and still talk, so they need help getting back to facts and agreeing next steps, not to be kept apart.

The logic behind the higher levels is about what the parties can still do. At level 4 each camp hears the other only through its principle, so joint sessions harden positions; separate conversations come first, and the sides meet again only when each has been heard. At level 5 the aim is no longer agreement at all: the first duty is safety, so the practitioner separates people and brings in the organisation's formal processes before any thought of reconciliation.

At low levels, let the team resolve it

At level 1, a servant leader lets the team work through low-level conflict itself and coaches it to do so, because a team that relies on a referee never learns to resolve its own disagreements. A respectful debate is the team doing its job. The practitioner's opinion on the technical question, or inexperience with the team, does not change that; stepping in to steer the outcome, redirect it or postpone it takes ownership of the problem away from the people who have to live with the answer.

The same principle explains a common anti-pattern. A practitioner who settles every small dispute personally feels efficient, but each ruling teaches the team that disputes belong to someone else, so more of them arrive. The fix is to hand the skill back: coach the team on how to settle routine disagreements among themselves, for example by agreeing simple decision rules, rather than moving the referee role to another person.

Letting the team resolve conflict is not the same as ignoring it. The practitioner keeps watching for the signs of escalation described above, and moves from observing to supporting as soon as the language and behaviour show the conflict has moved beyond a problem to solve.

The root cause of a conflict is the condition that keeps producing it, and on teams it is very often structural, not personal: an unclear shared definition, conflicting goals or incentives, unclear roles, a scarce resource, or a rule that people cannot actually keep. Addressing the personalities or the tone while that cause remains only buys a short pause before the next clash.

A useful habit is to ask "what are these people competing over, and why does it keep recurring?" before working on how they talk to each other. Feedback coaching or a reminder about respect cannot outlast an incentive scheme or a resource shortage that pits people against each other. When the cause lies outside the team, the practitioner works with the people who control it.

Read the constraints in the situation, too. A resolution that depends on something the scenario says is unavailable, or on a decision that has already been made, does not end the conflict now. The resolution that fits is the one the people involved can actually put into effect.

A collaborative resolution follows a simple sequence: agree what the problem is, agree what a good outcome must achieve, generate options together, and only then choose. Starting with solutions is the most common mistake, because each person arrives with a preferred answer and the session turns into a contest between them.

1. Agree a shared statement of the problem. Before anyone presents a solution, both parties describe the problem in words they both accept.
2. Uncover interests. Ask what each person needs and why (see Interests, not positions below).
3. Agree the criteria. Together, define what a good outcome must achieve, so options can be judged against something both accept.
4. Generate options before judging any. Build several possibilities together; separating creating from evaluating stops the first idea from anchoring the discussion.
5. Choose and commit. Select the option that best meets the criteria, using the team's decision rule.

What makes this collaboration is that the parties work on the problem jointly and look for an option that meets both sets of needs. If one side simply concedes, if each gives up part of what it wanted, if differences are set aside for the sake of peace, or if someone with authority decides for them, a different approach has been used; the next section compares them.

Interests, not positions

A position is the solution a person insists on; an interest is the need or concern that makes them insist on it, and conflicts that look deadlocked between positions can often be solved by meeting both interests. The distinction comes from Roger Fisher and William Ury's principled negotiation (Getting to Yes) and is at the heart of a collaborative approach.

Repeating positions, gathering more arguments for them or looking for a midpoint between them all keep the discussion on positions. Good interest questions are open and about the person's needs: what would this solution protect or make possible for you, and what worries you most about the alternative?

For example, an operations lead insists that releases happen only late on Saturday nights, while a developer insists on releasing every weekday. Asked what the positions protect, the operations lead names minimal customer impact and someone available to roll back; the developer names small changes and fast feedback. An option that meets both might be frequent releases at the daily low-traffic hour, with on-call cover and an automated rollback. That is collaboration. Settling on two releases a week is a compromise: each side gives up part of what it wanted, and neither need is fully met.

There are five classic approaches to resolving conflict, and collaborating (problem solving) is the preferred one on agile teams whenever the issue matters and there is time, but each of the others is the right choice in particular situations. The names below follow PMI's usage; the Thomas-Kilmann model describes the same five modes as competing, collaborating, compromising, avoiding and accommodating.

Choosing well means matching the effort to the stakes, the time available and any decision rule the team has already agreed:

• Low stakes: when the options are equally workable and little depends on the choice, a full interest-based session costs more than the issue is worth. The practitioner helps the team settle it quickly, with a timeboxed method the team accepts, so it stops consuming time and does not come back.
• Short-term pressure: when a decision is needed before there is time to collaborate properly and both views have merit, a compromise that is explicitly temporary keeps work moving, provided the fuller conversation still happens.
• Small differences: emphasising what the parties agree on and moving on is smoothing; it suits issues that do not matter much and would cost more to argue than to let go.
• Emergencies: under real time pressure the team relies on the decision rule it agreed in advance, such as a named role making the call, and reviews the disagreement once the emergency is over. A decision rule agreed calmly beforehand is what makes a forcing decision acceptable in the moment.

Recurring friction is best handled by the team agreeing, or updating, its own working agreement, because people keep agreements they wrote and ignore rules imposed from outside. If members keep scheduling meetings over each other's focus time, for example, the practitioner facilitates a team conversation that ends in a shared norm the team itself owns.

• Agreements age. An agreement describes the team as it was when it was written. New members, new locations or time zones, new tools and new kinds of work all create situations it never anticipated, and arguments over those gaps are a signal to revise it, ideally as a regular retrospective habit.
• Organisation-wide charters are input, not a substitute. A standard code of conduct can inform the team's agreement, but the team still writes, owns and maintains its own; a document it never discussed earns compliance at best.
• Rules that keep causing friction need a second look. If people clash because a rule cannot be kept, ask why, and let the team change the rule or the way it organises the work. Enforcing the rule harder leaves the cause in place.

Working agreements usually include a decision rule: how the team decides when views differ (for example, deciding once everyone can support a choice, or giving a named role the call during incidents). With a support-based rule, members do not have to agree that the choice is the best one; being fully heard and able to support it is enough. Once that point is reached, the practitioner confirms the decision and asks everyone to commit to it, rather than prolonging the debate or waiting for unanimity.

The practice that follows is often called disagree and commit; PMI's outline phrases it as committing to the team's decisions even in disagreement. Members argue their view fully while the team is deciding, then support the decision once it is made, and bring any genuinely new evidence back to the team through its normal process. The phrase comes from management practice, not from the Agile Manifesto, but it expresses the same respect for team decisions. Acting against a decision outside that process breaks the commitment. When it happens, the practitioner's first step is a private, respectful conversation with the person about their concerns and the agreement they share with the team.

Conflict on distributed teams escalates faster in text, because tone is easy to misread and the non-verbal cues that soften a disagreement are missing, so heated written exchanges should move to a private, real-time conversation, ideally by video. The medium is part of the problem: more written words, however well meant, tend to feed it, while a live conversation between the people involved lets them hear each other.

Two refinements matter:

• No overlapping hours is a scheduling problem, not a reason to stay in text. The people involved pause the written exchange and agree a time to talk, even if one of them starts early or finishes late that day. This matters more when others outside the team can see the channel. The resolution still belongs to the two people in the conflict.
• Prevent the pattern with a team agreement. If written arguments keep turning sharp, the team can add a trigger to its working agreement, such as moving a thread to a live call after a few tense replies. An agreement the team owns scales; relying on one person to police every thread does not.

Some conflict is outside the team's authority and must go through the proper channel: harassment and discrimination, breaches of mandatory organisational policy, and competing priorities set above the team. Facilitation and self-organisation apply to how the team works; they do not apply to people's safety or to rules the team does not own.

The order still matters. For priority conflicts, the first step is a collaborative conversation between the people who own the priorities; escalation is the fallback. For harassment there is no collaborative first step: it goes to the formal process, because asking the person affected to resolve it with the person harming them is itself unsafe. Escalating ordinary team disagreements to managers, by contrast, is a sign of reaching for authority too early.