Multi-Team Postmortem

Coordination.

Setup and attendees

Both team leads attend, plus the on-call engineers from each side. Senior enough to commit to action items without going back for approval.

Neutral facilitator. Often the platform team or a senior SRE. Reduces team-versus-team dynamics; keeps the conversation system-focused.

Pre-read circulated 24 hours before. Timeline, impact summary, contributing factors. The meeting is for analysis, not catching up.

Framing the conversation

Question is 'how did our two systems combine to cause this?', not 'whose fault was it?'. The facilitator enforces.

Each team takes responsibility for their own contributing factors. Other team listens; doesn't assign blame.

The interaction between systems is itself a contributing factor. Often neither team alone caused the incident; the integration did.

Walking the timeline

Single timeline with both teams' actions interleaved. Avoid two parallel narratives; the integration is what failed.

Decisions and observations from each side at each moment. What did Team A see; what did Team B see; were they aware of each other.

Common pattern: Team A took an action that was correct for them but unexpected by Team B. The discovery is the lesson.

Action items

Per-team action items: specific to one team's system or process. Owner, deadline, tracked.

Joint action items: changes that require both teams. Joint ownership with a designated lead. Most failure-prone item type; track religiously.

Process action items: how the two teams work together. Shared on-call channel, joint runbook, regular sync meeting. Often the highest-leverage.

Pitfalls

Async-only postmortems for cross-team incidents. Tone gets lost in writing; tensions escalate. Synchronous is required.

One-team-dominated meeting. Equal speaking time enforced by facilitator. Both teams' perspectives matter equally.

Vague action items ('improve communication'). Specific is the test of seriousness. Joint runbook by date X is specific; communication generally is not.