Post-mortem
A post-mortem is a structured analysis conducted after a significant event - typically an incident, project completion, or major release - to understand what happened, why it happened, and how to improve in the future. The term comes from medicine, where it describes examining a body to determine cause of death. In product and engineering, post-mortems examine events to extract learning, prevent recurrence of problems, and reinforce practices that worked well.
Why it matters
Organizations that don't learn from their experiences repeat their mistakes. Post-mortems create structured opportunities for that learning to happen. Without them, institutional knowledge remains in individuals' heads (and leaves when they do), patterns go unrecognized, and improvement becomes accidental rather than systematic.
Post-mortems are particularly valuable after incidents because the cost of repeated outages or failures is high. But they're equally useful after successful projects, where understanding what went right is as valuable as understanding what went wrong.
Types of post-mortems
Different events call for different types of review.
Incident post-mortems analyze service disruptions, outages, or other operational failures. These are the most common type in engineering organizations. The focus is on understanding the technical and process failures that allowed the incident to happen and preventing recurrence.
Project post-mortems review completed initiatives - whether successful or not. What went well? What didn't? What would we do differently? These are sometimes called retrospectives, though that term often refers to shorter, more frequent reviews within agile sprints.
Launch post-mortems specifically examine product or feature releases. Beyond technical performance, they assess whether the launch met its goals, how customers responded, and what the team learned.
Blameless post-mortems explicitly avoid assigning individual blame, focusing instead on systemic factors. This approach, popularized by companies like Google and Etsy, encourages honesty and reduces defensive behavior.
Conducting an effective post-mortem
Good post-mortems follow a structured process.
Gather data first. Before the meeting, collect relevant information: timelines, logs, metrics, communications, customer feedback. The post-mortem should analyze evidence, not reconstruct memories.
Establish the timeline. What happened, in what order? A clear chronology is the foundation for analysis. Often, creating the timeline reveals gaps in understanding or disagreements about what actually occurred.
Identify contributing factors. What conditions allowed this to happen? Avoid stopping at the first cause - dig deeper. The Five Whys technique (asking "why?" repeatedly) helps surface root causes rather than symptoms.
Distinguish root causes from triggers. The trigger is what set off the event; the root cause is the underlying condition that made the trigger dangerous. Fixing triggers prevents one specific recurrence; fixing root causes prevents entire categories of problems.
Generate action items. What specifically will change as a result of this analysis? Action items should be concrete, assigned to owners, and tracked to completion. Post-mortems without action items are venting sessions, not learning opportunities.
Document and share. The post-mortem document should be accessible to others who might benefit from the learning. Organizations that hide post-mortems lose the multiplier effect of shared knowledge.
The blameless approach
Blameless post-mortems focus on systems rather than individuals.
Assume good intentions. People involved were trying to do their jobs well. If someone made a mistake, ask what about the system made that mistake easy to make or hard to catch.
Focus on process, not people. Instead of "Who caused this?" ask "What allowed this to happen?" The first question produces defensiveness; the second produces insight.
Reward honesty. If people fear punishment for admitting mistakes, they'll hide information. Organizations get the candor they deserve based on how they treat people who speak up.
Separate learning from accountability. If there are performance or conduct issues, address them separately. Mixing accountability into the post-mortem corrupts the learning process.
This approach isn't about avoiding accountability - it's about recognizing that most failures result from system design, not individual malice or incompetence. Fix the system.
Post-mortem document structure
A typical post-mortem document includes:
Common post-mortem mistakes
Skipping them when things go well misses valuable learning. Understanding why success happened is as useful as understanding failure.
Rushing through them produces superficial analysis. Post-mortems require dedicated time and attention. Squeezing them into fifteen minutes between meetings yields fifteen-minute-quality learning.
Stopping at the first cause misses deeper issues. "The engineer pushed bad code" isn't a root cause - it raises questions about code review, testing, and deployment practices.
Generating too many action items dilutes focus. Three important actions completed are better than twenty actions forgotten. Prioritize ruthlessly.
Failing to follow through on action items makes post-mortems pointless exercises. Track actions to completion and report on progress.
Making them punitive shuts down honesty. If post-mortems become blame sessions, people stop participating authentically.
Post-mortems vs. retrospectives
The terms are related but distinct.
Retrospectives are typically regular, short reviews within agile sprints - reflecting on the past two weeks of work. They're lighter weight and more frequent.
Post-mortems are typically triggered by specific events and are more comprehensive. They happen when something significant occurs that warrants deep analysis.
Both serve learning, but at different cadences and depths. Teams often use both: retrospectives for continuous small improvements, post-mortems for deep dives into significant events.
Post-mortems and customer feedback
Incidents affect customers, and customer feedback provides crucial data for post-mortem analysis. Understanding how customers experienced an incident - not just what the metrics show - reveals impact that internal monitoring might miss.
Tools like Klero help capture and organize customer feedback related to incidents, ensuring that the customer perspective informs post-mortem analysis and action items.
