Post-Mortem Template

Why most post-mortems produce nothing

Most retros run hot for an hour, generate a long list of "learnings", get summarized into a deck nobody reopens, and the next program repeats the same mistakes. The pattern isn't because PMs are lazy. It's because the format invites narrative instead of decision.

A post-mortem is only useful if it changes the next program. That means the output isn't "what we learned", it's "what we'll do differently, who owns it, when it lands." Anything less is a writing exercise.

"A retro that doesn't change the operating model is theater. The artifact is the change, not the document."

This template structures the retro to produce ownership and changes, not narrative. The facilitation guide covers how to run the session so the team is honest without descending into blame.

Blameless ≠ consequence-free

The phrase "blameless post-mortem" gets misused. People hear it as "we don't talk about who did what." That's not the discipline. The discipline is:

• Focus on the system, not the person. When a person made a mistake, the question is what about the process, tooling, or context made that mistake easy to make.
• Decisions get owners. "We should improve handoffs" is not a decision. "The release manager owns rewriting the handoff template by Friday, with sign-off from the engineering lead" is a decision.
• Repeated patterns get escalated. If the same kind of failure shows up across three programs, that's a leadership-level issue, not a per-program one.

Pair the post-mortem with the pre-mortem template on your next program, comparing what you predicted vs. what actually happened is one of the highest-leverage learning loops in program management.