The Root Cause You Never Found: A Post-Mortem on Post-Mortems
Every post-mortem follows the same pattern. The incident is resolved. The team gathers. Someone writes a timeline. Someone identifies the root cause. Someone assigns action items. The document is filed. The team moves on.
Six months later, the same incident happens again. Different system, same pattern. The post-mortem from six months ago is buried in a Confluence page nobody reads. The action items are lost in a Jira backlog. The institutional memory exists only in the heads of the people who were there — and half of them have left.
This is not a process failure. It is a memory failure. Post-mortems are written but not stored, stored but not retrieved, retrieved but not connected. The root cause is found forensically, then lost structurally.
The Fragmentation of Why
The explanation for why a decision was made lives scattered across: - The Jira ticket where the decision was recorded - The Slack thread where it was discussed - The design doc where it was justified - The meeting notes where it was approved - The engineer's memory of the conversation that never got written down
No single system holds the full "why." Each holds a slice. The post-mortem attempts to reconstruct the full picture, but it is a snapshot, not a graph. It does not link the Jira ticket to the Slack thread to the design doc. It does not persist the connections so that future incidents can traverse them.
The Persistent Model Alternative
A persistent company model stores decisions as first-class entities, linked to the signals that support them. The decision "use payments API v2" is a node. It links to: - The Jira ticket where it was scoped - The Slack thread where the trade-offs were discussed - The design doc where the architecture was justified - The ask-loop answer where the team clarified the rationale
Six months later, when a new incident touches the payments API, the model traverses the links. It surfaces the original decision, the context, the trade-offs. The post-mortem is not a new document — it is a traversal over existing structure.
The Compounding Value
The first post-mortem in a persistent model is not better than a traditional post-mortem. It is the same work, stored differently. The tenth post-mortem is dramatically better because the model can correlate across incidents: "this is the third time a dependency on an undocumented API has caused a slip. The pattern is: engineer flags complexity → review is delayed → sprint slips."
This correlation is not possible from documents. It requires a graph where incidents, decisions, and dependencies are nodes, and the relationships between them are edges. The graph is the memory. The post-mortem is the query.
A persistent model that never resets is requirement four of The Olmex Standard, and it is the difference between a post-mortem and a query.
The Honest Position
Olmex does not eliminate post-mortems. It changes what a post-mortem is. Instead of a document written after the fact, it is a traversal over the accumulated model — a query that returns the decision history, the signal chain, and the pattern correlation.
The root cause you never found was not in the incident. It was in the model — if the model existed. Building the model is the work of months, not days. But once built, it pays dividends on every future incident, every future decision, every future "why did we do it this way?"
The post-mortem is not the product. The model is.