Core Primitive
What happened what did you expect what can you learn.
The project that no one debriefed
A product team at a mid-size software company spent four months building a feature that their largest enterprise client had requested. They shipped on time. The client implemented it. Three months later, the client churned anyway — the feature they had asked for was not the feature they needed. The gap between the request and the underlying problem had been visible in the original requirements conversation, but no one had flagged it.
The team moved on to the next project. Their retrospective covered the sprint mechanics — velocity, story point accuracy, deployment process. No one examined the actual failure: the decision to build what was requested rather than what was needed. No one asked why the requirements conversation had missed the deeper problem. No one documented the signal that had been visible but not acted upon.
Eighteen months later, a different team in the same company repeated the exact same mistake with a different client. Same pattern — client requests a specific feature, team builds it faithfully, client churns because the request was a symptom, not the disease. The lesson was available. It had simply never been extracted.
This is what happens when you do not review specific events with the deliberate intent to learn from them. The experience happens, the emotions fade, the team disperses, and the institutional knowledge — the hard-won, expensive knowledge that only emerges from things going wrong — evaporates. The cadence-based reviews you built in the previous lessons (daily, weekly, monthly, quarterly, annual) catch patterns over time. But they are not designed to dissect a specific event in the detail required to extract its full teaching. For that, you need a different tool.
You need an after-action review.
The AAR: a framework forged in high stakes
The after-action review originated in the U.S. Army in the 1970s, developed at the National Training Center at Fort Irwin, California. The context matters: the Army needed a way to help units learn from training exercises quickly enough to improve before the next engagement. Traditional debriefs — senior officers telling junior officers what they did wrong — were not working. They produced defensiveness, not learning. They captured the commander's perspective, not the unit's collective understanding.
The AAR was designed to solve this by restructuring the debrief around four questions, asked in order:
1. What was supposed to happen? Before you can evaluate an event, you need to establish the baseline. What was the plan? What were the objectives? What did you expect? This question forces you to reconstruct your pre-event mental model — the set of assumptions and predictions that guided your actions. It is harder than it sounds, because by the time you are reviewing the event, your memory of what you expected has already been contaminated by what actually occurred.
2. What actually happened? Not what you think happened. Not what you wish happened. What happened, in sequence, with as much factual detail as you can reconstruct. The Army insists on multiple perspectives at this stage — each participant describes what they observed from their position, and the group assembles a shared timeline. For a personal AAR, you are reconstructing your own timeline, but the discipline is the same: facts first, interpretation later.
3. Why was there a difference? This is the analytical core of the AAR. Why did reality diverge from the plan? The divergence might be negative (it went worse than expected) or positive (it went better than expected). Both directions matter, because both contain information about the accuracy of your mental model. This question requires you to distinguish between root causes and proximate causes — between the immediate trigger of the divergence and the deeper systemic conditions that allowed the trigger to fire.
4. What can we learn? Not "what should we do differently" — though that is part of it — but "what did this event teach us about how the world works, how our plans interact with reality, and how our processes produce or fail to produce the outcomes we intend?" This question is explicitly forward-looking. It translates the analysis from steps two and three into principles, procedures, or mental models that can be applied to future events.
The Army's results with the AAR framework were dramatic. Units that conducted AARs after training exercises showed measurably faster improvement than units that did not. The framework spread beyond the military to NASA (post-flight debriefs), to the National Transportation Safety Board (incident investigations), to emergency medicine (morbidity and mortality conferences), and eventually to the technology industry (post-mortems and retrospectives). Every high-reliability organization in the world uses some version of this four-question structure, because the structure works. It constrains the review tightly enough to be actionable and broadly enough to capture systemic lessons.
Why events demand their own reviews
You already have cadence-based reviews from the previous lessons in this phase. A weekly review catches patterns across the week. A monthly review identifies trends. A quarterly review examines strategic alignment. Why do you need a separate, event-triggered review?
Because cadence-based reviews are summaries, and summaries lose detail.
When you review your week, you are aggregating across dozens of events, conversations, and decisions. The review captures the general shape of the week — what went well overall, what themes emerged, what your energy patterns looked like. It does not — and cannot — reconstruct the specific sequence of decisions that led to a particular outcome on Tuesday afternoon. It does not capture the moment when you noticed a signal, chose to ignore it, and watched the consequences unfold over the next three days. That level of detail requires a dedicated review, conducted close enough to the event that your memory is still fresh and detailed enough to be useful.
NASA understood this distinction when they designed their post-flight debrief process. Astronauts returning from the International Space Station participate in both general mission reviews (cadence-based, covering the entire six-month mission) and specific event debriefs (triggered by anomalies, experiments, or EVAs that produced unexpected results). The mission review says: "Overall, the mission achieved 94% of its objectives." The event debrief says: "During the EVA on day 47, the tether management procedure produced a near-miss when the secondary attachment point failed. Here is why, and here is what we change."
Both reviews are essential. Neither can replace the other. The cadence review gives you the forest. The event review gives you the tree — the specific, granular, causally detailed understanding that only comes from examining one event thoroughly.
Hindsight bias: the enemy inside the review
There is a cognitive trap waiting for you inside every after-action review, and Daniel Kahneman spent decades documenting it. He called it hindsight bias — the tendency, after learning the outcome, to believe that the outcome was predictable all along.
Once you know that the product feature did not prevent the client from churning, it feels obvious that the original requirements conversation missed the real problem. Once you know that the rollback script failed, it feels obvious that the script should have been tested. The outcome rewrites your memory of the pre-event state. What felt uncertain and ambiguous at the time — when you were making decisions with incomplete information — now feels clear and inevitable. "I should have known" is the signature phrase of hindsight bias.
This is why the first question of the AAR framework — "What was supposed to happen?" — is so important, and why it must be answered honestly, not retrospectively. The question forces you to reconstruct your actual mental model before the event, not the revised mental model that hindsight has already installed. What did you actually believe would happen? What information did you actually have? What alternatives did you actually consider?
Kahneman's research shows that hindsight bias is nearly impossible to eliminate through willpower alone. You cannot simply decide to remember accurately. But you can mitigate it structurally. Gary Klein, the psychologist who pioneered naturalistic decision-making research, recommends a specific technique: before analyzing the event, write down what you remember believing before it happened. Write it before you start the analysis. Write it before you look at the outcome data. The act of explicitly reconstructing your prior beliefs — even imperfectly — creates an anchor that resists the pull of hindsight.
Klein's work on pre-mortems — imagining a project has already failed and working backward to explain why — is the forward-looking complement to the AAR. The pre-mortem inoculates against overconfidence before the event. The AAR extracts learning after the event. Together, they form a complete learning cycle around any significant undertaking.
Blameless review: the cultural prerequisite
In 2012, John Allspaw, then the CTO of Etsy, published a widely circulated article on blameless post-mortems that changed how the technology industry approaches event reviews. His argument was simple: if people are punished for mistakes, they will hide mistakes. If they hide mistakes, the organization cannot learn from them. Therefore, the only way to maintain a learning culture is to explicitly decouple the review process from the punishment process.
Google's Site Reliability Engineering team formalized this principle. In the Google SRE handbook, they describe blameless post-mortems as a core practice: "We aim to identify the contributing causes of an incident without indicting any individual or team for bad or inappropriate behavior." The focus is on systems, not people. The question is never "Who screwed up?" The question is always "What conditions in our systems, processes, and information flows allowed this outcome to occur?"
This principle applies to personal AARs with equal force, even though there is only one person in the room. When you review your own events, the temptation is to assign blame to yourself — "I was careless," "I did not prepare enough," "I should have known better." These judgments feel like accountability, but they are actually the opposite. They are character attributions that short-circuit systemic analysis.
"I was careless" is not a lesson. It is a verdict. It tells you nothing about what to change. "My review checklist did not include a step for validating the rollback procedure against the current schema" is a lesson. It tells you exactly what to change, and the change is procedural, not characterological. You do not need to become a better person. You need to update a checklist.
The blameless frame is not about letting yourself off the hook. It is about redirecting your analytical energy from self-judgment (which produces guilt) to system analysis (which produces improvement). Every time you catch yourself framing the AAR in terms of personal failure — "I was lazy," "I didn't try hard enough," "I'm not good at this" — reframe the question: "What process, checklist, decision rule, or information source would have produced a better outcome, regardless of my effort level on that particular day?"
How to run a personal AAR
The Army conducts AARs with facilitators, multiple participants, and structured timelines. You are one person reviewing your own events. The framework scales down cleanly, but it requires discipline in the absence of external structure.
Timing. Conduct the AAR within 48 hours of the event's conclusion, while your memory is still granular. After a week, you will remember the outcome and your feelings, but you will have lost the sequence of micro-decisions that produced the outcome. Those micro-decisions are where the lessons live.
Duration. Thirty to sixty minutes for most events. A major project or life event might warrant two hours across two sessions. Do not rush — the value is in the depth of analysis, not the speed.
Format. Write it down. Do not conduct your AAR as a mental exercise during your commute. The act of writing forces precision. Vague thoughts become specific claims when they must be articulated in sentences. Use the four-question structure as literal headings. Answer each question fully before moving to the next.
The four passes:
Pass 1: What was supposed to happen. Write your pre-event plan, expectations, or assumptions. If you documented a plan before the event (a project brief, a preparation outline, notes to yourself), reference it directly. If you did not, reconstruct from memory — and note where your memory feels uncertain. This uncertainty is itself a data point. It may indicate that you began the event without a clear enough plan to evaluate against, which is a finding for the AAR.
Pass 2: What actually happened. Write the timeline. Be chronological. Include key decision points — moments where you chose one path over another. Include surprises — moments where reality diverged from your expectations. Include emotional data — moments where you felt confident, anxious, frustrated, or relieved. Emotions are signals about the gap between your mental model and reality; they belong in the factual record.
Pass 3: Why the difference. For each significant divergence between your plan and reality, identify contributing causes. Use the "five whys" technique: ask why the divergence occurred, then ask why that cause existed, then ask why that condition was present, continuing until you reach a cause that is actionable. Most people stop at the first why. The first why gives you the proximate cause — the thing that went wrong. The third or fourth why gives you the systemic cause — the condition in your processes, habits, or infrastructure that made the proximate cause possible.
Pass 4: What you learn. Translate each root cause into a concrete change. Not a resolution ("I will be more careful") but a procedure ("I will add a rollback validation step to my launch checklist," "I will schedule a dry-run conversation before any high-stakes presentation," "I will create a decision journal entry before committing to any project with more than two weeks of scope"). Each lesson should be implementable within your existing systems — your task manager, your checklists, your review templates, your decision protocols.
Close the loop. An AAR is not complete until at least one concrete change has been implemented in your systems. Not planned. Not intended. Implemented. Update the checklist. Create the trigger. Modify the template. The AAR's value is zero until the behavioral change is real.
AARs for successes, not just failures
The most underutilized version of the AAR is the success review. When something goes well — a presentation lands, a project ships cleanly, a difficult conversation resolves better than expected — the instinct is to feel relief and move on. The event succeeded. What is there to review?
Everything.
A success that you do not understand is luck. A success that you can explain is a repeatable process. The AAR for a successful event asks the same four questions, but the analytical focus shifts from "What went wrong?" to "What went right, and was it deliberate?"
When your presentation landed well, was it because you prepared thoroughly, or because the audience happened to be in a receptive mood? When the project shipped cleanly, was it because your planning process was rigorous, or because the scope was simpler than usual? When the conversation resolved well, was it because you applied a specific communication technique, or because the other person was in an unusually good frame of mind?
The distinction matters because only deliberate successes can be reproduced. If your success was the result of a specific action you took — a preparation ritual, a planning framework, a communication approach — then you can codify that action and apply it to future events. If your success was the result of favorable conditions that you did not control, then you learned something different: you learned that your mental model overestimates your agency in this domain, and that you should prepare contingency plans for the scenarios where conditions are not as favorable.
Agile retrospectives, formalized by Esther Derby and Diana Larsen in their 2006 book "Agile Retrospectives: Making Good Teams Great," build this principle into the structure of every review. The standard retrospective begins with "What went well?" before it addresses "What did not go well?" and "What will we change?" Starting with success is not optimism for its own sake. It is the systematic capture of positive practices that might otherwise go unexamined and unrepeated.
The spectrum of event severity
Not every event deserves a sixty-minute AAR. Part of building an effective review practice is calibrating the depth of your review to the significance of the event.
Micro-AAR (five minutes). A brief mental or written check after any event of moderate significance — a meeting, a conversation, a task completion. Three sentences: What was the goal? What happened? What is one thing to adjust? You can run a micro-AAR in the margin of your notebook or as a quick note in your daily review.
Standard AAR (thirty to sixty minutes). The full four-question framework for events of real significance — project milestones, presentations, decisions with visible consequences, conflicts, significant conversations. This is the core practice.
Deep AAR (two or more hours, possibly across multiple sessions). For major life or career events — the end of a significant project, a job transition, a relationship milestone, a health event, a financial decision with long-term consequences. A deep AAR may involve gathering external data (emails, documents, calendars) to reconstruct the timeline accurately. It may involve soliciting perspectives from others who were involved. It produces not just tactical adjustments but strategic revisions to your mental models and decision frameworks.
The NTSB (National Transportation Safety Board) operates on this spectrum. A minor aviation incident gets a brief report. A major accident gets a multi-year investigation with hundreds of pages of analysis. The depth matches the stakes and the learning potential. Your personal AAR practice should follow the same principle.
Your Third Brain: AI as AAR partner
AI is remarkably well-suited to supporting the after-action review process, because it can serve as the structured thinking partner that the Army's AAR facilitator provides — someone who asks the right questions, pushes for deeper analysis, and resists the pull of hindsight bias.
Timeline reconstruction. Describe the event to the AI and ask it to help you build a structured timeline. The AI will ask clarifying questions — "When did you first notice X?" "What was happening between Tuesday and Thursday?" — that force you to fill in gaps your memory is already smoothing over. The resulting timeline is more detailed and more accurate than what you would produce alone.
Root cause analysis. After you describe the divergence between plan and reality, ask the AI to walk you through a five-whys analysis. The AI is excellent at pushing past the first and second "why" to reach systemic causes. When you say "The rollback script failed," the AI asks "Why was the script not tested?" When you say "I did not have time," the AI asks "Why was rollback testing not part of the standard launch process?" Each level of "why" peels back another layer of systemic assumption.
Hindsight bias check. Before you begin your analysis, tell the AI what happened and ask it to generate two or three alternative outcomes that were equally plausible given the information available before the event. This exercise — explicitly imagining how the event could have gone differently — counteracts the feeling that the actual outcome was inevitable. If the AI can construct a credible scenario where the project succeeded despite the same conditions, your hindsight-driven certainty that failure was "obvious" is immediately weakened.
Action item generation. After completing the four questions, ask the AI to review your lessons and propose concrete, implementable changes — checklist items, trigger conditions, process modifications. The AI can often identify procedural changes that are more specific and more implementable than the general resolutions people tend to generate on their own. "Be more careful" becomes "Add a line item to the pre-launch checklist that reads: validate rollback procedure against current schema within 24 hours of deployment."
Pattern recognition across multiple AARs. If you maintain a log of your AARs (and you should), periodically share a batch with the AI and ask it to identify recurring themes. Patterns that appear across multiple unrelated events point to deep systemic issues in your processes or mental models — the kind of issues that no single AAR can fully reveal.
The bridge to better questions
The four-question AAR framework is powerful, but it is a scaffold, not a ceiling. "What was supposed to happen?" and "What actually happened?" are good starting questions, but they are not the only questions that produce learning. Some events call for different angles: "What assumptions was I making that I did not realize I was making?" "What information was available that I did not seek out?" "Where in this event did my emotional state override my analytical judgment?"
The next lesson examines the specific questions that make any review — whether cadence-based or event-triggered — genuinely productive. The AAR gives you the structure. The right questions give you the depth.
But the structure comes first. Without the four-question framework — without the discipline of reconstructing your expectations, documenting what happened, analyzing the divergence, and translating the analysis into concrete change — questions float free. They become rumination rather than reflection. They circle without landing.
Start with the structure. Conduct your first personal AAR this week. Pick an event that mattered — one where the outcome surprised you, disappointed you, or delighted you in ways you do not fully understand. Apply the four questions. Write it down. Implement one change.
The event already happened. You cannot alter it. But you can extract from it every lesson it has to teach — and that extraction is the difference between experience and wisdom.
Sources:
- U.S. Army. (1993). A Leader's Guide to After-Action Reviews. Training Circular 25-20. Department of the Army.
- Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
- Klein, G. (2007). "Performing a Project Premortem." Harvard Business Review, 85(9), 18-19.
- Allspaw, J. (2012). "Blameless PostMortems and a Just Culture." Etsy Code as Craft Blog.
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media.
- Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
- Klein, G. (1998). Sources of Power: How People Make Decisions. MIT Press.
- National Transportation Safety Board. "NTSB Investigations." ntsb.gov.
- Morrison, J. E., & Meliza, L. L. (1999). Foundations of the After Action Review Process. U.S. Army Research Institute Special Report 42.
Frequently Asked Questions