Post-Mortems vs After Action Reviews: What Changes
TL;DR
A post-mortem is triggered by failure and set up to diagnose what went wrong.
An after action review is triggered by any significant event, including the ones that went well, and set up to turn the experience into a change.
An organization that runs only post-mortems learns systematically from its worst moments and almost nothing from its best ones.
What post-mortems do well
Post-mortems are one of the most common ways to review an outcome, particularly in technology and engineering teams. They give a team a structured opportunity to examine a failure or an incident properly.
When run well, they identify root causes, document what happened, and produce recommendations for preventing a recurrence. The blameless post-mortem approach many engineering teams use creates a safe environment for honest diagnosis, which is the hardest part of reviewing a failure and the part most organizations get wrong.
There is nothing wrong with the practice. The question is what it covers.
Where the gap appears
Post-mortems are triggered by failure. Successes, near misses, and ordinary projects that went fine do not usually get the same structured attention.
That means the organization learns systematically from its worst moments only. The practices that contributed to something going well, the communication patterns, the decisions that turned out right, the handoff that worked, are never captured, because nobody reviews what worked.
There is a second effect. Because post-mortems happen when something breaks, they stay ad hoc rather than becoming part of a predictable rhythm. The organization learns when failure forces it to, rather than choosing to learn from every significant experience.
What an after action review adds
An after action review is triggered by defined events rather than by failure: a completed project, a client engagement, a missed goal, a major decision, the close of a planning cycle.
It is governed by four standards agreed in advance. When reviews happen. Who participates. How people show up, meaning curiosity rather than defensiveness, facts rather than opinions, behaviour rather than intent, improvement rather than justification. And how learning turns into action, which means every review ends with a small number of changes that have named owners and are recorded where other teams can find them.
Those standards work the same way for a success as for a failure, which is what lets the practice cover both.
Because the trigger is an event rather than a breakdown, the review becomes a regular discipline. The organization learns from everything it does, and small improvements accumulate over time in a way they cannot when learning only follows failure.
Does the after action review replace the post-mortem?
For most teams, yes, and not because there is anything wrong with a post-mortem.
The after action review covers what a post-mortem covers and extends the same structure to successes and ordinary work. Teams that adopt it generally find the separate post-mortem practice stops earning its place, because the reviews they were already running are now a subset of the reviews they run anyway.
If your engineering team has a blameless post-mortem practice that works, there is no reason to dismantle it. The useful move is to extend the trigger, so that the same quality of attention reaches the projects that went well.
The distinction that actually matters
Both practices can produce a thoughtful conversation. The difference is what the conversation has to end in.
An after action review ends in at least one change specific enough that you would see someone making it, with an owner and a date, written down and sent to the teams it affects. "Communicate better" does not qualify. "Escalate a timeline risk within twenty-four hours" does.
That rule is what separates a review that changes something from a review that was interesting. The full method is here, including the ninety-minute agenda and the roles.
Common questions
Are after action reviews just post-mortems with a different name?
No. Post-mortems are triggered by failure and focus on diagnosing what went wrong. After action reviews are triggered by any significant event, including successes, and focus on turning the experience into a change. The trigger, the scope and the standards are all different.
Should we stop running post-mortems if we adopt after action reviews?
Most teams find they no longer need a separate practice, because the after action review covers the same ground and more. If you have a post-mortem practice that works well, extend its trigger rather than replacing it.
How do after action reviews avoid becoming blame sessions?
The standards are agreed in advance: curiosity rather than defensiveness, facts rather than opinions, behaviour rather than intent, improvement rather than justification. A facilitator protects the structure and interrupts blame when it starts. The focus stays on what happened and what will change.
What counts as a significant event?
A completed project or initiative, the end of a client engagement, a missed goal or significant delay, a major decision that affected several teams, and the close of a planning cycle. The organization names its own triggers in advance, so the review becomes automatic rather than optional.
Does this work for something that went well?
That is most of the point. A project that succeeded contains the practices worth repeating, and those are invisible to a practice that only runs when something breaks.
Get the template
We have put the whole method into a free template: the timed ninety-minute agenda, the roles, a one-page worksheet, weak-versus-strong examples for writing a change you would actually see, and the steps for documenting and sharing the lesson.