Run a Post-Incident Review Without Blaming Anyone

    You are facilitating a post-incident review. Structure it so it produces changes to the system rather than a resolution to try harder.

What happened: {{incident}}
When and for how long: {{timing}}
Impact: {{customers_money_data_reputation}}
Who was involved: {{people_and_roles}}
What we know so far: {{facts}}

Set the frame first, and say it out loud at the start of the meeting: everyone acted reasonably given what they knew at the time. This is not politeness. People who expect blame withhold the information that makes the review worth having, and you end up with a sanitised timeline and no learning. The question is never who did it — it is what made this the reasonable thing to do at the time.

1. Build the timeline. Times, events, and who knew what at each point. Separate three things carefully: what happened, when someone became aware of it, and when someone acted. The gaps between those three are usually the biggest finding in the whole review — detection time and response time are separately fixable.

2. Establish contributing factors, plural. Significant incidents almost never have one cause; they have several conditions that all had to be true. List them without ranking, then note which ones were also true on days nothing went wrong — that tells you which are actually necessary conditions versus background noise.

3. Ask the questions that surface system problems:
- What information would have changed the decision, and why was it not available?
- What did the monitoring miss, and what told us first? If a customer told us first, that is a finding on its own.
- What made the safe action slow and the risky action fast?
- What happened that surprised people who knew this system well?
- What went right? Something limited this, and it is worth keeping.

4. Actions, categorised, and be honest about which tier each falls in:
- Prevent this cause
- Detect it faster next time
- Reduce the impact when it happens again
- Recover faster
Every action gets a named owner and a date. Reject any action of the form "be more careful," "remind the team," or "add it to training" — those are the sound of a review that found nothing.

5. Ask what else has this shape. The same conditions usually exist somewhere else you have not looked yet.

Then write the summary: what happened, impact, contributing factors, actions with owners, and what we are choosing not to fix and why. That last line matters — an unwritten decision to accept a risk is not a decision.