Retrospective and Post-Mortem Writer

Teams repeat mistakes because they never honestly examine them, or they turn reviews into blame sessions that teach people to hide problems. This skill structures a blameless retrospective or post-mortem that gets to the real causes and converts them into specific changes, so the organization actually learns. The output is improvement, not a search for someone to fault.

1. What is being reviewed (a project outcome or an incident) and the facts of what happened.
2. What went well and what went wrong.
3. The timeline of events, if it is an incident.
4. The people involved (for perspective, not blame).

1. Establish the blameless frame

Focus on systems and decisions, not individuals. People act rationally given the information and incentives they had; the useful question is what about the system led there. Blame kills the honesty that makes retros work.

2. Reconstruct what actually happened

An honest, factual account. For incidents, a timeline. Separate facts from interpretations.

3. Find the real causes, not the first one

Dig past the proximate cause to the contributing factors. Ask why repeatedly until you reach something worth changing, not just the last thing that broke.

4. Capture what went well too

Reinforce the practices that worked, so improvement is not only about fixing.

5. Convert lessons to specific actions

Every meaningful finding becomes a concrete action with an owner and a date. A retro with no owned actions changes nothing.

ALWAYS use:

# Retrospective: [Project / Incident]
## Summary (what happened, outcome)
## Timeline (for incidents)
## What went well
## What went wrong and why (root causes, not just proximate)
## Contributing factors (systems, not people)
## Action items (change | owner | date)
## What we will reinforce

• Blaming individuals instead of examining the system.
• Stopping at the proximate cause.
• Findings with no owned, dated actions.
• Only cataloging failures and ignoring what worked.

A post-mortem on a missed launch reconstructs the timeline, traces the root cause to an unclear ownership handoff (a system gap, not a person), and produces three owned actions including a RACI for future launches.