Postmortem Multi-Team Contributing Factors Untangler Prompt
Untangle the contributing factors in an incident that crossed service and team boundaries — attributing factors to systems, not people, and mapping the seams where handoffs and ownership gaps let it propagate.
- Target user
- Incident commander / SRE leading a cross-team post-incident review
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a staff SRE who facilitates post-incident reviews that span multiple services and teams. You know the political trap: each team wants the cause to live in someone else's system. Your job is to map the contributing factors across boundaries fairly, with the focus on seams and systems rather than which team to blame. I will paste: [INCIDENT TIMELINE: how the failure originated and propagated across services] [SERVICES / TEAMS INVOLVED: the systems in the path and who owns each] [HANDOFF POINTS: API contracts, queues, on-call boundaries, and escalation paths between them] Do the following: 1. Map propagation: trace how the failure moved from service to service, marking where it was amplified, masked, or could have been contained. 2. Attribute contributing factors to systems and seams, not teams: for each factor, name the technical or process condition (a missing backpressure, an unvalidated contract, an ambiguous ownership boundary). Use roles, never individuals. 3. Highlight the seams: identify the inter-team handoffs where assumptions diverged — what Team A assumed about Team B's behavior that did not hold. 4. Find ownership gaps: surface any failure mode that fell between teams with no clear owner, and any conflicting assumptions about who was responsible. 5. Balance attribution: explicitly check that you are not over-weighting whichever team's logs are most detailed. Note where data is missing from a team's side and mark it [UNVERIFIED]. Output format: a propagation diagram described in steps, then a contributing-factors table (Factor / System or seam / Defense it would add / Owning role), and a short list of the cross-team seams that need a clear owner. Guardrails: stay strictly blameless and balanced — frame everything as systems and boundaries, never as a team's failing. Mark any cross-team claim you cannot verify from the pasted data as [UNVERIFIED]. The participating teams own validation of their own systems; I own the final document.
Why this prompt works
Multi-team incidents are the hardest postmortems to run honestly. A failure that crosses service boundaries arrives at the review with each team already holding a story in which the root cause lives somewhere else. Left unmanaged, the review becomes a negotiation over whose logs win, and the actual lesson — the seam where assumptions diverged — never gets written down.
This prompt keeps the analysis on systems and boundaries by design. It traces propagation across services, then attributes every contributing factor to a technical or process condition rather than a team, and it specifically hunts for the two things cross-team incidents are made of: handoff points where one service assumed something untrue about another, and ownership gaps where a failure mode belonged to no one. Those seams are usually the real fix, and they are exactly what single-team framing hides.
The balance check is what makes it fair. The team with the most detailed telemetry tends to look most culpable simply because more of its behavior is visible, so the prompt forces an explicit note where a team’s data is missing and marks those claims unverified. Attribution stays at the level of roles and systems, validation of each system stays with its owning team, and the final document stays with the human facilitator.