Book companion resource · Template
Post-Incident Debrief Template
Letter & A4. Print-ready. Free, no email required.
← Back to toolkit · Browse by chapterEvery war room event gets a 90-minute debrief within 72 hours of incident closure. Six questions, in order. One two-page memo as output. The install list is the most valuable artifact of the whole response.
Companion to: Fix the System, Chapter 11. Who uses it: the Incident Commander facilitates; all five war room roles + plant manager attend; the Comms Lead captures the memo. Where filed: war room archive (physical folder or shared drive), plant manager's file, planning queue for install items.
Event reference
| Field | Value |
|---|---|
| Incident name / short description | |
| Date of incident declaration | |
| Date of incident closure | |
| Duration (hours) | |
| War room activated? | Yes / No |
| Debrief date | |
| Debrief location |
Attendees
| Role | Name |
|---|---|
| Incident Commander | |
| Safety Officer | |
| Operations Lead (day) | |
| Operations Lead (night, if split) | |
| Logistics Lead | |
| Communications Lead | |
| Plant Manager | |
| Other material contributors |
Question 1 — What happened?
Build the timeline together before the analysis starts. Hour by hour. On a whiteboard in the room if that helps. Everybody agrees on the facts first.
| Time | Event / decision | Who was involved |
|---|---|---|
Keep timeline entries factual. No analysis, no blame, no "we should have." Just what happened, in order.
Question 2 — What did the system do well?
Before criticism. Name what the structure caught, what the cadence preserved, what would have gone worse without the war room.
Examples of what to capture:
- A decision that got made quickly because the IC was clearly designated.
- A safety call that the Safety Officer owned and the IC backed.
- Information that stayed coherent to the plant manager because Comms handled it.
- A shift handoff that preserved context.
- A resource that arrived in time because Logistics had the right contact.
List at least three specific moments. Not generalities.
1. 2. 3.
Question 3 — Where did the response drag?
Specific moments where decisions got stuck, information got lost, or the wrong person was doing the wrong thing. Name the moments. Do not name the people.
The rule is: we criticize the system, not the individuals. A moment where the Ops Lead got pulled into a customer call is a system problem (Comms did not intercept), not a person problem. Phrase findings accordingly.
| Moment | What went wrong | Root cause (system level) |
|---|---|---|
Question 4 — Where did the plant itself fail?
Separate the response from the underlying asset, procedure, or system that caused the event. A good response to a bad failure still reveals the bad failure.
This is the technical post-mortem. The war room managed the response well or badly, but the event itself came from somewhere. What was that somewhere?
- Asset condition: What was the state of the asset? What did we know, or not know, about its condition before the event?
- Procedure gap: Was there a PM, inspection, or close-out procedure that should have caught this and did not?
- System gap: Was the event a type we had not planned for? Should we plan for it now?
- Contractor work: Was prior contractor work involved? Reference Chapter 9 close-out standards.
Question 5 — What do we install into the cycle?
The install list. This is the output of the debrief. Each item is a specific change that goes into the planning queue, the preventive program, the inspection routine, or the procedures library.
Not recommendations. Not suggestions. Work orders, inspection additions, procedure edits, training commitments. Each item has an owner and a due date.
| # | Install item | Owner | Due date | Category |
|---|---|---|---|---|
| 1 | work order / PM / procedure / training / other | |||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 |
Categories:
- Work order: a specific job that must be done once and closed.
- PM: a recurring preventive maintenance task to be added to the program.
- Procedure: a change to a written procedure, work instruction, or standard.
- Training: a training module or drill that needs to be built and delivered.
- Other: vendor qualification, tool purchase, spare stocking, documentation.
Minimum: 3 items. Typical: 5-10 items. If fewer than 3, the debrief was shallow and should be re-run.
Question 6 — What do we change about the war room itself?
The structure learns from every activation. Role definitions, cadence, handoff format, stakeholder list, the war room space itself — everything is on the table.
| Structural change | Effective date |
|---|---|
Examples of things that get revised:
- Role assignment pattern (who plays which role by default).
- Cadence (add a 1 a.m. check-in during overnight events? drop the 7 p.m. stand-down on day 3?).
- Handoff form content.
- Stakeholder update schedule and channel.
- Who gets the end-of-day written summary.
- Physical space, supplies, technology.
Output — the two-page memo
Within 7 days of the debrief, the IC produces a two-page memo with the following structure:
Page 1 — Executive summary
- Event description (3-4 sentences)
- Key timeline beats (6-8 bullets)
- What went well (3 bullets)
- Where the response dragged (3 bullets)
Page 2 — Install list + structural changes
- Install list (the Question 5 table)
- Structural changes to the war room (the Question 6 table)
- Signature line for plant manager acknowledgement
Distribution: plant manager, executive office, all five war room role-holders, planning queue for install items.
Filed to war room archive. The memo is re-read at the start of the next war room activation, which is often what tells the plant its structure is improving year over year.
Facilitation tips
- Start with the timeline. Do not start with "what went well." Start with what happened, hour by hour, on a whiteboard. Agreeing on the facts is 30-40% of a good debrief.
- Time each question. Rough budget: timeline 25 min, what went well 10 min, where it dragged 20 min, plant failures 15 min, install list 15 min, structure changes 5 min. Total 90 min.
- The IC facilitates, but does not dominate. Ask the other roles for their own observations before offering yours. A debrief that becomes the IC's monologue has failed.
- Do not use "we should have." Use "the structure did not catch X" or "we did not have a procedure for Y." Fixes go in Question 5. The debrief is not the place to perform blame or contrition.
- End with the install list. Leaving the room without named items and named owners is the single biggest failure mode of post-incident debriefs. Do not leave without it.
What NOT to do in a debrief
- Do not invite people who did not materially contribute to the event. Observers dilute candor.
- Do not read through the timeline aloud. Build it together from memory in the room.
- Do not start scoring. A debrief is not a review. The IC is not being graded.
- Do not write the memo before the debrief and fill in answers during the meeting. That is theater.
- Do not skip the debrief because the event "went well." The events that go well are often the ones with the most teachable structure wins.
From Fix the System by Ivan Getov. Companion to Chapter 11: The War Room. getov.xyz/toolkit/fix-the-system/ch11/post-incident-debrief-template. Free. No email required.