incident review meeting agenda that works

TL;DR

30 minutes, start with the timeline, spend most of the time on action items, end with owners and dates. The agenda that works is short because long reviews drift into blame or architecture debates. One incident, one meeting, out with assignments.

Error / query

incident review meeting agenda that works

The postmortem is written and now the team has to meet about it. You want an agenda that produces decisions, not a two-hour debate.

Use this skill when

• youre facilitating the post-incident review meeting
• past reviews ran long and produced nothing
• reviews keep drifting into blame or redesign arguments
• you need a standard agenda the team can reuse

Not for this skill when

• you need the postmortem document template (a different skill)
• the incident is still active (work the incident first)
• you need to track action items after the meeting (see the action items skill)

Steps

1. Send the agenda and the postmortem draft 24 hours ahead

Nobody should meet about an incident they havent read about. The agenda sets the timeboxes up front.

cat > /tmp/review-agenda.md <<'EOF'
# Incident review: [title]

1. Timeline walkthrough (10 min) - incident commander presents
2. What went well (5 min)
3. Root causes, systemic only (5 min)
4. Action items: owner and date for each (10 min)

Out of scope: blame, redesign debates, new feature pitches
EOF
cat /tmp/review-agenda.md

Expected: the agenda sent with the postmortem draft a day ahead. Attendees arrive having read the timeline.

2. Timebox with a visible timer

The agenda only works if the timeboxes hold. Start a timer the facilitator can see.

sleep 1800 && echo "TIME - wrap up action items now" &
echo "30-minute timer started, pid $!"

Expected: a hard stop at 30 minutes. When the timer fires, the only remaining business is assigning owners to action items.

3. Publish the notes the same day

Notes published tomorrow are notes nobody reads. Same-day notes with owners and dates close the loop.

cp /tmp/review-agenda.md ./postmortems/2026-10-04-review-notes.md
echo "notes published; every action item has an owner and a date"

Expected: review notes committed the same day, with action items carrying owners and dates. The meeting produced work, not just talk.

Variant phrasings

postmortem meeting agenda

Same fix: the four-part agenda in step 1 is the postmortem meeting agenda. Short, timeboxed, action-oriented.

how to run an incident retrospective meeting

Same fix: timeline first, blame never, most time on action items. The retrospective that works ends with assignments.

blameless review meeting format

Same fix: the "systemic only" rule in section 3 plus the out-of-scope list keeps it blameless. The facilitator enforces both.

Why it happens

Reviews sprawl because nobody owns the agenda, so the loudest topic wins: usually blame or a redesign argument. A short, pre-circulated agenda with timeboxes removes the vacuum that sprawl fills. Thirty minutes is enough because the real work (the postmortem doc) happened before the meeting; the meeting just ratifies action items.

Edge cases and pitfalls

• Remote team: run it async-first with a 15-minute sync for action items only. Dont make twelve time zones sit through a timeline read-aloud.
• Recurring incident: skip the timeline walkthrough and focus on why the last fix didnt hold. Thats the whole meeting.
• Execs attending: give them the summary up front so they dont derail the timeline section with questions.
• No action items identified: the meeting failed. Say so out loud and schedule a follow-up instead of pretending it worked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OcG9uqe74v-5AFUBtsJbVQ