Sergeant Major Jason has run more After-Action Reviews than he can count. In 26 years of military service — field exercises, deployments, garrison operations, major training events — the AAR was the primary tool for learning what worked, what didn't, and why. It was so embedded in the culture that no one questioned it. You run the mission, you run the AAR, you get better.
When he transitioned to the civilian world and started leading teams, he noticed something immediately: the civilian version of the AAR — the "retrospective" or "post-mortem" or "lesson learned" meeting — was almost universally bad. People complained in vague terms. Someone took notes that no one read. The action items, if any existed, disappeared into a shared doc that no one looked at again. The meeting happened, time passed, and the same mistakes happened again.
The AAR isn't complicated. But it is specific — and the specificity is what makes it work. Civilian retrospectives fail because they skip the structure. Military leaders who know how to run a real AAR have a serious competitive advantage in any team environment. Here's how to bring it in.
📌 Context first: If you're earlier in your transition, start with Your First 90 Days After the Military. Running an AAR requires some organizational credibility — the framework is most effective once you're established in a team. But you can introduce it early, starting small.
What an AAR Actually Is (And Isn't)
The civilian world has a loose equivalent called a "retrospective." Most teams run them badly — a loosely structured conversation where people talk about what went wrong and feel vaguely bad about it. That's not an AAR.
A real After-Action Review is a structured, facilitated discussion that follows a specific format. It's not a complaint session. It's not a performance review. It's not a blame assignment meeting. The AAR's single purpose is to extract lessons from an event — what was planned, what actually happened, why there was a gap, and what we're doing differently next time.
The format was developed by the US Army in the 1970s as a training tool, and it's been refined over decades of use across all branches and across allied militaries worldwide. The reason it's survived that long is simple: it works. Not as a philosophical discussion — as a practical improvement mechanism. Done properly, it produces specific, actionable changes that show up in measurable results within the next execution cycle.
The key distinction: AARs are focused on the event and the process, not on individuals. The military runs them immediately after an event — sometimes within hours — while details are fresh and before people have had time to construct narratives about what happened. This timing matters enormously, and civilian organizations almost never do it.
The Four AAR Questions
The military AAR format has four questions, run in order. This sequence matters. Skip a step or run them out of order and the AAR loses its structure — and therefore its effectiveness.
What was planned?
The first question establishes the baseline. Not "what did we hope would happen" — what was the actual plan? What were the specific objectives? What was the timeline? What resources were allocated? What was the decision criteria for success?
This question does something critical: it separates planning failures from execution failures. If the plan was good and execution failed, that's one lesson. If the plan was flawed, that's a different lesson. If the plan was right but the situation changed unexpectedly, that's yet another lesson. You can't answer any of those questions without first establishing what was planned.
Civilians almost never do this step. They jump straight to "what went wrong" without establishing what was supposed to happen. The result is a discussion of symptoms, not causes.
"The OPORD specified a 0600 H-hour with three forward squads advancing on a suppression timeline of 15 minutes. Resource allocation was 4×60mm mortars with 48 rounds."
"The project plan specified a May 1 launch with the data migration completing by April 15, three QA sprints in the final two weeks, and a Go/No-Go decision point on April 28."
What actually happened?
The second question is a factual reconstruction of events. Not interpretations, not evaluations — just the sequence of what actually occurred. In military AARs, this step is often supported by the "commo check" — checking communication logs, operation logs, and other documentation to establish an objective timeline.
In civilian contexts, this is where the meeting can go wrong fast if you're not careful. People want to jump to "why" before they finish establishing "what." Your job as the facilitator is to keep the group on the factual sequence. What happened, in order, from beginning to end. Disagreements about what happened are resolved by going to the data — emails, logs, project management records, whatever exists.
One rule the military enforces: everyone who was present contributes to this reconstruction. The AAR isn't a leader reporting to subordinates — it's a collective reconstruction of events by everyone involved. This prevents the leader's version of events from overwriting what actually happened.
"The H-hour was delayed 45 minutes due to a vehicle maintenance issue. Squad 1 reached the first waypoint at 0635, Squad 2 at 0638. Suppression was called in at 0641. The target was engaged at 0647."
"The data migration didn't complete until April 18 — three days late. QA Sprint 1 started on April 19 as scheduled. Sprint 2 was shortened from two weeks to nine days after the delay. The Go/No-Go meeting happened on April 28 as planned."
Why did it happen that way?
The third question is where most civilian retrospectives live — but they jump here too quickly, before establishing the plan and the facts. Now that both are on the table, the group can examine the gap between what was planned and what actually happened.
The military teaches facilitators to push for root cause — not symptoms. "We ran out of time" is a symptom. "The scope was underestimated and no one had authority to cut it" is closer to root cause. "The project had no formal change control process, so scope creep accumulated invisibly until the deadline was structurally unreachable" is root cause.
This question requires honest analysis, which means it requires psychological safety. If people feel like admitting a mistake will be held against them, they'll soften the analysis. The facilitator's job is to make root cause analysis safe — the AAR is about the process, not the person. Leaders set the tone by asking genuine questions rather than making judgments.
One technique that works: ask "why" five times. The first "why" produces a surface explanation. The second reveals a process failure. The third reveals a system failure. By the fifth, you're often at a root cause that no one in the room had named before the exercise began.
"The 45-minute delay in H-hour cascaded from a maintenance deferral decision made 8 days prior — one that wasn't flagged up the chain because there's no formal process for surfacing deferred maintenance risk."
"The migration delay cascaded from a data quality issue that was identified in the discovery phase but not communicated to the engineering team until two weeks before the migration date. No one owned the cross-team data issue until it was a crisis."
What do we do differently next time?
This is the step that separates a useful AAR from a useless one. The first three questions generate insight. This question converts insight into action. The military requires this step to produce specific, assigned, time-bound changes — not vague intentions.
Good outputs from this question look like: "We will implement a formal maintenance deferral review that surfaces all deferred maintenance decisions to the commanding officer 10 days before any operation." That's specific, assigned, and actionable.
Bad outputs look like: "We should communicate better." "We need to be more proactive." "We should prioritize more carefully." None of these are wrong — but none of them are changeable in a specific way. "We should communicate better" doesn't tell you what to do differently on Monday.
The military standard is one change per AAR — one specific improvement that will be tracked and verified in the next execution cycle. More than one change gets diffused. If the AAR produces 12 action items, the team won't act on any of them. Pick the most important change and own it.
"For the next operation, the maintenance NCO will brief all deferred maintenance decisions to the commander's staff meeting 14 days prior to H-hour, with explicit risk assessment for each deferral."
"For the next launch, the data team will complete a data quality audit and surface all blocking issues to the project lead no later than 30 days before the migration date, with a formal sign-off from engineering on feasibility."
📌 Related: This AAR framework is directly connected to the military planning methodologies — running a proper AAR is what closes the loop on the planning cycle. What you plan, you execute, you review, and you improve. That's the full cycle.
How to Facilitate One in a Corporate Team
Running an AAR in a civilian context requires adaptation. Military AARs have cultural support — the whole organization runs them, leadership expects them, and there's an established norm that they're a learning tool, not a performance review. In a civilian team, you may be the only person who's ever done this. Here's how to introduce it without friction.
Timing and Frequency
Run AARs at the right moment — not too early (nothing has happened yet), not too late (details are forgotten). The military standard is within 24 hours of an event, while details are fresh. For corporate projects, this might mean: at the end of a sprint, within 48 hours of a launch, or within a week of a project milestone.
You don't need a major project to run an AAR. The format works for any event with a defined start and end — a client meeting, a sales pitch, a product launch, a team offsite. Small, frequent AARs build the habit. A single large AAR after a disaster is less effective than several smaller ones that catch issues early.
The Facilitator's Role
The facilitator's job is to hold the structure — not to contribute to the content. You ask the questions, you keep the sequence, you prevent early judgments about "why" before the "what" is fully established, and you push for specific action items in the fourth question. You don't give your own analysis until the AAR is complete, and even then, you frame it as "here's my observation" — not "here's the correct answer."
One bias to watch for: the "hindsight bias" that makes people identify the failure point in retrospect and then assume it was obvious. The military counter to this is asking "what information did we have at the time, and what information did we not have?" The gap between those two sets is the actual learning opportunity. Retreating to "it was obvious" after the fact is the enemy of honest analysis.
Note-Taking and Follow-Through
Designate a note-taker before the AAR starts. The note-taker captures: the planned vs. actual reconstruction, the root cause analysis, and — critically — the specific action items with owners and deadlines. This isn't a passive role; the note-taker should push back if the action items aren't specific enough.
The AAR is worthless if the action items disappear. Assign a specific owner to each action item and schedule a 15-minute check-in at the next team meeting to review the status. This is how you build organizational trust in the AAR process — by showing that it produces real change, not just notes that no one reads.
📌 Related: The facilitation skills in an AAR — structured questioning, root cause analysis, action item ownership — are exactly the leadership skills that translate directly to VP and director-level roles. Running a good AAR is a demonstration of organizational leadership that most civilian peers can't replicate.
Common Mistakes Civilians Make
After working with hundreds of transitioning military leaders who introduced AARs into civilian teams, the following mistakes come up repeatedly:
Running the AAR as a Complaint Session
The AAR is not a place to air grievances or express frustration. It's a structured analysis. The facilitator's job is to keep the conversation analytical rather than emotional. When someone says "what happened was completely unacceptable," the response isn't agreement — it's "walk me through the sequence of events that led to that moment." Facts first, evaluation second.
Skipping the "What Was Planned" Question
Almost every civilian retrospective starts with "what went wrong?" This skips the baseline. Without an explicit statement of what was planned, the discussion has no reference point — people disagree on what "should" have happened, and the analysis stays surface-level. Force the group to articulate the plan before moving forward.
Blame Instead of Analysis
When something goes wrong, the civilian instinct is to find a person who caused it. "Sarah didn't get the data to us on time, that's why we missed the deadline." This is a symptom explanation, not a root cause analysis. The real question is: what system allowed that to happen? If Sarah is the problem, the system failed by not catching it earlier. If the system is the problem, fixing it prevents the next Sarah situation too. Blame fixes one case; system analysis fixes all future cases.
Vague Action Items
"We should be more careful about scope." "We need to improve communication." "We should have better planning." These aren't action items — they're intentions. The AAR produces specific, assigned, time-bound changes. "The project lead will require a scope change log for any request received after the project kickoff meeting, with approval required from the executive sponsor before implementation" is an action item. "We should communicate better" is not.
Running the AAR Too Late
By the time a civilian retrospective runs — often weeks after an event — people have constructed narratives, memories have softened, and the reconstruction is more about interpretation than fact. The military runs AARs within hours of an event specifically because details fade fast. If you're running a retrospective two weeks after a project ends, the "what actually happened" reconstruction will be less accurate than it should be. Build AARs into the project rhythm so they run close to the event.
📌 Related: AAR mistakes compound in environments without strong leadership — which is exactly what senior military leaders are positioned to fix when they enter civilian organizations. Introducing proper AAR discipline is one of the most concrete ways to demonstrate leadership impact in the first 90 days.
Free Resource
Leadership Frameworks for Military-to-Civilian Transitions
AAR facilitation, MDMP, OODA loops, and the other frameworks that give military leaders a structural advantage in civilian organizations. Download the free guide.
When NOT to Run an AAR
The AAR isn't universal. There are situations where it's the wrong tool:
- During active crisis management: If the situation is still ongoing and people are in response mode, defer the AAR until the immediate threat is resolved. Running an AAR during a live incident creates a distraction from the response and contaminates the analysis with incomplete information.
- When the event is under investigation: If there's a formal HR, legal, or compliance investigation related to the event, do not run an AAR. The AAR's purpose is learning, not evidence gathering. The presence of a formal investigation changes the dynamics and risks contaminating the investigation or exposing the organization to liability.
- With a team that has no psychological safety: If the organizational culture punishes mistakes, running an AAR will backfire. People will game the analysis to protect themselves rather than contribute to honest learning. In these environments, the first step is building the safety, not running the AAR.
- For purely personal failures: The AAR is for events with multiple participants and systemic factors. A one-person mistake, unless it affected a team operation, is better addressed through coaching or direct feedback — not a group AAR that puts one person on the spot unnecessarily.
Timing note: The military runs AARs within hours of an event. In civilian environments, the equivalent is within 24-48 hours for fast-moving work (sprints, product releases) or within one week for slower-moving projects. Beyond a week, the reconstruction quality degrades significantly. Build AARs into your project rhythm rather than running them as one-off responses to problems.
The Three-Step AAR Application for Civilian Teams
Here's how to introduce the AAR into a team that has never run one properly:
| Phase | What to Do | What to Say in Interviews |
|---|---|---|
| Step 1 Introduce the Format as a Learning Tool |
Don't pitch it as "we're going to start doing AARs" — pitch it as "I ran a structured review process in the military and it consistently identified the highest-leverage improvements. I'd like to try it on our next project." Frame it around outcomes, not process. Run the first one on a low-stakes project where the team will see immediate value. | "I facilitate structured lessons-learned sessions after significant events — not blame sessions, but a specific four-question format that consistently surfaces root causes and produces assigned action items." |
| Step 2 Run It by the Numbers |
Use the four questions in sequence. Keep the discussion factual and analytical. Push for specific, assigned action items — not vague intentions. Assign a note-taker and follow up on the action items at the next team meeting. The follow-through is what builds organizational trust in the process. | "The last project we ran, I facilitated a 45-minute AAR within 24 hours of launch. We identified three specific process changes that we tracked and verified in the next cycle — all three were implemented and measurable." |
| Step 3 Make the Results Visible |
Track the AAR action items visibly — in the project tracker, in the team meeting notes, in the team channel. When the next similar event happens, open the previous AAR and review what was decided. The point isn't to blame people who didn't follow through — it's to demonstrate that the process works when it's followed. A team that sees results from AARs will keep running them. | "We run AARs on all significant launches — the action items are tracked in our project tracker and reviewed at each kickoff meeting. The last two cycles we identified and closed the highest-impact process gaps, both of which would have been invisible without the structured review." |
The civilian market is looking for exactly this: Leaders who can run structured learning cycles — who don't just fix problems when they appear, but build systematic processes that prevent the same problems from recurring. AARs are one of the most concrete, demonstrable examples of this capability. You're not running "another meeting" — you're running the mechanism that closes the gap between experience and improvement.
If you want to work through how to position this capability — and the other military leadership frameworks that compound in civilian organizations — the CommandShift Leadership Transition Blueprint covers AAR facilitation, the four questions, and how to introduce it into a civilian team without friction. The leadership positioning module specifically addresses how to demonstrate these skills in interviews and performance reviews.
Or start with a free 30-minute conversation: book your discovery call. No pitch, no pressure. Just a direct conversation about how the AAR framework fits into your specific transition and what it looks like in the role you're targeting.
— The CommandShift Team