The After-Action Review That Turns a Bad Job Into a Lesson

Why this matters

A bad job is expensive whether or not you learn from it. The only thing you control is whether you get the lesson for that price or throw it away. An after-action review is the tool that extracts it: a short, structured conversation that turns "that was rough" into a specific change to how you work. Run right, it takes a slice of an afternoon and it stops the same job from happening again. Run wrong, it becomes a blame session that teaches everyone to keep their heads down next time.

What an after-action review is

An after-action review, or AAR, is a disciplined look back at a finished job built around four plain questions:

  1. What was supposed to happen?
  2. What actually happened?
  3. Why was there a difference?
  4. What do we change so the gap does not repeat?

That is the whole spine. The power is in doing it honestly and finishing at question four with a real change, not a shrug. (For deciding whether a given job even earns a review, see related: Run a Post-Mortem on That Job or Move On.)

Do it fast, while it is fresh

The value of an AAR decays by the day. Details that are obvious the afternoon of the job, who said what, which part was wrong, where the time went, blur into "it was a mess" within a week. Run it within a day or two. A quick review while the memory is sharp beats a thorough one a month later when everyone is reconstructing.

Question 1: what was supposed to happen

Start with the plan, out loud, before you touch what went wrong. What was the job, the scope, the timeline, the expected outcome? This matters because half of "bad jobs" are really expectation gaps: the plan itself was wrong, or nobody shared it. Naming the intended result first gives you something concrete to measure the mess against.

Question 2: what actually happened

Now the facts, in order, without interpretation yet. Walk the job start to finish. What happened, when, in what sequence. Keep people to observations, not theories or blame. "The part was not on the truck" is a fact. "Purchasing never does their job" is a theory dressed as a fact. Get the timeline clean before anyone explains it.

Question 3: why was there a difference

This is where the review earns its keep, and where it most often goes wrong. The honest answer is almost never a name. Push each gap back to its condition:

  • The part was missing. Why? It was not on the work order. Why? Intake did not capture the equipment, so nobody knew it was needed.
  • The job ran long. Why? It was scoped from a phone description that missed half the work.

Keep asking why until you reach something you can change (this is the Five Whys applied to a whole job, see related: The Five Whys and How to Actually Use It). And hold the room blameless out loud, "we are after what let this happen, not who," or the answers bend to self-protection and you fix the wrong thing.

Question 4: what do we change

An AAR that ends in understanding changes nothing. The output is a specific, owned change:

  • Name the change. A new checklist line, a captured field at intake, a changed handoff, a script. Concrete enough that a new hire would follow it.
  • Give it an owner. One person, not "the team." Unowned changes evaporate.
  • Set a check. How you will know in thirty days whether it held.

One or two real changes beat a list of ten good intentions. Pick the change that removes the biggest cause and make it stick.

Keep it blameless or watch it die

The fastest way to kill the AAR habit is to let one turn into a public flogging. Do that once and the next review is all defense and no truth. Protect the tone hard:

  • Ask the people who were there, not an audience. A review with six spectators and one person on the hot seat is theater.
  • Include the win. Ask what went right and what almost went wrong but did not, the near-miss is the cheapest lesson in the room and the first one forgotten.
  • End on the system, not the person. The last thing said should be the change and its owner, never a warning.

Watch the pattern across reviews

One AAR tells you about one job. Kept together, they tell you what keeps happening. If the same cause shows up across three reviews, a handoff that keeps dropping, a service line that keeps blowing scope, that is a structural problem, not three bad days. Keep your reviews somewhere you can actually find them, and read them as a set once in a while.

References

  • Trade-standard practice for after-action and post-incident review
  • See related: Run a Post-Mortem on That Job or Move On; The Five Whys and How to Actually Use It; Getting to Root Cause Instead of Blaming the Person
  • Plan-Do-Check-Act improvement cycle, standard continuous-improvement method