Conflict Management

Most conflict on a project isn't personal, even when it feels that way. Two groups read the same data and answer different questions with it. Business and engineering each hold half of a risk and argue as though they hold all of it. Someone with more authority uses it in place of a decision. One team changes something another team was quietly depending on. Treated as personality clashes, these conflicts come back every sprint, because the structure that produced them is still there.

This practice starts by finding the structural cause, then picks a resolution strategy on purpose, handles the common project conflicts in a repeatable way, and escalates with evidence rather than feeling. The personal side of conflict still matters, and the strategies cover it. The structural causes just come first, because they're the ones that recur.

When to use this

• Use it when a disagreement about scope, release or risk has stopped being about the facts.
• Use it when two dashboards or two groups give conflicting answers to what sounds like the same question.
• Use it when a change by one team breaks something another team relied on.
• Use it when internal staff and external consultants have stalled over a design.
• Use it before escalating, and again when deciding how to escalate.
• Interpersonal conflict that involves conduct, discrimination or safety is an HR matter, not a project one. Escalate it through that route immediately.

Principles

Look for the structural cause before the personal one. Unclear ownership, different time horizons and undeclared dependencies produce most project conflict. Fix those and many personal conflicts stop.

Both sides can be right. QA saying a fix failed and analytics saying the trend improved can both be true, because they cover different horizons. Find out which question each side is answering before deciding who's wrong.

Separate who decides from what's decided. Agree on the owner of the decision first. Disagreements about content go faster once nobody is also fighting over the right to decide.

Say exactly what yes means. When someone with more authority pushes for a risky path, don't refuse it. Describe the consequences of saying yes and ask who's accepting them. That moves the conflict from a test of wills to a named decision.

Choose the strategy on purpose. Collaborating, accommodating, competing, compromising and avoiding each fit some situations. The failure is falling into the same one every time.

Escalate with evidence and leave a record. An escalation that arrives as a phone call and a feeling resolves nothing; it moves the conflict up a level. Write down the options, the evidence and the decision.

The practice

Diagnose the conflict

1. Write down what each side wants and why, in their own words. Check the summary with each side.
2. Classify the conflict using the table in Decision aids: ownership, horizon, dependency, resources or interpersonal.
3. If it's structural, fix the structure first. Name the owner, agree the question each number answers, or make the dependency visible. Then see what disagreement is left.

Choose a strategy

Pick from the five strategies in Decision aids. By default, I collaborate on anything that will come up again and compromise on one-off resource trade-offs. I compete only when there's an emergency or a non-negotiable control at stake, and I say so out loud when I do. Avoiding is a legitimate choice for trivial issues and for conflicts that need time to cool, but give it a date. Avoiding with no end becomes the outcome by default.

Settle a risk conflict between business and engineering

1. Put both sets of facts in front of everyone: what engineering knows about testing and stability, and what the business knows about commitments and costs.
2. Split the ownership. The business owns the business risk decision; engineering owns the accuracy of the technical risk assessment.
3. Lay out the feasible options with their risks and timelines, and give a recommendation.
4. If the decision goes against engineering's advice, record the risk acceptance with a name on it, then carry the decision out professionally.

The release-specific version of this, with the paths to production, is in Sprint & Release Management.

Settle a conflict between two sets of numbers

1. Before arguing about which number is right, ask which question each one answers and over what time horizon.
2. Agree on a definition for the measure that matters to the decision. Many dashboard conflicts are really two definitions of the same word.
3. Route the question to the owner whose evidence can answer it, as described in Product Management.

Prevent dependency conflicts

1. Before a feature ships, ask which other teams read the fields, events or interfaces it changes. Agree which of them are durable and which can change without notice.
2. Keep a decision log that both sides can read. Most "we never agreed to that" arguments are memory conflicts.
3. When internal and external people share a design, hold joint design reviews and give the internal team a defined way to challenge external recommendations before they become commitments.

Escalate well

1. Escalate when the people involved have tried to resolve it directly and failed, when nobody can say who owns the decision, or when the risk is beyond the authority of anyone in the room.
2. Write the escalation down: the decision needed, the options, the evidence for each, the recommendation and the date it's needed by.
3. Send it to the person who owns the decision, not to whoever is most likely to agree. I'd rather wait a day for the right owner than get a fast answer from someone who can't make it stick.
4. Pass on the decision, not just the pressure that came with it. A conflict escalated upward and then passed back down unchanged has only moved.

Follow up

Check that the resolution held, a week or a sprint later. If the same conflict returns, the cause was structural and the resolution only treated a symptom. Raise it in the retrospective as a change to ownership, definitions or dependencies.

Decision aids

Types of project conflict

The five strategies

Saying what yes means

"We can do it. Here's exactly what that means: QA's window drops from two days to one across every feature in the release, and if they find a problem, we're looking at a delayed release or a rollback at 2 AM. Are you comfortable signing off on that risk for this change? The alternative is shipping it Wednesday in its own release with full testing."

Who owns what

Signs it's going wrong

• The same argument comes back every sprint. The resolution treated a symptom, and the structure is unchanged.
• Meetings turn into audits of whose dashboard is right, and no decision gets made.
• Escalations happen by phone and leave no record, so the decision gets argued again.
• People say "we decided as a team" and nobody can say who decided.
• One group always accommodates. QA absorbing late changes is the usual example, and it stops raising concerns.
• Avoiding has become the default, and conflicts resolve themselves when a deadline forces a choice.
• Internal staff and consultants communicate through their managers instead of directly.

Related terms

Accountability, Authority, Decision Rights, Escalation, Risk Acceptance, Analytic Contract, Business Owner, Product Owner, Delivery Lead, PMO, Portfolio, Sponsor, Outcome

Where this came from

• Accountability and Authority: Walking the Tightrope: saying exactly what yes means, and taking the pressure instead of passing it down.
• Tactical Excellence, Strategic Truth: Who Checks Whom: both sides can be right when they answer different questions.
• Stop Digging Through Logs. Start Designing for Learning.: dependency conflicts between teams reading the same data.
• A Journeyman's Guide to Three-Week Sprints: splitting business risk from technical risk.
• The Balanced Equation: Crafting the Perfect Project Team Mix: conflict between internal staff and external consultants.