# How to run a blameless post-mortem and why AI facilitation helps _A practical guide to understanding an incident, finding system causes and leaving with owned improvements rather than blame._ After an incident, everybody wants to learn and nobody wants to be placed in the dock. Unfortunately, a meeting can promise blamelessness while its questions, speaking order and selective memory suggest otherwise. The result is a polite timeline, one familiar action about documentation, and several lessons discussed privately afterwards. A useful post-mortem examines how the system made actions reasonable at the time. It separates causes from symptoms, preserves different perspectives and turns learning into owned changes. This 60-minute format uses Five Whys, Theme Sort and Who, What, When with 3 to 12 people. ## Prepare facts without writing the verdict Build a factual timeline before the session: what was observed, when alerts fired, which decisions were made, how service was restored and what customers experienced. Mark gaps and uncertainty plainly. Logs, tickets and messages are useful, but they do not explain what participants knew or believed at each moment. Invite people involved in detection, response, recovery and the relevant system design. Share the purpose and timeline in advance. Managers should be particularly careful not to open with their diagnosis. Psychological safety is not created by saying “no blame” once; it is created by asking about conditions, trade-offs and safeguards rather than who made the offending change. > We are here to understand why the actions made sense with the information and tools available, then improve the system around them. > — A practical opening agreement ## 1. Investigate one problem with Five Whys Use 30 minutes to investigate one concrete problem from the incident. Begin with an observable event, such as “checkout errors continued for 24 minutes after the first alert”. Ask why it happened, then ask why of each answer until the group reaches causes it can influence. Five is guidance, not a mystical number. Stop when another why would become guesswork. Check that every answer explains the previous one rather than restating it. “The responder missed the alert because they were not paying attention” closes inquiry around a person. “The alert appeared among 180 low-priority notifications and had the same presentation” exposes system conditions the team can change. Ask what evidence supports each link and record uncertainty. Collect answers from multiple participants at each round. The person who changed the code may understand one local choice; support, operations and another responder may reveal surrounding pressures. Do not force a branching incident into one elegant chain. Keep contributing factors that matter even when they do not fit the main line. ## 2. Organise contributing factors with Theme Sort Spend 15 minutes sorting all the causes, contributing factors and possible action areas from Five Whys. Group items by meaningful patterns such as alert design, deployment controls, ownership, documentation or recovery tooling. Use names that describe the system condition, not departments that can conveniently receive the blame. Invite participants to move items and challenge the draft themes. Keep significant outliers visible rather than pushing them into a weak category for the sake of a tidy board. The sort should help the team see where several facts point to the same improvement area and where one unusual factor still deserves attention. ## 3. Commit with Who, What, When Use the final 15 minutes to select the two or three themes most important to address. If discussion does not produce a clear choice, run a quick private vote. Then create one concrete action for each selected theme and record who owns it, what will happen and when it will happen or be reviewed. “Improve monitoring” is an aspiration. “Priya will test a severity-based checkout alert with the on-call group by 18 September” can be followed up. The owner need not perform every task, but they are responsible for moving it forward. Include a checkpoint and the evidence that would show whether the change helped. - Name the system condition the action addresses. - Choose an owner with the authority or support to progress it. - Write an observable action rather than a worthy intention. - Set a realistic date and a point for reviewing the result. ## Why AI changes the post-mortem Incident reviews place a heavy load on the facilitator. They must collect several accounts, notice when one confident narrative is taking over, timebox analysis without cutting off a quieter voice, and distinguish a cause from a restatement. They must synthesise carefully, guide transitions, organise themes, run a vote if priorities remain unclear and still reserve time for actionable outputs. ### A consistent process for ordinary incidents A serious incident involving damaged trust, regulatory exposure or employment concerns needs experienced human leadership and possibly an independent specialist. For routine service incidents, teams rarely have a consultant budget available. That does not make careful facilitation optional. It usually makes the engineering manager or incident lead do two jobs. Clarvelo is the AI facilitator, not an assistant producing tips for a human facilitator to apply. It runs each input round, keeps the Five Whys chain visible, synthesises contributing factors, guides Theme Sort, manages timeboxes and transitions, and turns selected themes into a Who, What, When table. Reliable process becomes available whenever the team needs to learn, not only when outside facilitation is affordable. ### Quieter evidence reaches the record Multi-participant collection matters particularly after an incident. Junior responders, support staff and people who joined late may hold evidence that complicates the first account. Structured rounds let them contribute before status or fluency sets the accepted story. Clarvelo can summarise connections while keeping uncertainty and important outliers visible for the group to correct. ### The incident lead gets to learn as well The diligent organiser often knows the incident best, yet conventional internal facilitation leaves them checking timers, copying notes and preparing the next board. When Clarvelo runs the room, they can explain what they knew, question the emerging causal chain, sort themes and accept ownership alongside everyone else. The team does not lose a key perspective to meeting administration. AI should not decide culpability, infer motives or turn uncertain evidence into a smooth story. The participants remain responsible for facts, interpretation and commitments. Clarvelo provides the process discipline that helps those judgements happen in the right order. ## A 60-minute Blameless Post-Mortem agenda - 30 minutes: investigate one concrete incident problem with Five Whys - 15 minutes: cluster causes and contributing factors with Theme Sort - 15 minutes: select priorities and create a Who, What, When action plan ## Turn the incident into system learning Clarvelo’s [Blameless Post-Mortem](/workshops/blameless-post-mortem) guides 3 to 12 people through Five Whys, Theme Sort and Who, What, When. [Start the AI-facilitated workshop](/workshops/blameless-post-mortem) when the facts are ready and the team needs to learn without assigning blame. --- Written by Joe Corcoran for [Clarvelo](https://clarvelo.com). Clarvelo helps teams run structured retros, decision jams, post-mortems, and other key decision-making workshops with an AI facilitator. Assigned outcomes are automatically exported to wherever your team works. [Read more on the Clarvelo blog](https://clarvelo.com/blog) or [try the live AI-facilitated workshops](https://clarvelo.com).