Sample output
Made on 27 October 2026
Conflict Map
| Side | Stated positions | Likely underlying interests |
|---|---|---|
| Teammate A: stricter reviewer | “Reviews must catch design, testing, style, and maintainability issues before merge.” “Authors should address every comment.” “Standards should be consistent.” | Protecting reliability and long-term maintainability; avoiding technical debt and incidents; preserving team credibility; having concerns taken seriously; clarity about reviewer responsibility. |
| Teammate B: faster-flow advocate | “Reviews should focus on correctness, not personal preferences.” “Small issues should not block delivery.” “Authors should retain implementation ownership.” | Shipping predictably; preserving autonomy; avoiding rework and bottlenecks; reducing subjective or shifting expectations; feeling trusted and respected. |
Do not assume these motives are accurate. Test them with questions such as:
- “What risk are you trying to prevent?”
- “What does a good review protect?”
- “What happens when the current process goes badly?”
- “Which part feels most important to you: quality, speed, consistency, ownership, or something else?”
- “What would make the process feel fair?”
Personal layer to surface carefully
Both may also want:
- Recognition as competent engineers
- Respect for their judgment
- Freedom from public embarrassment
- Predictable expectations
- Assurance that disagreement will not affect reputation or advancement
- Confidence that standards apply equally to everyone
Likely Common Ground
- Both care about delivering good software.
- Both want defects caught before they harm users.
- Both want code that future teammates can understand.
- Neither wants reviews to become delivery bottlenecks.
- Both benefit from explicit standards rather than case-by-case power struggles.
- Both want technical disagreement separated from judgments about competence.
- Both likely prefer faster resolution when reviewer and author cannot agree.
- Both want the team—not