Learning Reviews vs Postmortems: When Each Earns Its Keep
A postmortem documents an incident. A learning review extracts a lesson worth telling other teams. They are not the same artifact and treating them interchangeably wastes both.
Two different artifacts
A postmortem is a record of one incident. A learning review is a synthesis across one or more incidents that extracts something the rest of the org can learn from. Most teams smush them together; the result is a postmortem too long for the team and too narrow for everyone else.
The audience asymmetry. The team owning the service needs the postmortem (specific, technical, actionable). The rest of the org needs the learning review (generalised, conceptual, transferable). One document trying to serve both fails at both — too much detail for the org, too little context for the team.
The cost of merging. A 12-page postmortem with embedded "lessons for the broader org" gets read by the team and ignored by the org. The lessons are real; they're just buried in detail nobody else cares about. Separating them produces a 4-page postmortem that the team uses and a 1-page learning review that the org reads.
What a postmortem does
Documents what happened, in enough detail that the on-call team can answer the customer's questions and reconstruct the incident in six months. Specific. Action items attached. Audience: the team and adjacent on-callers.
The postmortem's specific use cases. Customer questions ("what exactly happened on April 15?"). Engineering follow-up ("did we ship the action items?"). Onboarding ("here's an example of how our team handles incidents"). All require detail; all require team-level context.
What goes in the postmortem. Timeline (minute-by-minute). Impact details (specific customers, specific durations). Technical analysis (the actual code/config/system change). Action items (with owners and dates). The postmortem is comprehensive at the team's scale.
What a learning review does
Extracts a lesson generalised beyond the one incident. The audience is wider: other teams, leadership, the organisation as a pattern library. Light on play-by-play; heavy on "what we now believe is true that we did not believe a month ago."
The learning review's distinct contribution. Patterns that span multiple incidents. Updates to the team's mental models. Transferable insights that other teams can apply without needing the original incident's context. The review's job is to be USEFUL TO PEOPLE WHO WEREN'T THERE.
The format. Short (1-2 pages). Three sections: what we used to believe, what we now believe, where else this applies. Light on technical detail; heavy on principles. Linked to the underlying postmortem(s) for those who want details.
When to do which
Every significant incident gets a postmortem. A subset of those incidents (typically 1 in 5) earn a separate learning review when the lesson generalises beyond the team. Do not force every postmortem into a learning review; the false-positive rate is high.
The 1-in-5 ratio is approximate but useful. Most incidents are team-specific (a bug, a config error, an integration). Some incidents reveal something broader (a class of failures, an industry-wide assumption that's wrong, a process that needs org-level change). Only the latter need learning reviews.
The selection criterion. After the postmortem, ask: "would another team benefit from this learning even though they don't share our service?" If yes, write the learning review. If no, the postmortem is sufficient.
Three sections a learning review needs
- What we used to believe: the assumption the incident violated.
- What we now believe: the updated mental model.
- Where else this applies: which other teams should care, even though they were not involved.
None of these belong in a postmortem. All three are essential to a learning review.
Section 1's discipline. Surface the assumption that was wrong. Most incidents have an underlying assumption ("we assumed X was always true"); the incident proved X is sometimes false. Naming the assumption is what makes the review transferable — other teams probably hold the same assumption.
Section 3's discipline. Be specific about who should read this. "Other teams should read this" is too vague; "teams using cross-region async replication should read this" is actionable. The specificity is what gets the right teams to engage.
Audience matters
A postmortem written for the team and one written for the org are different documents. Trying to write one that serves both produces a bad version of each. Pick the audience first; let the format follow.
The audience drives length, technicality, and structure. Postmortem audience: 5-10 engineers who already understand the system. Learning review audience: 100-500 engineers across the org who don't share context. Different vocabulary, different detail level, different examples.
The publication path. Postmortems live in the team's wiki or incident tool. Learning reviews live somewhere broader — engineering newsletter, all-hands deck, internal Confluence space. The path determines who actually reads the review; ensure it's a place the intended audience visits.
A concrete example
Incident: a database migration ran longer than planned, causing user-visible slowdown. Postmortem: timeline of the migration steps, exact queries that ran slow, action items to add migration timing alerts and to refactor the migration framework. Learning review: "We used to believe online migrations were safe to run during business hours; we now believe migrations exceeding 30 minutes need scheduled windows; this applies to any team running migrations on tables >50M rows."
The postmortem is for the database team. The learning review is for every team that runs migrations. Both contain real value; neither serves both audiences well.
Common antipatterns
Learning reviews that are just postmortem summaries. "Here's what happened in 200 words." Misses the point — the review's job is generalisation, not compression. Always include the three sections.
Postmortems that try to be learning reviews. Embedded "broader lessons" sections that nobody reads. Either the lessons are real (extract them into a separate review) or they're not (delete them).
Forcing a learning review for every incident. Most incidents don't generalise. Forcing reviews for all dilutes the format; engineers stop reading because most reviews aren't actually about something they need to know.
Learning reviews without distribution. Written, filed, never shared. The review's value depends on reaching the audience that needs it. Always pair the review with a distribution mechanism (newsletter, Slack post, engineering all-hands).
What to do this week
Three moves. (1) Audit your last 5 postmortems. How many had embedded "broader lessons" that were really learning reviews trapped inside? Those are the candidates for extraction. (2) For one of those, write the separate learning review using the three-section format. Distribute via your engineering newsletter or all-hands. (3) Add a "should this generate a learning review?" question to your postmortem template. The visible prompt forces the team to consider extraction during the postmortem itself.