Postmortem Review¶
Event-triggered review — instantiates Reflexive Self-Monitoring
Uses a failure, incident, near miss, or major outcome as evidence for revising future behavior and safeguards.
A Postmortem Review is fired by a specific event — an outage, a near miss, a surprising outcome — and works backward from it to the system's own contribution, so that the same failure is harder to reproduce. Its defining trait is that a single, concrete incident is the unit of learning: the review reconstructs what actually happened, asks how the actor's own decisions, safeguards, and blind spots let it happen, and produces named corrective actions with owners. Unlike a recurring ritual, it does not run on a calendar; it runs because this thing broke. Its whole discipline is turning one painful event into durable memory and specific safeguards, without letting the search for causes curdle into a search for someone to blame.
Example¶
A payments service is down for 47 minutes after a routine config change. Once service is restored, the on-call team runs a postmortem. They build a minute-by-minute timeline from logs and chat: the change passed CI, deployed clean, and only failed under production traffic because a validation step existed in staging but had been quietly disabled in prod months earlier. The instructive part isn't "who ran the deploy" — it's that the system let a safeguard silently diverge between environments and nobody noticed. The review records this as durable memory: a written record of the timeline, the contributing conditions, and the reasoning, so the next team facing something similar can find it. It produces three owned action items — re-enable and alert on the validation step, add a prod/staging config diff check, name owners and dates — and frames one as a hypothesis: if we alert on disabled safeguards, then silent divergence gets caught early, which the next incident (or its absence) will test. The value is a single failure converted into memory plus specific, owned safeguards.
How it works¶
- Trigger on the event. The review exists because a specific incident occurred; the incident is the evidence and the boundary of what's examined.
- Reconstruct before judging. A factual timeline of what happened, built from records, precedes any account of cause — the sequence is the shared object everyone reasons from.
- Find the system's contribution. The question is how the actor's own safeguards, defaults, and decisions permitted the failure, not which individual to fault.
- Emit owned actions and a written record. Corrective actions get names and dates; the reasoning and timeline are preserved so the lesson survives the people who learned it.
Tuning parameters¶
- Trigger threshold — every incident, only above a severity bar, or near misses too. A low bar catches more but floods the team; a high bar misses the cheap warnings.
- Blame stance — blameless by design versus accountability-seeking. Blameless surfaces honest cause but can feel like nobody owns anything; the tension is real and deliberate.
- Depth — a quick five-whys versus a full contributing-factors analysis. Depth finds systemic causes but costs hours and can over-engineer a minor event.
- Action rigor — advisory findings versus tracked, owned, dated items. Tracking drives follow-through but risks a backlog of stale action items.
- Record durability — a filed doc versus a searchable, linked archive. Durable records compound into institutional memory; buried ones are re-learned the hard way.
When it helps, and when it misleads¶
Its strength is converting rare, expensive failures into cheap future safety: a well-run postmortem finds the systemic condition behind a one-off and installs a safeguard, and its written record lets an organization learn from an incident its next team never lived through. The blameless postmortem, associated with John Allspaw's engineering-safety work, is the discipline that keeps the analysis honest by separating learning from punishment.[1]
Its failure modes are blame and shelf-ware. Once the review becomes about fault, people withhold the very details that explain the failure, and the analysis dies — the punitive review spiral. Just as often, the postmortem produces a tidy document with action items that no one owns or does, so the same incident recurs and the report becomes filed evidence of learning that never happened. The guarding discipline is to keep it blameless and to track the actions to closure — a postmortem whose safeguards are never built is documentation, not learning.
How it implements the components¶
accountability_anchor— it assigns named, dated ownership for each corrective action, making follow-through visible.decision_memory— the written timeline, contributing factors, and reasoning become durable memory the organization can learn from across future incidents.experiment_or_change_hypothesis— each safeguard is framed as an if-then bet whose effect the absence (or recurrence) of the failure will test.
It is triggered by a specific incident, not run on a rhythm — the standing reflection_cadence and process-level adjustment_rule of a recurring review belong to Team Retrospective.
Related¶
- Instantiates: Reflexive Self-Monitoring — the postmortem is the loop's event-triggered branch, learning from a single failure.
- Sibling mechanisms: Team Retrospective · Organizational Review · Peer Feedback Session · Reflective Journal
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Postmortem Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it uses a failure, incident, near miss, or major outcome as evidence for revising future behavior and safeguards.
Independent corroboration: The frozen evidence defines Postmortem Review as 'Uses a failure, incident, near miss, or major outcome as evidence for revising future behavior and safeguards', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Learning from failures and near misses through systems-focused review is rooted in safety and reliability engineering.
Related originating lineages:
- Aviation & Aeronautics — Aviation independently institutionalized accident and near-miss investigation.
- Computer Science & Software Engineering — Software incident postmortems materially standardized blameless technical reconstruction and corrective action.
- Organizational & Management Science — Organizational management developed the blameless retrospective as a recurring learning practice.
Review resolution: Both blind reviewers agree that engineering design is the primary origin. Reconciliation resolves alternate origin disagreement. Formative alternate lineages are retained as aviation_aeronautics, organizational_management, computer_science; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=convergent describes the relationship among origin lineages.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Allspaw, J. "Blameless PostMortems and a Just Culture". Etsy Code as Craft (2012). Explains blameless postmortems as learning-focused investigations that elicit detailed accounts without fear of punishment. registry ↩