This article is an expansion of the “alignment” thread in Management Retrospective.

“They won’t cooperate” is an easy thing to say and a nearly impossible thing to act on in moving a project forward. Every time I hear it, I instinctively get wary — it shrinks a complex working relationship into a judgment of character. Whatever follows — more meetings, pushing for progress, or escalating the conflict — is likely only to make both sides more defensive.

When a project conflict arises, I try to return first to three more concrete things. These three things can usually cover the real source of the conflict.

1. What Are We Trying to Change Together

In the same project, one person treats “shipping on schedule” as the goal, another treats “avoiding incidents” as the goal, and a third treats “leaving behind extensible interfaces” as the goal. They are not necessarily in contradiction, but without a clear order of priority, every trade-off can feel like dismissing someone else.

For example: a marketing campaign launches tomorrow, the design team wants another round of page changes, and the engineering team worries that unverified interactions will add risk. At this point, don’t argue over “who is more expert”; first make clear: this time, what matters most — being on time, conversion, or stability? If only two of these can be protected, which one can give way?

This question sounds simple, but most conflicts get stuck precisely because no one asks it at this step.

2. Which Facts Do We Actually Have

Conflicts are often caused by different versions of reality. One person says “the change is tiny,” another says “it touches many modules”; one says “users are in a great hurry,” another says “there is no evidence.”

List the facts separately: which systems are involved, how much time remains, what has been verified, what is still an assumption, and whether a failure can be rolled back. Facts do not necessarily resolve the disagreement immediately, but they can shift the discussion from positions to judgment — replacing “who is right” with “what each of us is basing our claims on.”

3. Who Makes the Final Decision, and Under What Conditions

Collaboration sometimes fails not because there are no opinions, but because everyone assumes someone else will make the call. It needs to be stated in advance: who is responsible for consolidating the options, who bears which kinds of risk, when to escalate, and what new information would trigger a fresh decision.

This is not about building a power game, but about preventing problems from being resolved at the last minute by whoever is loudest. What I fear most is not disagreement, but disagreement left hanging until the day before the deadline, when someone settles it on a whim.

Three Kinds of Conflict, Three Kinds of Handling

Sorting conflicts into categories makes them easier to handle:

  • Goal conflict: occurs when “shipping fast” and “doing it completely” are both treated as the top priority at once. The way to handle it is to rank priorities and define delivery boundaries.
  • Dependency conflict: occurs when both sides treat the other’s input as a precondition. The way to handle it is to make clear who goes first, who goes second, and when the interface is finalized.
  • Fact conflict: comes from different measurement standards or different versions of the plan. The way to handle it is to calibrate the facts first — without shared facts, arguments over the plan only turn into collisions of position.

For issues where real disagreement exists, keep a decision record: goal, options, benefits and risks, current decision, and review conditions. For example, if you temporarily drop support for a rare input format in order to release on schedule, you should also record who is affected, the temporary workaround, and the signal that triggers closing the gap. That way “doing less first” is not a permanent debt.

“Setting aside the dispute” does not mean burying the problem. It should mean: for now, move forward on the shared goal, while leaving a record of the disagreement, the way to verify it, and the time to revisit it. Handled this way, conflict need not damage relationships; it can instead help the team gain clearer boundaries for working together.

The review matters more than who wins on the spot. Agree on what results to look at a week later, who escalates when a dependency slips, and how to look back over the process after a risk materializes. When people trust that the facts will be re-examined, conflicts no longer need to be resolved by rank, volume, or favors.