Facilitate a Blame-Free Root Cause Analysis
Facilitates a 5 Whys root cause analysis in a blame-free format focused on system and process, not individuals. Built for teams processing an incident or missed commitment.
When to use this prompt
Use this when something went wrong (an incident, a missed commitment, a broken rollout) and the team needs to understand why without blaming individuals. You will need the incident or miss context and a group of people willing to look at systems rather than people. The prompt enforces blame-free language and structures the conversation around 5 Whys plus a fishbone step. It is particularly useful in engineering cultures with a strong blame reflex; the structure gives the facilitator explicit language to redirect blame toward system questions. Do not use it for emotionally charged situations without a skilled human facilitator; the prompt is a guide, not a therapist.
The Prompt
You are a Scrum Master facilitating a blame-free root cause analysis after an incident or missed commitment. Use 5 Whys followed by a fishbone approach, and enforce blame-free language throughout. Incident or miss: {{incident}} What went wrong: {{what_went_wrong}} Impact: {{impact}} Participants: {{participants}} Time available: {{time}} Produce the facilitation script in this structure: 1. OPENING (5 min) - State the purpose: understand the systems and processes that allowed this to happen, so we can prevent recurrence. - Ground rules: no names, no blame, no "should have." We are looking for how our system made this likely. - Acknowledge the impact without apology: "This hurt the team. We are here to learn." 2. DESCRIBE WHAT HAPPENED (10 min) - Build a shared timeline of events, pulled from facts only (logs, messages, commits). - Facilitator prompt: "Let's get the sequence of events without interpretation yet." - Rule: if anyone uses a name or "X did Y," redirect: "Let's focus on what the system allowed." 3. 5 WHYS (15 min) - Start with the outcome and ask why 5 times. - Each answer must point to a system, process, or context, not a person. - Example reframe: "Engineer missed the bug" becomes "The test coverage did not include this edge case." 4. FISHBONE ANALYSIS (15 min) - Organize contributing causes into 4 categories: PROCESS: What process step was missing or weak? TOOLING: What tool or automation failed to catch the issue? INFORMATION: What context or data was missing or unclear? TIMING: What pressures or dependencies made this harder? - Under each category, list 2-3 causes surfaced in the discussion. 5. SYSTEMIC FIXES (10 min) - For each fishbone category, propose 1 systemic fix. Fix must change the system, not require individuals to try harder. - Examples: add a test, change a review rule, update a runbook, adjust a deadline policy. - Explicitly reject fixes that depend on individual vigilance ("be more careful" is not a fix). 6. CLOSE (5 min) - Name the 2-3 most important systemic fixes with owners and deadlines. - Check in with the team on psychological safety: "Did this feel blame-free?" Facilitator cheat sheet: - When someone says "I should have...," redirect: "What in the system made that easy to miss?" - When someone names another person, redirect: "What was the context that made that the most likely choice?" - When a fix is "be more careful," reject: "That is a person solution, not a system solution. What would we change so care is not required?"
Example Output
INCIDENT: Invoice export released with timezone bug, affected 80 customers, required rollback. OPENING: We are here to understand what in our system allowed this to ship. No names, no blame. Our goal is prevention. TIMELINE: PRD approved April 1. Dev started April 5. PR merged April 18 after 2 approvals. Deployed to beta April 20. Bug reported April 22. Rollback April 22. 5 WHYS - Why did the bug reach customers? Because beta testing missed it. - Why did beta testing miss it? Because our beta cohort is all in UTC. - Why is beta all in UTC? Because we pick beta customers by revenue and our UTC customers are overweighted. - Why does the beta selection process not consider timezone? Because timezone is not a criterion in our beta selection policy. - Why is timezone not a criterion? Because our beta selection was written before timezone-sensitive features existed. ROOT CAUSE: Our beta selection policy has not evolved to cover timezone-sensitive features. FISHBONE - PROCESS: Beta selection policy missing timezone criterion; test plan did not require multi-timezone verification. - TOOLING: No automated test for timezone handling; staging DB seeded only with UTC customers. - INFORMATION: Engineer was not aware that timezone handling was a known risk area. - TIMING: Deadline pressure to ship by quarter end. SYSTEMIC FIXES 1. PROCESS: Update beta selection policy to require at least one customer from each of 3 timezones. Owner: PM. 2. TOOLING: Add timezone test to CI for all date-handling code. Owner: Tech Lead. 3. INFORMATION: Add timezone section to engineering onboarding doc. Owner: EM. 4. TIMING: Add 'timezone-sensitive' flag to PRD template that triggers mandatory beta checks. CLOSE: 3 owners, 2-week deadline on each fix. Safety check: "Did this feel blame-free?" â team confirms yes.
Recommended Tools
Notion projects is the best place to host the post-mortem document because it supports timeline, fishbone diagram, and systemic fix owners in one place. Linear is where the systemic fix action items should live as tracked tasks. Google Workspace (Docs) is the alternative for teams that prefer document-based post-mortems. Use Notion for the analysis document and Linear for the follow-up tracking.
Frequently Asked Questions
When should I use this prompt?
Use it after any significant incident, missed commitment, or broken launch where the team needs to understand what happened without blaming individuals. It is especially valuable in engineering cultures with a strong blame reflex because the prompt provides explicit language to redirect blame. Do not use it for interpersonal conflicts; those need a different kind of facilitation. Also do not use it for trivial mistakes where a quick fix is more appropriate than a full RCA; reserve the formal process for incidents where learning is genuinely required to prevent recurrence.
How do I enforce blame-free language?
The cheat sheet in the prompt gives you three specific redirects to use when someone drifts into blame. Practice them before the meeting so they come naturally. The most important redirect is replacing 'X should have' with 'what in the system made that easy to miss?' The shift from person to system is where the real learning happens. Also watch for subtler blame: phrases like 'the engineer who wrote this' are still blame, just more polite. Redirect every naming to a system question. Over time, the team will internalize the pattern and self-correct.