After-Action Review Tool for Engineering Teams

AAR Maker runs structured after-action reviews: the incident and post-launch review I used to facilitate in person, now software a team runs on its own cadence. Each review becomes a structured artefact the team keeps learning from, with the discipline a good facilitator brings to the room.

How a review runs

A review moves the way a good facilitator would take you: build the timeline, find the contributing factors, and map each one to where it actually lives, whether that’s strategy, structure, process, rewards, or people. It doesn’t stop at “someone missed a step.” It asks what made that step easy to miss. You come out with a short list of actions, each rated by relative urgency, so the team fixes the constraint instead of trying to fix everything at once.

Blameless by default

The tool holds the stance the method depends on. Most of what goes wrong is systemic, not personal (Deming), so “who missed it” becomes “what made this outcome likely.” When someone made a call that looks wrong in hindsight, it asks what made it seem right at the time (Dekker’s local rationality). Fair accountability, not blame: the only way people tell you what actually happened.

What the team keeps

Every review is a durable artefact, not a meeting that evaporates. Run enough of them and the tool reads across the whole set for the patterns a single review can’t see: the org-design gaps that keep generating the same incident. With your tools connected, it pulls the bug and timeline evidence in and writes the action items back out as tickets, so the follow-through has somewhere to land.

The retrieval architecture underneath is open source at github.com/chrisgagne/grounded-forge, and I’m glad to demo AAR Maker live.