Most postmortems are well-intentioned and change nothing. The meeting happens, the document gets written, a list of action items appears at the bottom, and six months later the same failure happens again while everyone half-remembers having discussed it.
The document is not the point. The change is the point, and there are a few specific reasons the change usually does not arrive.
Blame quietly ends the investigation
The moment a review is looking for a person, it stops looking for a cause. The person is easier to find, the search terminates, and everyone can go home. It feels like a conclusion.
The deeper problem is that blame makes the next investigation worse. People who expect to be blamed report less, later, and less completely, so the information you need stops arriving. You do not get honest timelines from people who are managing their exposure.
This is not about being nice. It is that a system which allowed one person to take it down will allow the next person to do the same, and the useful question is why the system permitted it, not why the human did the obvious thing.
Separate the decision from the outcome
An engineer who made a reasonable call with the information available, and got a bad result, made a good decision. An engineer who guessed, and got away with it, did not. If you grade by outcome, you teach people to avoid decisions rather than to make better ones, and you learn nothing about your actual process.
Ask what the responder knew at each point, not what you know now. Hindsight makes every incident look obvious, which is precisely why it is useless for finding out what to change.
Action items need an owner and a date, or they are wishes
This is the boring, mechanical part, and it is where most of the value leaks out. An item that says "improve monitoring for the payment path" will never be done, because it is not a task, it is a sentiment.
Useful items are small enough that one person can finish them in a normal week, assigned to a named human rather than a team, and tracked wherever the team's real work is tracked rather than in the postmortem document nobody reopens. If an item is too big for that, it is a project and needs to be argued for on its own terms.
Do fewer of them, properly
If everything gets a postmortem, the format becomes paperwork and the quality collapses. Pick a threshold, write it down, and hold to it. Everything below the line gets a ticket and a one-line note.
The ones above the line deserve real time: a timeline built from evidence rather than memory, the contributing factors, and honest treatment of the things that went right, which are usually invisible and worth protecting.
The signal that it is working
You know the process is real when someone brings up a near miss that nobody outside the team noticed. That only happens in an organization where reporting a problem is safe and useful, and it is worth more than any document.