When two teams working through a project conflict seek a win/win solution, they should employ collaborating (problem-solving) as the primary strategy, using integrative negotiation to surface both teams' underlying interests rather than their stated positions. Collaborating is the only Thomas–Kilmann mode that aims to fully satisfy both parties, and it fits conflicts where stakes are high, interdependence is real, and time allows joint diagnosis.
Collaboration is not a mood; it is a procedure. It works when both teams separate people from the problem, generate options before judging them, and agree on objective criteria for choosing among them. This explainer covers the mechanism, the conditions that make it succeed, the edge cases where it fails, and the concrete steps that turn the intention into an agreement.
The mechanism: interests, not positions
A position is what a team says it wants. An interest is why it wants that. Two teams may both demand ownership of the same release calendar, but one team's interest may be predictability while the other's is visibility. Collaboration works by trading across those underlying interests rather than splitting the stated demand.
The Thomas–Kilmann framework defines five conflict modes along two axes: assertiveness (how much you pursue your own concerns) and cooperativeness (how much you pursue the other party's). Collaborating scores high on both. Compromise scores medium on both and splits the difference. Accommodating is low assertiveness, competing is low cooperativeness, and avoiding is low on both.
The mechanism is escalation of information, not escalation of demands. Each team discloses constraints the other did not know: freeze dates, shared dependencies, staffing limits, compliance gates. Disclosure expands the set of feasible agreements. A deal that looked like a fixed pie becomes a variable pie once the constraint behind each demand is visible.
The plain version: collaboration works by finding out what each team actually needs, then building an option that meets both needs instead of dividing one demand. If the teams cannot or will not share constraints, the strategy has nothing to process and will stall.
Quantified context: when collaboration pays
Roughly 30 years of negotiation research suggests joint problem-solving produces more joint gain than distributive bargaining when integrative potential exists. The effect is conditional, not universal. The classic caveat, from the negotiation literature rather than any single trial, is that collaboration costs more time and requires trust that may not be present.
In software and project settings, a working heuristic is to reserve collaboration for conflicts touching shared architectural decisions, release calendars, or cross-team dependencies, meaning conflicts where a decision for one team directly constrains the other. For trivial conflicts, collaborating is expensive overhead; the mode fit matters more than mode preference.
A practical threshold: if resolving the conflict would take more than one meeting but less than a week, collaboration is usually proportionate. If it would take more than a week of facilitated work, the conflict may need escalation or structural resolution first. That threshold is a practitioner heuristic, not a published constant, and should be treated as guidance rather than evidence.
Reconcile the thresholds explicitly. Use collaboration when stakes are high, both teams hold real information, and a joint solution is feasible. Use compromise when stakes are moderate and speed matters. Use competing only when a safety or compliance call overrides consensus. These rules overlap at the boundary, so decide by asking which failure is cheaper: a slow agreement or a wrong one.
Edge cases where collaboration fails
Collaboration fails when one party is playing a distributive game. If a team uses disclosed constraints as leverage, the disclosing team learns to withhold, and the integrative process collapses after the first cycle. The warning sign is a constraint that gets weaponized in the next negotiation.
Collaboration also fails when authority is ambiguous. If neither team can commit resources, the joint solution is a proposal, not an agreement. Many "collaborations" on project conflicts dissolve because the people negotiating lack decision rights.
A counterintuitive detail: teams that like each other often collaborate worse than teams that respect each other's competence. Liking increases the desire to preserve the relationship, which can suppress the candid constraint disclosure collaboration depends on. The professional caveat is that collaborative language can mask avoidance. A meeting that never names the disagreement is not collaboration; it is conflict suppression wearing a collaborative label.
Red flag: one team's "constraint" is really a fixed position in disguise. Red flag: the facilitator has a stake in one outcome. Red flag: no one at the table can commit resources. Red flag: disagreement is never named explicitly. Red flag: collaboration is used to delay a decision that must be made.
Comparing the five strategies
| Strategy | Assertiveness | Cooperativeness | Best fit for project conflict | Main failure mode |
|---|---|---|---|---|
| Collaborating | High | High | High stakes, shared dependencies, real integrative potential | Slow; collapses if trust or authority is missing |
| Compromising | Medium | Medium | Moderate stakes, time pressure, acceptable split | Leaves joint gain on the table |
| Accommodating | Low | High | Issue matters more to the other team; preserve relationship | Resentment; hides the real problem |
| Competing | High | Low | Safety, compliance, one clear expert | Loses information; damages future collaboration |
| Avoiding | Low | High (de facto) | Trivial issue or a needed cooldown | Unresolved conflict returns larger |
The table is descriptive, not prescriptive. Teams often default to one mode regardless of fit. The professional move is mode agility: choose consciously, name the choice, and revisit it if conditions change.
Timeline of a collaborative resolution
| Stage | Typical duration | What happens | Failure point |
|---|---|---|---|
| Pre-brief | 1 day | Each team writes its position and the interest behind it | Interests never written down |
| Joint framing | 1–2 hours | Teams agree on the problem statement | Framing favors one side |
| Option generation | 1–2 sessions | Ideas generated without evaluation | Judgment creeps in too early |
| Criteria selection | 1 session | Objective standards agreed before choosing | Criteria gamed for a preferred option |
| Agreement | 1 session | Commitments, owners, dates recorded | Commitments stay verbal |
| Follow-up | Weeks | Agreement reviewed against reality | No review, so drift goes uncorrected |
The durations are typical ranges, not measured medians. Treat them as planning estimates. The stages that matter most are joint framing and criteria selection, because errors there contaminate everything downstream. Plain version: get the problem statement and the rules for choosing right, or the rest is theatre.
Practical actions with thresholds
Prepare each team separately before the joint session. Ask each team lead to write three things: their stated position, the interest behind it, and one constraint they are willing to disclose. Do not proceed until each team has produced at least one tradeable constraint. Threshold: if fewer than two tradeable constraints exist across both teams, collaboration is unlikely to produce joint gain, and compromise is the better fit.
Frame the joint session around the problem, not the personalities. State the conflict in one sentence that both teams can accept as accurate. If a shared sentence cannot be produced in 30 minutes, the conflict is not ready for collaboration; run a separate framing session first.
Generate options before evaluating them. Require at least five candidate options before anyone scores one. Threshold: stop option generation when two consecutive options are minor variations on an earlier one, then move to criteria.
Agree on criteria before applying them. Use measurable standards where possible: release date, defect rate, integration cost. Record every commitment with an owner and a date. Review the agreement at a fixed interval, typically two weeks, against actual outcomes.
Escalate only on defined triggers: a violated commitment, a withheld constraint discovered later, or a deadlock that survives a full cycle. Escalation is not failure; it is the correct mode when collaboration has been tried and the conditions were absent.
Limitations and what collaboration cannot fix
Collaboration cannot create integrative potential that does not exist. If the project genuinely has one slot and two teams, the outcome is distributive, and pretending otherwise wastes time. The honest move is to name the fixed pie and negotiate the split with objective criteria.
Collaboration cannot substitute for authority. If the conflict requires a decision neither team can make, the correct path is a named decision-maker, not another joint session. Treating an authority gap as a collaboration problem is one of the most common and most costly project-conflict errors.
The evidence base is also uneven. Much of the collaboration literature comes from negotiation experiments and observational field work rather than controlled project settings. The mode-fit logic is well established; specific effect sizes for project outcomes are not. Claims should be held with appropriate confidence.
This article is general educational information about conflict strategy, not a diagnosis, treatment plan, or professional recommendation for any specific organization. Do not promise or expect guaranteed outcomes from any strategy. For high-stakes organizational, legal, or contractual disputes, consult a qualified professional in your jurisdiction.