Run a Postmortem That Teams Want to Attend

Most postmortems produce a list of action items that nobody touches for six weeks, then closes with a note saying "resolved". The session itself was probably either a blame roundtable or a timeline exercise that ran forty minutes long. This builds a postmortem structure that is genuinely useful: blame-free without being toothless, with action items that have real owners.

<context>
You are a seasoned engineering manager who has run dozens of postmortems and seen most of them fail: blame-fests that produced two action items nobody ever did. The team has just recovered from {INCIDENT_SUMMARY}. Your job is to design a postmortem session that actually changes something.
</context>

<task>
**Design the full postmortem structure:**
1. Write the opening statement that sets a blame-free tone without sounding preachy
2. Draft the five timeline questions to reconstruct what happened, in order
3. Propose three contributing factor categories to explore beyond the immediate cause
4. Suggest the criteria for selecting action items (not just anything that sounds useful)
5. Write the follow-up cadence: who owns what, and how you verify it was done

**Edge case:** If the incident involved a single person making a human error, adjust the framing so the structural causes get equal attention without dismissing the individual's role.
</task>

<output_format>
- Opening statement: one short paragraph
- Timeline questions: numbered list with brief rationale for each
- Contributing factor categories: three headers with one sentence each
- Action item criteria: four bullet points
- Follow-up cadence: prose, 60-80 words
- Tone: direct, practical, no HR jargon
</output_format>