The Report Nobody Reads
The post-mortem has become one of the most universally practiced and least effective governance tools in organizational life. Every field that has adopted it — engineering, project management, healthcare, emergency response, education — has developed its own version of the same ritual: after something goes wrong, convene a meeting, document what happened, produce a list of lessons learned and action items, and file the report.
The outcomes are also universal. The lessons sit unread. The action items go unassigned or uncompleted. The same failure mode recurs, often within 12 months, often in the same team. The next post-mortem documents it again.
This is a design failure, not an intent failure. The people who run post-mortems generally want them to work. The organizations that mandate post-mortems generally want to learn from incidents. The problem is that the standard post-mortem format is designed to produce documentation, not change. It is, in governance terms, a ceremony for acknowledging that something went wrong — not a mechanism for preventing it from going wrong again.
The Recurrence Prevention Protocol described in this article rebuilds the post-mortem from the goal backward. The goal is not a report. The goal is a measurable change in the system that produced the failure. Every element of the protocol is designed with that goal in mind.
Why Post-Mortems Fail to Prevent Recurrence
The failure modes of the standard post-mortem are well-documented by the organizations that have studied them most seriously — high-reliability organizations in aviation, nuclear, and healthcare. They converge on four structural problems.
The attribution problem. Standard post-mortems, despite explicit guidance to avoid blame, routinely produce attribution to a person rather than to a system. The timeline reconstruction surfaces what someone did or failed to do. The root cause analysis identifies who made the decision. The corrective action specifies retraining that person or tightening the approval process they bypassed. The system that made the failure easy, predictable, and almost inevitable goes unexamined. Attributing a systemic failure to individual error does not prevent recurrence — it prevents honest analysis.
This is not primarily a cultural problem. It is a structural one. Standard post-mortem formats ask "what happened and why?" in a sequence that naturally surfaces proximate causes and proximate actors. Reaching systemic causes requires a different analytical sequence, one that specifically asks: what conditions made this failure easy? What would have had to be different for a different person in the same situation to have avoided the same outcome?
The action item problem. Post-mortem action items share a characteristic with risk register entries: they are created in a context of high motivation (the meeting) and then handed off to a context of low accountability (someone's task list). The standard action item format — "Owner: [Name], Due: [Date]" — produces no mechanism for completion verification, no consequence for non-completion, and no follow-up by the people who created the action item. Completion rates for post-mortem action items in organizations that have measured them are typically 30–50%, and the items that get completed are usually the easiest ones, not the most important ones.
The documentation problem. Post-mortem reports are filed in shared drives where they are rarely retrieved. Lessons learned sections are written at a level of generality that makes them non-actionable: "improve communication," "ensure clearer requirements," "strengthen testing protocols." These lessons are true and useless. They cannot be applied to the next situation because they do not specify what different action to take in what specific circumstance. A lesson that does not change behavior is not a lesson — it is a statement.
The timing problem. Post-mortems typically happen days or weeks after an incident, when the full team is available and the pressure has subsided. The team members who were most directly involved have spent the intervening time reconstructing their own mental model of what happened in ways that are self-consistent and self-exonerating. Memories have converged. The discomfort that drives honest analysis has faded. The post-mortem convenes at precisely the moment when the appetite for uncomfortable learning is lowest.
The Structural Elements of a Post-Mortem That Drives Change
The Recurrence Prevention Protocol has six elements. Each is designed to address one of the failure modes above.
Structured timeline reconstruction before the meeting. Within 48 hours of an incident — not two weeks — the team lead collects a factual timeline: what happened, in sequence, with timestamps where available. This is not a narrative. It is a structured log of events, decisions, and observations. Sources include system logs, message threads, email records, and brief (10-minute) written inputs from each person involved. The inputs are collected individually, before the group convenes, specifically to preserve the diversity of perspectives that group discussion will erase. The timeline is shared with participants before the post-mortem meeting. The meeting does not reconstruct the timeline — it analyzes it.
Root cause analysis that reaches systemic causes. The analytical sequence matters. The Recurrence Prevention Protocol uses a modified "Five Whys" approach with a constraint: the chain of causation cannot end at a person's decision. It must continue until it reaches a system condition — a process, a resource allocation, a structural incentive, a design feature — that made the failure predictable. This requires the facilitator to enforce the constraint explicitly: when the analysis produces "the engineer approved an untested deployment," the facilitator asks "what made it possible for an untested deployment to reach the approval stage?" When it produces "the team skipped the verification step," the facilitator asks "what about the process made skipping the verification step easier than completing it?"
This does not eliminate individual accountability — it contextualizes it. A systemic cause analysis that produces "the deployment pipeline had no automated verification gate" and "the approval checklist was 47 items long and routinely completed as checkbox theater" gives the organization actionable targets. "The engineer made a mistake" gives the organization a warning to issue.
Action items tied to system or process changes. Post-mortem action items should produce changes in four categories: process (what we do), system (how tools and infrastructure are configured), structure (how decisions are made and who owns what), or training (what people know how to do). Action items that do not fall into one of these categories — "be more careful," "communicate better," "follow the process" — are not action items. They are wishes. The Recurrence Prevention Protocol rejects them in the meeting and replaces them with the system-level change that would make "being more careful" automatic rather than volitional.
Every action item must have: a named owner who has agreed in the meeting, a specific completion criterion (not "improve the deployment checklist" but "reduce the deployment checklist to 12 items with automated validation for 8 of them"), and a verification date. The verification date is scheduled in the meeting, before the meeting ends. This is non-negotiable. If the verification date is not scheduled in the meeting, the action item will not be verified.
Follow-up review at time of post-mortem. The post-mortem produces two calendar entries before it closes: the verification date (when action item owners report on completion) and the recurrence review date (90 days out, when the team confirms the same failure mode has not recurred). These are not optional. Scheduling them in the meeting, with the full team present, produces a fundamentally different accountability dynamic than scheduling them after the fact. Everyone in the room knows the date. Everyone in the room will be there. The action item owner knows this.
Lessons embedded in process, not documented in reports. The post-mortem report is written, filed, and never read. The lesson embedded in the deployment checklist, the onboarding process, the partner agreement template, or the decision memo format is read every time that process runs. The Recurrence Prevention Protocol requires that every lesson be assigned to a specific process where it will be embedded, with a named owner for the embedding. "Lesson: we should verify that test coverage includes edge cases" becomes "Action: add edge case coverage verification as item 3 in the pre-deployment checklist, owned by the tech lead, completed by [date]." The lesson is now in the process. It will be consulted whether or not anyone remembers the post-mortem.
Pre-mortem integration. The best post-mortem is the one that prevented the failure. Teams that run post-mortems consistently for 12–18 months develop pattern recognition: they begin to see, before a project or deployment or program launch, the conditions that have historically produced failures. The Recurrence Prevention Protocol integrates this pattern recognition into a pre-mortem practice: before major decisions or launches, a 30-minute session that asks "what would have to go wrong for this to become a post-mortem?" The answers are drawn directly from the organization's post-mortem history. This closes the learning loop — post-mortems generate patterns, pre-mortems apply them forward.
Making Post-Mortem Outputs Actionable for Teams Under Time Pressure
The objection to this protocol, in every organization where it is introduced, is time. The team is already under pressure. Adding structured timeline reconstruction within 48 hours, a root cause analysis that requires a facilitator, a post-mortem meeting with a specific analytical sequence, individual input collection before the meeting, and scheduled verification reviews is, the objection goes, too much process for an organization operating at capacity.
This objection is correct about one thing: the full protocol is more demanding than the standard post-mortem. It is correct about nothing else. The standard post-mortem consumes the same meeting time and produces no change. The Recurrence Prevention Protocol consumes somewhat more process time and prevents the next incident — which will cost the organization far more than the additional process overhead.
The practical adaptation for teams under time pressure is proportionality. Not every failure warrants the full protocol. The Recurrence Prevention Protocol distinguishes three incident levels:
Level 1 (localized, low impact): A 20-minute team discussion using a simplified three-question format — what happened, what made it possible, what specific change will prevent it — followed by one action item, one owner, one date. No formal report required.
Level 2 (cross-functional, moderate impact): The full timeline reconstruction, a 60-minute post-mortem meeting with a facilitator, root cause analysis to systemic level, action items in the four categories, verification date scheduled. A one-page summary shared with leadership.
Level 3 (organizational, high impact): The full protocol including pre-meeting individual inputs, an external or senior internal facilitator, root cause analysis reviewed by leadership, action items with board-level visibility, 90-day recurrence review. A full report shared with the board.
The level classification happens within 24 hours of the incident, before timeline reconstruction begins. It prevents both under-investment (Level 1 process applied to a Level 3 incident) and over-investment (Level 3 process applied to a Level 1 incident).
The Facilitator's Role
The quality of a post-mortem is determined almost entirely by the quality of the facilitation. A skilled post-mortem facilitator does three things that an unskilled one does not.
First, the skilled facilitator maintains the analytical sequence. When the group wants to jump from "what happened" to "how do we fix it," the facilitator holds the group in the analytical phase until the root cause chain has reached systemic conditions. This is uncomfortable. Teams under pressure want to move to solutions. The facilitator's job is to resist this pressure long enough for the analysis to be honest.
Second, the skilled facilitator redirects attribution from persons to systems. When a participant says "the problem was that [person] made a bad call," the facilitator asks "what conditions made that call likely?" — not to exonerate the person, but to reach the system condition that made a bad call available to anyone in that role. This requires genuine skill. The redirect cannot be mechanical. It must be curious and genuinely interested in the answer.
Third, the skilled facilitator converts lessons to actions before the meeting closes. When a participant says "we need better communication," the facilitator asks "what would better communication look like in this specific context, and what process change would produce it?" The meeting does not close until every lesson has been translated into a specific action or explicitly parked as a question for follow-up.
The facilitator should not be the person most affected by the incident, the most senior person in the room, or the person who made the decision most implicated in the failure. These constraints are necessary for the analysis to be honest.
The Organizational Condition for Success
The Recurrence Prevention Protocol works in organizations where failure is treated as information. It fails in organizations where failure is treated as evidence of individual inadequacy. This is a leadership condition, not a process condition. No post-mortem format can survive in an organizational environment where the first question after an incident is "who is responsible?" in the accountability-as-punishment sense.
Leaders who want post-mortems to work have one primary task: to demonstrate, repeatedly and visibly, that reporting a failure honestly produces better outcomes than concealing it. This requires that the first response to a disclosed failure is curiosity, not judgment — and that this pattern holds consistently enough that the team believes it will continue to hold.
In organizations where this condition exists, the Recurrence Prevention Protocol compounds in value over time. Post-mortems generate patterns. Patterns inform pre-mortems. Pre-mortems prevent incidents. The incidents that are prevented cannot be measured directly, but their absence becomes visible as the organization navigates complexity with fewer failures than its peers. This is the compounding return on a post-mortem practice that actually works.
What to Do After the Next Incident
The next time something goes wrong, do not call a meeting in two weeks. Do this instead.
Within 24 hours: classify the incident level and assign a timeline reconstruction owner. Within 48 hours: collect individual written inputs from everyone involved, compile the factual timeline, and distribute it to participants. Within 5 days: run the post-mortem with a facilitator who is not the most affected person, analyze to systemic causes, produce action items with owners and completion criteria, and schedule verification and recurrence review dates before the meeting closes. Within 30 days: embed lessons in the relevant processes. At the verification date: review completion. At 90 days: confirm non-recurrence.
This is more work than filing a report. It is less work than repeating the failure.