liveBook · Manning

Conflict

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

A conflict is a state of disagreement or opposition between people or positions within a group.

Conflict is a natural difference of opinion between two or more people. In collaborative modeling, disagreements can concern bounded contexts, pivotal events, proposed solutions, hierarchy, or pace. Rather than treating conflict as inherently bad, use it as a signal that important perspectives or hindrances may need attention. section 8.2 section 8.7

Conflict is not a diagnosis for every uncomfortable behavior. Observe what people actually say and do, without assumptions or interpretations, and look for an objectively observable pattern before treating behavior as a possible sign of conflict or resistance. Neutrality matters because a facilitator’s own reactions can reshape group dynamics. section 8.2.1 section 8.3

Use conflict to improve the group’s work:

  • Make opposing perspectives explicit so the group can build mutual understanding and counter functional fixedness. section 8.2.3
  • Distinguish functional task conflict from dysfunctional relationship conflict by asking whether it is task- or emotion-related and whether it helps or hinders progress. section 8.5
  • Reframe a disagreement as dialogue or debate when discussion shifts toward who is right or wrong, keeping attention on ideas rather than personal conflict. section 8.5
  • Address concerns with the whole group, invite differing views, and avoid unsolicited advice or singling out lower-ranked people. section 8.5

Detecting edge behavior

In a design discussion, a developer repeatedly interrupts a colleague, redirects proposals toward his own ideas, then nods along without contributing. Treat these as observable behaviors rather than proof of motive. The pattern may indicate avoided conflict or resistance, and calls for careful, neutral facilitation rather than judgment. section 8.2.1 section 8.7

When conflict stays hidden, the group can lose relevant input, repeat the same conversations, and delay sustainable decisions. A facilitator can surface patterns through neutral feedback, help people feel heard, and let the group participate in resolving its own conflict. section 8.4 section 1.3.3

Figure 1.7 Lurking in the group’s shadows, called the unconsciousness of the group, are a lot of social dynamics, such as ranking, cognitive bias, conflicts, and polarities, that can block the flow of a session and stop the group from moving forward and making sustainable design decisions.

View conflict alongside ranking, cognitive bias, and polarities as a social dynamic that can block session flow and sustainable design decisions when left unaddressed. section 1.3.3

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes
Explains observable patterns, learning opportunities, conflict types, and facilitation heuristics without reducing behavior to fixed motives.
Examples
Uses BigScreen design discussions, edge behavior, gossiping, and EventStorming facilitation scenarios.
What it assumes
Assumes participation in collaborative modeling while teaching conflict recognition through observable behavior and patterns.
What you can do after
Practice neutral observation, classify conflict, invite perspectives, and de-escalate conversations without taking over resolution.
How it connects
Connects conflict with resistance, ranking, cognitive bias, functional fixedness, sensemaking, and collaborative modeling.

Also explained in

Compare how 4 books explain conflict →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.