A fintech startup ran postmortems after every major incident for a full year. At the end of that year, their CTO noticed something uncomfortable: the same categories of issues kept appearing. The postmortems were happening — the learning was not.
What was going wrong in the process
Each postmortem produced a list of action items. Those items were assigned to individuals with loose deadlines. Nobody tracked completion. In the next incident review, the same gaps appeared, sometimes with a note that the fix was still pending.
The format was also wrong. Postmortems were written by the engineer closest to the fix, which meant they were technically detailed but organizationally thin. Process failures and communication breakdowns received two lines. Root cause analysis stopped at the technical layer.
The restructured approach
They moved to a facilitated postmortem format with a dedicated facilitator who was not involved in the incident itself. The format required answers to five specific questions:
- What was the user or client impact, in concrete terms?
- What detection method found this — and why did it take that long?
- Where did the response process break down, not just the system?
- What decision was hardest to make, and what made it hard?
- What one change, if made before this incident, would have most reduced the impact?
The difference it made
Action items from postmortems were moved into the main project tracker with sprint assignments. Completion was reviewed at the monthly engineering retrospective, not left to individual follow-through.
Within eight months, two recurring incident categories disappeared entirely. A third dropped in frequency. The postmortem process did not solve every problem — but it stopped producing shelf documents.