Work World
21,802 views
25 min · 2 min read
7 steps
Advanced

How to run a post-mortem meeting that focuses on learning, not blame

A post-mortem meeting done well helps teams learn faster and reduce repeat problems. Focus on facts, outcomes, and actionable changes rather than assigning blame so people feel safe sharing real causes and ideas.

Verified by pleasexplain editors
  1. Step 1: Schedule promptly and limit time

    Hold the post-mortem within 48–72 hours after the incident while memories are fresh, and keep the session to 60–90 minutes. A focused, time-boxed meeting forces prioritization of the most important evidence and decisions.

    [Illustration: calendar with 48-72 hour note and a 60–90 minute clock]

  2. Step 2: Set a clear learning goal

    State one concrete question at the start, such as “How did recovery take 45 minutes and how do we reduce it to 20?” Defining the question keeps discussion actionable and prevents spinning into unrelated topics.

    [Illustration: whiteboard showing single bold question and an arrow to outcomes]

  3. Step 3: Establish psychological safety

    Begin with a neutral facilitator statement: no blame, only facts and improvements; violations of this rule pause the meeting. Explicitly invite junior people to speak first for 5–10 minutes each to balance power dynamics.

    [Illustration: circle of diverse team members with a speech bubble saying 'safe space']

  4. Step 4: Collect and share facts beforehand

    Ask participants to submit timelines, logs, screenshots, and notes 24 hours before the meeting; distribute a 1-page incident summary to attendees. Shared data reduces speculation and creates a common starting point for discussion.

    [Illustration: one-page incident summary document with attached logs and screenshots]

  5. Step 5: Use a structured timeline reconstruction

    Spend 15–25 minutes building a minute-by-minute timeline together, marking actions, alerts, and decisions. A structured reconstruction reveals causal links and separates observable events from interpretations.

    [Illustration: linear timeline with timestamps and colored event markers]

  6. Step 6: Identify contributing factors, not culprits

    For each major event on the timeline, ask “What conditions enabled this?” and list 3–5 systemic causes (process, tooling, staffing). Framing issues as conditions encourages systems fixes instead of blaming individuals.

    [Illustration: flowchart showing root causes feeding into an incident]

  7. Step 7: Agree on 3–5 concrete actions

    Create action items with an owner, due date within 7–21 days, and measurable success criteria (e.g., runbook updated, alert threshold changed, automation added). Review and publish progress in the next 2 weeks to close the loop.

    [Illustration: task board with cards labeled owner and due date]


  • Require a neutral facilitator for the first three post-mortems to model tone and structure.
  • Limit slides to a single incident summary page to keep focus on discussion over presentation.
  • Use anonymous feedback forms after the meeting to capture concerns people did not voice in person.
  • Keep a public, searchable post-mortem log with tags and links so future teams can reuse findings within 6 months.
  • Rotate note-taking responsibilities so institutional knowledge is shared across roles.
  • When possible, simulate the agreed fixes in a staging environment within 14 days to validate assumptions.

  • Avoid turning the meeting into a fault-finding session; calling out individuals can silence others and reduce learning.
  • Do not postpone the meeting beyond 7 days; memories fade and action momentum is lost.
  • Beware of too many action items; more than 7 open tasks dilutes focus and reduces completion rates.
  • Avoid vague action items without owners or deadlines—they rarely get done and erode trust.

Was this guide helpful?