On this page (8 sections)
A blameless retrospective asks what made a mistake possible, not who made it. The team assumes people acted reasonably with what they knew at the time, writes notes about situations rather than people, and leaves with actions that change the system. It doesn't mean nobody is accountable: actions still have owners, and people still own up to what they did.
The term comes from incident reviews, but it applies to any retro where something went wrong: a missed deadline, a bad handoff, a sprint that came apart. Below: what it means, ten examples of blaming notes rewritten, a worked example, and what to say when the room starts pointing fingers.
What "blameless" means, and what it doesn't
Etsy's John Allspaw wrote the post that popularized the term, Blameless PostMortems and a Just Culture, in 2012. Its core idea: people who contributed to a failure can give a detailed account of what they did, what they saw, what they expected and what they assumed, without fear of punishment. Google's SRE book describes it similarly, as finding contributing causes without indicting any person or team for bad behavior. Atlassian makes the same assumption of good intentions.
Allspaw uses a distinction from the book Behind Human Error: every failure has a first story and a second story.
Two ways to tell the same event
The first story
- Human error caused the failure.
- It's satisfying to say what people should have done.
- The fix is telling people to be more careful.
The second story
- The error is a symptom of weaknesses deeper in how the work is set up.
- Saying what they should have done doesn't explain why it made sense to them.
- The fix is finding and removing those weaknesses.
What it doesn't mean:
- It doesn't mean nobody says what happened. As Atlassian puts it, the point isn't that a review never identifies who made a mistake. The person involved often gives the most useful account.
- It doesn't mean no accountability. Allspaw is direct about this: engineers stay on the hook for helping make the company safer. In a retro, that's an action with an owner.
- It doesn't mean politeness. The SRE workbook compares a blaming write-up with a blameless one for the same incident, and the blameless one is the more detailed of the two.
You can't "fix" people, but you can fix systems and processes.
Why it matters
The reason isn't kindness. It's that blame stops the flow of information, which is exactly what a retro needs. Allspaw lays out the cycle.
What blame does to a team
- 1Someone contributes to a failure
- 2They're blamed or shamed
- 3Trust in management drops
- 4People stop sharing details
- 5Managers lose sight of how work happens
- 6The same failure happens again
- ↺ Blame cycle
The research on teams points the same way. Amy Edmondson's study of 51 work teams in a manufacturing company found that psychological safety, a shared belief that it's safe to take interpersonal risks, was associated with learning behavior, and that learning behavior linked it to team performance. DORA's research on software teams finds that a high-trust culture, where failure leads to inquiry rather than scapegoating, predicts software delivery and organizational performance. Those are correlations and they don't prove that a blameless retro will fix your team, but they do make the case for trying.
Blameless retrospective examples: ten notes rewritten
These are the kinds of notes that show up on real boards. We wrote these examples ourselves, and the names are made up. The second column keeps the facts and drops the verdict. The third is what a facilitator can ask next.
| The note says | Rewrite it as | Then ask |
|---|---|---|
| "Sam broke the deploy." | "The deploy ran without its checks because the flag was unset, and nothing on screen said so." | "What did the script show at that point?" |
| "QA should have caught this." | "The test plan didn't cover the new payment path." | "How did we decide what to test for this release?" |
| "The PO keeps changing scope." | "Three stories changed mid-sprint, and the team heard about them in standup." | "What happens now when a request arrives mid-sprint?" |
| "Nobody reads the runbook." | "The runbook's first step no longer works, so people ask in chat instead." | "What did people use instead, and why?" |
| "Priya was too slow on call." | "It took 40 minutes at 3 a.m. to find the right dashboard." | "What were you looking at in those 40 minutes?" |
| "Backend always blocks us." | "Two stories waited four days for an API change." | "Where did the request sit, and who could see it?" |
| "Design handed off late again." | "Designs arrived on day 6 of 10, after we'd estimated the work." | "What would need to be true for designs to arrive before planning?" |
| "Jun should have asked for help." | "A story was stuck for three days and the board didn't show it." | "What made asking for help feel expensive?" |
| "We got lazy about tests." | "We skipped integration tests to hit Friday's date." | "Who set that date, and what did we know then?" |
| "Management doesn't care." | "The launch date was set before we'd estimated the work." | "What could we bring to the next planning to change that?" |
Notice that the rewrites aren't softer. "Two stories waited four days" is harder to wave away than "backend always blocks us".
A worked example
This example is made up too. A team ships on a Friday, and checkout errors run for 40 minutes before anyone rolls back. By the retro, the top note reads: "Alex shipped without testing."
From the first story to something you can change
-
1
Get the facts in order
Start the timeline before the incident and work forward. Thursday: the release moved up a day. Friday 3 p.m.: Alex deploys. 3:20: support gets the first complaint. 3:40: rollback. Facts only.
-
2
Ask the person what they saw
"What were you expecting when you deployed?" Alex expected staging to have caught it, because staging had passed. "What were you looking at?" The staging test report, which showed green.
-
3
Find the second story
Staging doesn't use real payment settings, so the failure couldn't appear there. Nobody on the team knew that. Moving up the release also dropped the usual manual check. Deploying made sense given what Alex could see.
-
4
Ask how the team found out
Support noticed before monitoring did. There's no alert on failed checkouts, which explains the 20-minute gap.
-
5
Write actions for the system
"Marcus adds an alert on the checkout failure rate. Check: next retro." "Alex adds payment settings to staging, and documents what staging can
The first note would have produced one action: "test more carefully". The second story produced two that make the next failure less likely, whoever's deploying.
How to run a blameless retrospective
Set the rule before the first note. Many teams read Norm Kerth's Prime Directive at the start: whatever we discover, we believe everyone did the best job they could, given what they knew, their skills, the resources and the situation. Read it out loud, then say what it means in practice: "If you see a name in a note, I may ask to rewrite it."
Put the facts first. Build the timeline before anyone offers an explanation. As PagerDuty advises, work forward from before the event, so you see what people could see then instead of working back from the outcome.
Ask "what" and "how" questions. PagerDuty recommends these because "why did you…?" makes people justify themselves. Allspaw goes further in The Infinite Hows, citing prompts from Gary Klein and Sidney Dekker.
Questions that open things up
What people saw
What were you seeing at that point? What were you focused on? What wasn't visible?
What they expected
What were you expecting to happen? What did you assume was already true?
Why it made sense
What would a reasonable person have done with that information? What made the other option look worse?
The system
How did we find out? What made this easy to get wrong? Could the next person hit the same thing?
Interrupt blame gently. You'll need a line ready. "Let's look at what made that possible." Or: "Could anyone have made that same mistake? Then let's talk about what would stop it." PagerDuty's version is to treat the person as an unspecific responder: anyone could have made the same mistake.
Write actions for the system. Google's workbook says changing human behavior is less reliable than changing systems and processes, and its examples of weak actions include training people not to run unsafe commands. Give each action one owner, and a clear end state. The person involved often makes the best owner, as Allspaw notes, if they want to be.
Where blameless retros go wrong
| Failure | What it looks like | Fix |
|---|---|---|
| Blameless in name only | Nobody's named, but everyone knows who "someone" means | Talk about the conditions and leave out the "someone" entirely |
| Blaming the group | "The team should have known better" | That's still blame. Ask what the team could see |
| Hindsight | "It was obvious that would fail" | Ask what was known then. Allspaw says "wrong" only becomes visible after the outcome |
| A boss in the room | People give the safe version | The Agile Alliance notes that a manager's presence can inhibit discussion. Share the outcome afterward instead |
| "Be more careful" actions | Nothing about the system changes | Ask what would make it fail safely next time |
| A chain of whys | The trail ends at one person | Use 5 Whys on a process, not a person. Allspaw warns that "why" tends to turn into "who" |
Blameless retros in Retro Rabbit
Software won't make a team blameless, but it can remove a few obstacles.
- Notes without a name. Each person can switch off Show Name, and their notes show as Anonymous. It lowers the barrier for raising something awkward. On a small team, style and context can still give someone away, so it isn't a substitute for trust.
- Notes written at the time. A note added the day something happens tends to be more factual than one written two weeks later, when the story has already set. The board's open all sprint.
- The right format. The incident and postmortem templates move from facts to causes to prevention. The Incident Review format writes the timeline first, for that reason.
- Actions that survive. Each action gets one owner and comes back at the next retro's check-in. That's what accountability looks like in a blameless retro. CarrotIQ can draft one from your notes on Pro AI and during the trial, and it's up to you to check that it points at the system.
Try it on your next retro: the trial is 14 days with no card, and the 2-minute practice retro needs no signup. See pricing.
Related
Frequently asked questions
What is a blameless retrospective?
A retrospective that looks for what in the situation made a mistake possible, rather than who to punish for it. It assumes people acted reasonably given what they knew at the time. The idea comes from blameless postmortems, used by companies like Etsy and Google for reviewing outages.
What is an example of blameless language?
Instead of 'Sam broke the deploy', say 'The deploy ran without its checks because the flag was unset, and nothing on screen said so.' The second version describes what happened and points at something the team can change. This post has ten more examples.
Does blameless mean nobody is accountable?
No. John Allspaw's description of Etsy's process says engineers are still on the hook, in the sense of helping make the system safer. A blameless retro still names owners for its actions. What it removes is punishment for honestly describing what happened.
Can you name people in a blameless retrospective?
Yes, when it describes what happened rather than judging it, and when the person is comfortable with that. The person involved is usually the best source. Google's guidance warns against singling out individuals in root causes or action items, so keep names out of the causes and use them for owners.
What do you do when someone really did act recklessly?
Take it out of the retro. Repeated disregard for agreed rules, or anything involving harassment, belongs with a manager or HR, not on a team board. Blameless doesn't mean there are never consequences. It means a group retro isn't where you decide them.
What is the retrospective Prime Directive?
A statement from Norm Kerth's book Project Retrospectives, read at the start of many retros. It says that whatever the team finds, it believes everyone did the best job they could, given what they knew, their skills and abilities, the resources available and the situation at hand.
Run retros that actually lead to change
Your team adds notes during the sprint, CarrotIQ groups and summarizes them and suggests action items, and unfinished items carry into the next retro.
14-day free trial · No credit card