Conflict Coach

Input

• Conflict description: Two senior engineers disagree on whether to migrate the current monolithic Rails app to a microservices architecture. One engineer (Maya, backend lead) argues the monolith is becoming a deployment bottleneck and wants to begin extracting services now. The other (Priya, principal engineer) says the team lacks the operational maturity to run microservices and the migration will create more problems than it solves. Both have been vocal in Slack and in planning meetings, and the debate is now spilling into sprint planning and blocking roadmap decisions.
• People involved: Maya (backend lead), Priya (principal engineer), and the engineering manager (Tomás) who is trying to facilitate but feels out of his depth on the technical substance.
• Domain: Technical decisions
• Duration: Ongoing for approximately 6 weeks
• What's been tried: One informal 1:1 between Maya and Priya that ended without resolution; Tomás raised it briefly in a retrospective but it didn't get structured airtime.

Output

Conflict Coaching Plan

Conflict: Monolith vs. microservices migration at Tomás's engineering team Domain: Technical decisions Prepared for: Tomás (engineering manager)

Step 2: Resolution Level Recommendation

Recommended level: 2 — Facilitated session

Why: A direct conversation was already attempted and stalled. Both Maya and Priya are strong technical voices with legitimate positions, which means this isn't a knowledge gap — it's a values and risk tolerance disagreement. After six weeks, the conflict has calcified and is now contaminating sprint planning. Tomás needs to step in as a structured facilitator, not just a referee. A decision needs to emerge from this session; continuing to leave it unresolved is itself a choice with compounding costs.

Step 3: Coaching Plan — Technical Decision Conflict

Trade-off matrix

Use this to move the conversation from position-based ("we should do X") to criteria-based ("what do we optimize for?"). Have both Maya and Priya fill this in independently before the session, then compare.

Instructions: Ask each person to weight the criteria independently. Where weights diverge sharply, that's the real disagreement — surface it explicitly rather than debating the solution.

Should a spike help resolve this?

Yes — partially. The disagreement has both an opinion component (architecture philosophy) and a facts component (what the team can actually operate). A 2-week spike on one candidate service extraction would generate real data on operational overhead, CI/CD complexity, and team lift. This doesn't resolve the philosophical disagreement, but it removes one of the main unknowns Priya is pointing to. Recommend proposing this as an option during the session.

Voice and vote

This is a decision that affects the whole team but has two strong technical advocates. Suggested structure:

• Voice: Maya, Priya, and one or two other engineers who will live with the outcome should be heard in the session.
• Vote: Tomás makes the final call. He should say this explicitly upfront: "I'm going to hear both positions fully. I will make the decision by end of session. Both of you will be expected to commit to it." This removes the dynamic where both parties keep lobbying because no one has authority.

Decision record template

## Architecture Decision Record: Monolith Migration
**Date:**
**Decision:**
**Options considered:**
  - Option A: Continue monolith, address bottlenecks within it
  - Option B: Begin microservices extraction (phased)
  - Option C: Spike on one service extraction, revisit in 6 weeks
**Rationale:** (what criteria drove this)
**Trade-offs accepted:** (what we're knowingly giving up)
**Owner:**
**Review trigger:** (e.g., after next major deploy pain point, or in 90 days)

Step 4: Facilitation Script

# Conflict Resolution Session
**Topic:** Monolith vs. microservices migration decision
**Duration:** 60 min
**Goal:** By the end of this session, we will have selected one of three options
(continue, migrate, spike) and documented the rationale and owner.
**Participants:** Maya (backend lead), Priya (principal engineer), Tomás (EM, facilitating)

---

## Agenda

### 0. Warm-up (3 min)
**One-Word Check-In:** Each person shares one word for how they're arriving.
No explanation required. This creates an honest baseline and signals
that the session is different from the Slack debate.

### 1. Frame the conflict (5 min)
**Tomás says:**
"We've had a live debate for six weeks about our architecture direction.
Both Maya and Priya have made strong cases, and I haven't given this the
structure it deserves. Today I'm going to fix that. We're here to make
a decision together — not to relitigate the whole thing. I'll be listening
for interests, not just positions. At the end, I'll make the call and we'll
all commit to it. Sound fair?"

### 2. Hear perspectives (15 min)
**Format:** Each person speaks uninterrupted for 5-7 min.
**Prompt:** "Walk me through your concern — specifically what you're
worried goes wrong if we go the other direction."

**Facilitator notes to keep:**
- What outcome does each person actually want? (not just the architecture)
- Where do they agree on the problem?
- What are they each most afraid of?

### 3. Identify common ground (10 min)
**Tomás says:**
"Here's what I'm hearing you both agree on: the monolith has real
deployment friction, and neither of you wants the team spending weekends
on incidents eighteen months from now. The disagreement is about timing
and operational readiness — whether we build the plane while flying it,
or get ready first."

**Prompt to both:** "Does that capture it? What's missing?"

### 4. Review trade-off matrix + generate options (15 min)
Share pre-completed matrices. Surface where weights diverged.

**Tomás says:**
"I notice you both weighted deployment independence similarly,
but Priya weighted operational complexity nearly 3x higher than Maya did.
Let's talk about that gap — because that's the actual disagreement."

Options to evaluate:
- Stay in monolith, target specific bottlenecks (database read replicas,
  background job isolation)
- Begin phased microservices extraction with defined first service
- Run a 2-week spike on one service, decide with real data

### 5. Decide and document (10 min)
**Tomás makes the call and states it out loud.**

**Tomás says:**
"Here's my decision and why. [Decision.] I'm accepting [trade-off]
as a known risk. [Name] owns this. We'll revisit at [trigger]."

---

## Decision record
- **Decision:**
- **Rationale:**
- **Trade-offs accepted:**
- **Actions:**
  | Owner | Action | Due |
  |---|---|---|
  | | | |
- **Review trigger:**

Step 5: Self-Check for Tomás

Before the session, Tomás should run this check on himself:

"I raised this in retro but didn't give it structured airtime. Did I avoid the discomfort of facilitating a technical decision I don't fully understand — and let it fester instead?"

Key question for Tomás: Am I avoiding making the call because I'm uncertain about the technical substance? If yes, that's the real bottleneck. The engineers don't need him to be the best architect in the room. They need him to create a decision-forcing structure and own the outcome.

One thing to say before the session starts:

"I'm not the best person in the room on architecture. I am the person responsible for unblocking this team — and that's what I'm here to do today."

Related skills

• /decision-brief — if the outcome requires executive sign-off, use this to structure the summary for stakeholders above Tomás
• /difficult-conversation-prep — if Tomás needs to separately address how either Maya or Priya has been showing up in this debate (e.g., Slack behavior, shutting down other voices