Keeping a postmortem blameless after an admission
Whether you can protect blameless culture under pressure.
Acknowledge the courage, redirect from who to why the system allowed it, ask what guardrails were missing.
What's really being asked
Whether you genuinely understand blameless postmortems or just recite the slogan. The interviewer is probing how you behave at the exact moment blame is tempting, because that moment defines whether your culture is real.
The full answer
Start by acknowledging the engineer's transparency, because admitting your change triggered an outage takes courage and you want to reinforce that behavior, not punish it. Then immediately redirect the conversation from the person to the system. The right questions are: what made it possible for this change to reach production and cause harm? Why did code review, automated tests, canary analysis, or monitoring not catch it before or during rollout? What feedback was missing that would have made the danger obvious? The premise is that competent people make reasonable decisions given the information and tools available, so a single person triggering a major outage points to missing guardrails, not a bad actor. Action items target those systemic gaps.
The mistakes people make
Recording human error as the root cause, which ends the analysis prematurely. Praising honesty in words while the meeting tone or follow-up still singles out the engineer, which is worse than overt blame because it teaches people that admitting mistakes is unsafe.
What usually comes next
What if leadership demands accountability and wants a name? How do you handle repeated mistakes by the same person without becoming punitive? How do you measure whether your postmortem culture is actually blameless?
A concrete example
The engineer pushed a config change that took down a region. Instead of stopping at that, the postmortem asks why a single config change could affect a whole region with no canary, no validation, and no staged rollout, producing action items to add config canarying and progressive deployment that protect every future change.
Interview question
After an engineer admits their change caused the outage, which facilitator move best preserves blamelessness?
- a.Skip the topic entirely so no one feels uncomfortable
- b.Record 'human error by the engineer' as the root cause and close the item
- c.Privately note the engineer for a performance discussion later
- d.Thank them, then ask why the system let that change reach production undetectedCorrect
Why? this is the answer
Redirecting from the person to the systemic gaps that allowed and failed to catch the change is the core of blameless analysis. Logging 'human error' ends investigation early, and quiet performance flags destroy the trust that makes people admit mistakes.
Just read this? Test yourself on what you have been reading.
Read the original → sre.google
- #sre
- #postmortem
- #blameless-culture
- #incident
- #leadership
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on sre — each one lists the topics its interview covers.
See open roles