Your Debriefs Change Nothing

A problem you fixed last quarter is back, and the team is solving it again from scratch. Somewhere there was a debrief, and it clearly didn't take. This is the normal result of how most teams close out work: they finish, they move on, and the lesson inside the project is never turned into a change. The same issue returns next quarter, and the team relearns it the hard way. An after action review is how you fix that, and here's the whole method, made simple enough to run on a small team.

The debrief that changed nothing

You've probably held the debrief already, the one some people call a post-mortem. It turned into blame, or into storytelling, and nothing about how the team works actually changed. The takeaways were things like "communicate better" and "plan earlier," too vague for anyone to act on. When reflection does happen, it often happens informally, and it turns into a search for who to blame, which teaches the team to say less next time.

So the same issue shows up again, a mistake you fixed once returns, and the team learns it a second time. Not because anyone is careless, but because the review never ended in a change, and the lesson never reached the people who needed it.

A good discussion isn't a change

Here's the idea the whole method turns on. A good discussion feels productive, and on its own it changes nothing. A project only teaches the team something when the review ends in a change the team actually makes and that change reaches the people it affects. Insight is the feeling of understanding something. A change is a specific thing you do differently. The two are easy to confuse, and confusing them is why so many thoughtful debriefs lead nowhere.

An after action review exists to close that distance on purpose. It's built so the conversation has to end somewhere real: with at least one change you can see.

What an after action review is, and isn't

An after action review is a structured, blameless review you run after something finishes — a project, a client engagement, a missed goal, or a big decision. It's a structured way to reflect on an outcome and improve how the team works, focused on the system and the process, and run on a clear agenda.

It isn't a post-mortem in the finger-pointing sense, a performance review, or a session to work out who failed. And it isn't reflection for its own sake, because it always ends in a change and a shared lesson. That last part is the whole point. An AAR that ends without a change was just a conversation.

The 90-minute agenda, in order

The review works because it follows the same order every time, and that structure is also what keeps it safe: when everyone knows the same questions are coming and the review stays on the system, people can speak plainly. In about ninety minutes, the team goes through:

• What we expected — the goal, the assumptions, and what success looked like going in.

• What actually happened — facts and observable outcomes only, walked through as a timeline.

• The signals we saw — the early signs someone noticed, and when the team first sensed something was off.

• Where the gap was — in the process, communication, escalation, decisions, or assumptions, looking at the system rather than the person.

• What we learned, and what to keep — the patterns worth carrying forward, and what went well.

• What we'll change, and who owns it — one to three observable changes, each with a named owner and a date.

• Close, document, and share — confirm what's changing, where it's recorded, and which teams need to hear it.

Same questions, same order, every time. The predictability is what lets people be honest.

Two roles, kept separate

An AAR runs on two roles, kept with different people. A facilitator runs the agenda, keeps it blameless, and keeps it on the system and to time. A scribe captures the review as it happens — the decisions, the changes, and the owners. It helps to name one more person as the steward, who keeps every review in one shared place so they stay findable over time. Splitting the roles keeps the person running the conversation free to run it, and makes sure nothing gets lost.

Make the change something you'd actually see

The one rule is that you leave with at least one change you can see, and most reviews fail right here, because the change they name is too soft to do anything. "Communicate better," "be more careful," and "plan earlier" all sound reasonable, and none of them tells anyone what to do differently on Monday.

A real change is observable, like "escalate a timeline risk within twenty-four hours" or "write down cross-functional decisions the same day." The test is simple: would you actually see it happening. Keep it to one to three changes, each with a named owner and a date, because too many changes at once means none of them sticks.

Keep it blameless, and make it reach other teams

People are honest in a review only when it's safe, and the safety comes from the structure itself: the same questions every time, kept on the system, let people speak without it becoming personal. As you run it, deal in observable facts, interrupt blame and storytelling when they start, and ask what part of the process or the handoff contributed rather than who was at fault.

Then make sure the lesson doesn't stay with the people who were there. The scribe writes it up, it goes to everyone who attended, and the bigger lessons get sent to the other teams they affect, sometimes in a short session when a lesson touches several teams. A lesson only helps the business if the next team facing the same thing can find it.

Start this week

You don't need a big program to begin. Pick the last thing your team finished, name a facilitator and a scribe, and run a review off the agenda. Go through what you expected, what happened, the signals, and the gap, and leave with one change that's owned, written down, and shared. That single review is the habit starting.

Where the After Action Review fits

The After Action Review is one of the standards inside the Leadership Operating Flywheel, the way the whole business aligns, grows capacity, and turns effort into growth. It's how the team learns from the work and improves over time. It works best alongside the others: a team that shares one direction, raises problems early, and holds each other accountable for the changes it commits to. Each standard strengthens the others, and together they're what lets the team run without you in every decision.

Download the free After Action Review Agenda Template

We put the whole method into the After Action Review Agenda Template. It has the ninety-minute agenda in order, the two roles and the steward, a one-page worksheet the scribe fills in as you go, weak-versus-strong examples for writing an observable change, and the steps for documenting and sharing it after.

→ Download the free template: loyaltyops.com/after-action-review

If you want to build the review habit alongside a room of other leaders working through the same thing, that's part of the work inside the Leaders Mastermind.

FAQ

What is an after action review?

An after action review is a structured, blameless review you run after something finishes, to turn the experience into at least one change the team actually makes. In about ninety minutes, the team goes through what you expected, what happened, the early signals, and where the gap was, and ends with a specific change that has an owner and a date.

How is an after action review different from a post-mortem?

An AAR is a blameless review focused on the system and the process, and it always ends in a change and a shared lesson. Many post-mortems turn into finding who failed or into storytelling that changes nothing. The AAR's structure and its one rule — leave with a change you can see — are what make it different.

How do you run an after action review?

Name a facilitator and a scribe, book about ninety minutes, and follow a fixed agenda: what we expected, what happened, the signals we saw, where the gap was, what we learned, what we'll change and who owns it, then close, document, and share. Keep it on the system, not the person.

What makes a change "observable"?

You'd actually see it happening. "Communicate better" isn't observable; "escalate a timeline risk within twenty-four hours" is. Observable changes can be checked and practiced, which is why an AAR insists on them and caps the list at one to three so each one sticks.

Why share the results with other teams?

Because a lesson that stays with the people who were in the review only helps them. Written down and sent to the teams it affects, it stops the same problem from reappearing elsewhere. Keeping every review in one shared place means the next team facing the same thing is one search away from the answer.