Leadership Framework
How I Run an After-Action Review
The After-Action Review is the most useful leadership tool I learned in the Army, and the one most consistently misused in civilian work. This page gives you the four questions, the facilitation rules that make them honest, the differences between an AAR and a retrospective or postmortem, and a one-page template you can use this week.
Definition
What an AAR actually is.
An After-Action Review is a structured debrief held immediately after a defined event — a mission, a project phase, a launch, a customer call, a deploy. It exists to convert what just happened into what the team will do differently next time. The Army formalized the discipline in the 1970s through the National Training Center, and the U.S. Army Combined Arms Center still publishes the doctrine that governs it in Training Circular 25-20. It works because it is small, fast, and run the same way every time.
What an AAR is not: a status update, a retrospective vote on what to try next sprint, a postmortem that assigns blame, or a meeting where the most senior person reads the team a list of corrections. Strip those away and what remains is a guided conversation built around four specific questions, asked in a specific order, with a written output.
The Core Loop
The four questions.
Every AAR I have ever found useful answers these four questions, in this order. The order matters: each question only makes sense once the previous one has been answered honestly.
The four-question loop. Q4 always feeds the next plan in writing.
Question 01
What was supposed to happen?
Purpose: anchor the team in the plan as written.
Before anyone talks about what went well or badly, the team has to agree on what the plan actually said. Read the objective out loud. Pull up the brief, the spec, the ticket, the order. If two people in the room remember the plan differently, you have already found something worth fixing — and you have not even gotten to the event yet.
Scenario: a four-person team launches a small product update on a Thursday and rolls it back Friday morning. Asked what was supposed to happen, two people describe a feature launch and one describes a phased rollout. The plan was never shared the same way twice.
Question 02
What actually happened?
Purpose: a shared, agreed account of events.
Walk the event chronologically. Each person speaks to the moments they owned. No interpretations yet, no causes, no blame — only what occurred and in what order. The goal is one timeline the whole team agrees on. If you cannot get there, the rest of the AAR will not hold.
Scenario: on the same launch, the timeline shows the feature flag was toggled before the database migration completed. Nobody disputes the order once it is written down. The dispute was always about the cause, not the facts.
Question 03
Why was there a difference?
Purpose: separate causes from symptoms.
This is the question most civilian debriefs skip. Differences between plan and reality have causes — missing information, a brittle dependency, a handoff that was assumed but never owned, a check that was skipped because it had never failed before. Push past the first answer. A useful AAR usually finds the second or third cause, not the first one offered.
Scenario: the team initially says the rollback was caused by the migration. Pushing further, the cause was that no one owned the cross-check between the migration window and the flag toggle. The missing ownership is the real finding.
Question 04
What do we sustain, improve, or change?
Purpose: convert the conversation into a written commitment.
Three columns, not one. Sustain: what worked and should be protected even when pressure rises. Improve: what worked but can be tightened. Change: what must be redesigned because the current approach failed for a real reason, not a one-off. Every item gets an owner and a date. An AAR without a written output is a conversation, not a review.
Scenario: the team sustains its short feedback loop with engineering, improves the launch checklist by adding a dependency cross-check, and changes the flag-toggle process to require explicit handoff sign-off. Three items, three owners, three dates.
Facilitation
The rules that make it honest.
The four questions are not the hard part. The hard part is running them in a way that produces truthful answers in front of the people whose decisions are being examined. The Army solves this with four facilitation rules; civilian teams can adopt them without change.
- Rank is checked at the door. Inside the AAR, the most junior person on the team can name the senior person’s decision as the cause of a difference, and that is welcomed, not punished. If your culture cannot do this, fix the culture before you run the AAR. Otherwise the AAR will teach the team to lie politely.
- One person facilitates; that person is not the decision-maker. The decision-maker is in the room as a participant, not a chair. A facilitator who is also the boss will, without meaning to, signal which answers are welcome.
- Time-box it. Thirty minutes for a sprint or a single event. Ninety minutes for a project phase or a launch. Half a day for a major program close-out. Beyond that, attention degrades and the conversation drifts into storytelling.
- The output is written. Every AAR ends with a one-page artifact: timeline, three to seven findings, and the sustain / improve / change list with owners and dates. The artifact is what the next plan inherits. Anything not written down did not happen.
Adjacent Practices
AAR, retrospective, postmortem — not the same thing.
These three are routinely confused. They share ancestry but answer different questions, and the right tool depends on what you are trying to learn.
| Dimension | After-Action Review | Agile Retrospective | Engineering Postmortem |
|---|---|---|---|
| Trigger | End of a defined event or phase | End of every sprint, on a cadence | A specific incident or outage |
| Primary question | Why did plan and reality diverge? | How do we work better together next sprint? | What was the failure chain and how do we prevent recurrence? |
| Time horizon | The just-completed event | The last two weeks | The minutes and hours around the incident |
| Typical output | Sustain / improve / change list with owners | Team-norm adjustments and a few action items | Root-cause analysis, timeline, remediation list |
| Blame posture | Decisions are named; people are not blamed | Process-focused; people-light by design | Blameless by stated convention |
In practice the three overlap. A team that runs all three well will notice the AAR is the most plan-anchored of them: it always starts from a documented plan, and its first finding is often that the plan was understood differently by different people.
Failure Modes
Where AARs go wrong.
Every failure mode I have watched up close shows up as a symptom in the room. Treat the symptom early or the AAR will quietly degrade into a meeting nobody trusts.
- The room turns into a status update. People describe what they did, not what was supposed to happen. Fix: re-read the plan out loud at the top of every AAR. If there is no documented plan, name that as the first finding before going any further.
- Question three is skipped. The team jumps from “what happened” straight to “what should we do next time.” Fix: make the facilitator hold the room on causes for at least ten minutes. The improvement list is only as good as the causes underneath it.
- No written output. The conversation was good; nobody can find the notes a week later. Fix: a scribe is assigned at the start, the one-page artifact is published the same day, and the next plan references it explicitly. Anything not written down did not happen.
- Items have no owner or no date. “We should improve the handoff” with no name and no deadline is a wish, not a finding. Fix: the facilitator refuses to close the AAR until every change item has one owner and a date within the next operating cycle.
- Rank is not actually checked at the door. Junior people stay quiet while the senior person speaks. Fix: the facilitator calls on the most junior person first for each question. After two or three AARs, the room reorganizes itself.
One-Page Template
Copy this and run it Monday.
This is the page I actually write. It is short on purpose. If your AAR will not fit on one page, the event was probably two events.
AFTER-ACTION REVIEW Event: ____________________________________________ Date of event: __________ Date of review: __________ Facilitator: ____________________________________________ Participants: ____________________________________________ 1. WHAT WAS SUPPOSED TO HAPPEN (Read the plan as written. Note any drift between how participants remembered it.) 2. WHAT ACTUALLY HAPPENED (Chronological timeline. One line per material event.) T+00:00 ____________________________________________________ T+__:__ ____________________________________________________ T+__:__ ____________________________________________________ 3. WHY THERE WAS A DIFFERENCE (Causes, not symptoms. Push past the first answer.) · ____________________________________________________ · ____________________________________________________ · ____________________________________________________ 4. SUSTAIN / IMPROVE / CHANGE SUSTAIN ____________________________ Owner ______ By ______ SUSTAIN ____________________________ Owner ______ By ______ IMPROVE ____________________________ Owner ______ By ______ IMPROVE ____________________________ Owner ______ By ______ CHANGE ____________________________ Owner ______ By ______ SIGNATURES Facilitator: ________________________ Date: __________ Lead: ________________________ Date: __________
Sign it. Publish it. Reference it by name in the next plan. The artifact is the unlock.
Worked Example
See the framework run on a real workflow.
This framework is the engine behind every after-action artifact on this site. The clearest worked example is the GoDaddy cPanel publishing AAR, in which the four questions are applied to the site’s own publishing workflow and paired with Six Sigma DMAIC analysis. Four programs on this site run after-action discipline at program scale; each is linked below.
- AAR + DMAIC: the GoDaddy cPanel publishing workflow (the worked single-event example)
- Workforce Stability — charter, risk register, and program-scale AAR artifacts
- Veteran Regional Stability Index — program documentation with partial-publish discipline (AAR pending)
- Household Cost Tools (TCBI & TSCI) — program documentation; the mod_deflate buffer-cap incident is logged in memory (AAR pending)
- Veteran Livability Index — program documentation with embed-route discipline (AAR pending)
- Series 01: How I Write a Project Charter (the document the AAR reviews against)
- Series 02: How I Run a Risk Register (the register where AAR findings close)
Next in the Series
The AAR is the foundation of process improvement.
The next leadership-framework piece walks a full Six Sigma DMAIC cycle — Define, Measure, Analyze, Improve, Control — and shows where the AAR feeds in and where it does not. Run AARs consistently for a quarter and you will have the baseline data the Measure phase needs.