After-Action Review: Learning From a Bad Job
Why this matters
Bad jobs happen at every shop: a callback, a blown estimate, an upset customer, a safety near-miss. The shops that stay small repeat them. The shops that grow turn each one into a fix so it does not happen again. An after-action review (a short, structured look back at what happened and why) is how you convert a costly mistake into a permanent improvement. The catch is that it only works if it stays blameless. The instant it becomes a search for who to punish, people hide problems, and you lose the very information you need to fix anything.
Step 1: Decide what deserves a review
You cannot review every job, and you should not try. Run an after-action review when the stakes or the lesson justify it:
- A callback or a job that had to be redone.
- An estimate that missed badly, over or under.
- A customer complaint or a job that nearly lost the customer.
- A safety incident or close call. These always get reviewed, no exceptions.
- A job that went unusually well, occasionally, so you learn what to repeat, not only what to avoid.
Small, one-off slips do not need a formal review. Patterns and expensive mistakes do.
Step 2: Get the right people in the room, fast
Hold the review while the job is fresh, within a few days, and keep it to the people who were actually involved plus whoever owns the fix. This is not a group event. Dragging the whole crew through a post-mortem of a job they were not on wastes their time and embarrasses the people who were.
- Keep it short. Twenty to thirty minutes is plenty.
- Make it private. The people involved should be able to speak plainly without an audience.
- Set the tone in the first sentence: we are here to fix the process, not to find a neck.
Step 3: Establish the facts before the opinions
Start with what actually happened, in order, agreed by everyone present. Facts first, judgments later. A clean way to structure it is four questions:
- What was supposed to happen? The plan, the estimate, the expected outcome.
- What actually happened? The real sequence, plainly stated.
- Where did the two diverge? The specific point things went off.
- Why? The honest cause at that point.
Getting agreement on the facts before anyone offers an opinion prevents the review from turning into a blame argument. People can disagree about fault, but they can usually agree on the timeline.
Step 4: Dig for the real cause, not the first one
The first answer is almost never the root cause. "The tech installed it wrong" is a symptom. Keep asking why until you hit something a process change can actually fix. A simple discipline: ask "why" a few times in a row.
- The unit failed. Why? It was installed wrong. Why? The tech had not done that type before. Why? Nobody checked the assignment against skill before dispatch.
Now you have a real cause (dispatch did not match the job to the skill) and a fix that prevents a whole class of future failures, not just this one. Stop at the symptom and you fix nothing.
Step 5: Keep it blameless on purpose
This is the step that makes or breaks after-action reviews. Most failures trace to a process or a setup, not a bad person. When you treat them as character flaws, three things happen: people get defensive, they stop telling you the truth, and the actual cause stays hidden. Hold two ideas at once:
- The process is on trial, not the person. Assume a competent person doing their honest best, and ask what about the system let this happen.
- Genuine negligence is still addressed, but privately and separately, never in the review. Mixing discipline into the review poisons it for everyone watching.
A crew that has learned reviews are safe will bring you the near-misses and the small problems early, which is worth more than any single fix.
Step 6: Turn the cause into a specific change
A review that ends in "we will be more careful" changed nothing. Every review produces at least one concrete action with an owner and a by-when:
- Add a step to a checklist. Change a dispatch rule. Add a verification before sign-off. Update a training.
- Name who owns the change and when it is done.
- Write it down where it will be acted on, not buried in a notebook.
If the cause was a missing or unclear process, the fix is usually to write that process down so it survives past memory.
Step 7: Close the loop and check it stuck
The improvement is not real until it is in place and confirmed. A while later, check: did the change happen, and did it work? If the same kind of job is going smoothly now, the review did its job. If the problem recurs, the fix missed the real cause, so review again and go deeper. Tracking whether your fixes actually hold is what separates a shop that learns from one that just holds meetings.
The mindset
A bad job already cost you the money. The only question left is whether you also get the lesson. Shops that treat mistakes as expensive tuition, paid once, and pocket the learning, get steadily better. Shops that treat them as someone's fault pay the same tuition over and over.
References
- See related: Running an Effective Team Huddle
- See related: Process Not Followed: Retrain vs Enforce vs Revise Decision Tree
- Trade-standard practice for continuous improvement and incident review