Etsy & the Origin of Blameless Postmortems

This is a real, named company's story, and it sticks closely to what one person actually published: John Allspaw's 2012 essay on Etsy's engineering blog, "Blameless PostMortems and a Just Culture." That single post — plus the safety-science literature it draws on and the follow-up writing Allspaw did in the years after — is the specific, traceable origin of vocabulary that is now so common in incident response that many engineers assume it was always there. It wasn't. Someone had to argue for it, in public, against the intuitive alternative of finding out who broke something and making sure they felt bad about it. Where this page describes things beyond that essay itself — Etsy's broader engineering culture, what happened after the post went out — it says so plainly and hedges accordingly.

Where this starts: a company that had already bet its culture on shipping fast

☺ Like you're 10: Etsy was already deploying code many times a day, which only works if people aren't afraid to admit when a deploy breaks something.

By the early 2010s, Etsy had built an engineering culture organized around frequent, low-ceremony production deploys — commonly cited figures from Etsy's own engineering talks and blog posts of that era put the pace at dozens of deploys a day, pushed by ordinary engineers rather than routed through a separate release team. That model has a structural precondition that's easy to miss: it only works if engineers aren't quietly afraid of what happens the day one of those deploys breaks something. A culture that punishes the person whose deploy caused an outage creates enormous incentive to slow down, add approval gates, and route around anything risky — exactly the behavior that kills a high-frequency deploy culture. Etsy's technical leadership, John Allspaw prominent among them, was explicit that psychological safety wasn't a nice-to-have side effect of a good culture; it was a load-bearing requirement for the operating model they'd already chosen.

The essay: "Blameless PostMortems and a Just Culture"

☺ Like you're 10: One engineer wrote down, in public, exactly why blaming people after an outage backfires — and gave the alternative a name.

In May 2012, John Allspaw — an engineering leader at Etsy at the time (accounts of his exact title through his Etsy tenure vary; he would go on to serve as the company's CTO) — published "Blameless PostMortems and a Just Culture" on Etsy's engineering blog, Code as Craft. The essay's core claim is a practical one, not a moral one: a postmortem's entire value depends on getting an honest, detailed account of what happened from the people closest to the incident, and blame is the single most reliable way to make that account less honest and less detailed. If engineers expect that admitting "I ran that command without checking the flag first" will be held against them, they'll describe what happened in vaguer terms, omit the part where they were exhausted or the runbook was wrong, and the postmortem ends up with less information than the incident actually contained. Allspaw's essay draws directly on an existing body of safety-science research from aviation and healthcare — most explicitly Sidney Dekker's writing on "just culture" — rather than presenting the idea as original to software. Its contribution to this industry wasn't inventing the concept; it was translating it into terms a software engineering organization could actually adopt, and doing so in public, with a title specific enough to become the standard shorthand.

Old view vs. new view: why "human error" is a symptom, not a cause

☺ Like you're 10: Instead of stopping the investigation the moment you find "a person did the wrong thing," that's supposed to be where the real investigation starts.

The essay's central distinction, borrowed from Dekker's "old view" and "new view" framing of human error, reframes what a postmortem is even trying to find:

The trap the new view is built to avoid is hindsight bias: once you know how an incident ended, the "obvious" mistake in the middle of the timeline looks obvious only because you're looking at it backwards, with information the person in the moment did not have. A responder at 2am, staring at one dashboard, working from a runbook that was accurate the last time they checked it, is not the same as an investigator a week later who already knows exactly which command caused the outage. Treating the two as equivalent — judging the 2am decision by what a calm, fully-informed reviewer would have done — is, in this framing, not just unfair to the individual; it's bad epistemics that produces a postmortem which explains nothing generalizable about the system.

Just Culture: blameless doesn't mean consequence-free

☺ Like you're 10: Not punishing honest mistakes isn't the same thing as never holding anyone accountable for anything, ever.

The word "blameless" gets flattened in casual retelling into "nobody is ever responsible for anything," and that is not what the essay argues, nor what the "just culture" literature it draws on argues. A just culture — the term itself, again, is Dekker's, developed from earlier aviation and healthcare safety work — deliberately holds two things in tension: an organization needs an environment safe enough that people report honest mistakes and near-misses without fear, and it still needs a way to address genuinely reckless or willfully harmful behavior, because collapsing that distinction in the other direction is its own failure mode. An engineer who makes a defensible call under uncertainty, following the process as documented, using the information available to them, is the case blameless postmortems exist to protect. An engineer who ignores a known safety check, repeatedly, after being explicitly told not to, is a different case — and pretending otherwise in the name of "we're blameless here" is not the culture Allspaw's essay is describing.

What actually changes in the document: an account, not a verdict

☺ Like you're 10: Instead of writing what the person should have done, you write down exactly what they could actually see and know at the time.

The just-culture framing isn't only a meeting-room tone — it changes specific sentences in the postmortem document itself. Counterfactual language ("they should have checked," "they could have noticed") gets replaced with a reconstruction of the responder's actual view: what was on their screen, what the runbook told them, what they'd been told in the last handoff, what else they were juggling. Judgment-laden verbs ("failed to," "neglected to," "ignored") get replaced with neutral, specific description of what happened and what information was or wasn't available at the time. The rewrite below is an illustrative example applying this framing — not an excerpt from an actual Etsy postmortem, which this page has no access to:

Before (verdict-style):
"The on-call engineer failed to check the runbook before
restarting the primary database, which caused a 40-minute
outage. They should have known the restart procedure required
a failover step first."

After (account-style, just-culture framing):
"The on-call engineer restarted the primary database directly —
the same way every previous restart of this service had been
performed without incident. A failover step had been added to
the runbook six weeks earlier, after a different service's
postmortem, but that change was never surfaced in the on-call
handoff notes or in the alert that paged this engineer. Given
what was visible to them at 2am, a similarly-trained engineer
would plausibly have taken the same action."

Notice what the second version makes actionable that the first doesn't: it points at a specific, fixable gap — the runbook change never reached on-call handoff or the paging alert — instead of a character trait ("should have known better") that no engineering ticket can close. This is the same discipline this course's own postmortems & blameless culture page teaches through the five-whys technique, and it's not a coincidence: that page's warning that five-whys is a tree of contributing factors, not a single line, traces back to a later, widely-cited Allspaw piece critiquing an over-simplified use of the five-whys technique on exactly these grounds — that chasing one linear "root cause" tends to land back on a person if you stop asking too early.

How the idea spread beyond Etsy

☺ Like you're 10: One company's blog post turned into vocabulary that almost every tech company now uses without citing where it came from.

"Blameless postmortem" is now close to universal vocabulary in incident response — enough that most engineers who use the phrase today have never read the essay that gave it its name. A few concrete threads in that spread are worth naming specifically, while being honest about which are well-documented and which rest on secondary reporting rather than the essay itself:

• Google's SRE book. Google's Site Reliability Engineering (2016) devotes a full chapter to postmortem culture and treats the blameless framing as a settled best practice rather than a novel argument — by the time Google's own book codified it for a much wider audience, the vocabulary Etsy had popularized four years earlier was already the industry default, not something the book had to reintroduce from scratch.
• Allspaw's own follow-up writing. Roughly two years after the original essay, Allspaw published a widely-cited follow-up, generally referred to as "The Infinite Hows," specifically critiquing shallow use of the five-whys technique — the same critique this course's own postmortems page repeats as a warning callout, arguing that real incidents are a tree of contributing causes, not a single chain terminating conveniently on one person.
• Outside expertise brought in-house. Public reporting from that period (treat this as secondary reporting, not something stated in the 2012 essay itself) describes Etsy engaging outside resilience-engineering researchers to work directly with its engineering organization in the years after — a sign the company treated the underlying safety science as something to keep investing in, not a blog post to publish once and move on from.
• Conference and community adoption. The framing spread heavily through the DevOps and web-operations conference circuit of the early-to-mid 2010s — talks, panels, and follow-on blog posts from other companies citing Etsy's approach directly — the informal mechanism through which a lot of operational best practice actually propagates, well before it shows up in a textbook.

What to steal for your own postmortem practice

☺ Like you're 10: You don't need Etsy's scale to copy the habit — write down what people actually knew, not what they should have known.

• Draft the account before assigning any judgment. Reconstruct exactly what the responder could see, know, and was juggling at the time, before anyone in the room says a word about what "should" have happened. The reconstruction is the valuable artifact; the judgment, if any is even warranted, comes after and separately.
• Ban counterfactual and judgment language from the written document. "Should have," "could have," "failed to," "neglected to" are all signals the writer has substituted hindsight for the responder's actual, in-the-moment view. Cut them and ask what specific information gap or missing guardrail the sentence is actually describing.
• Keep the accountability line, and draw it explicitly. State plainly, as policy, that honest mistakes made in good faith following available process are not punished — and that this is distinct from, not the same as, tolerating reckless or willfully harmful action. A team that never says the second half out loud will eventually have someone test whether "blameless" was ever real.
• Watch the room, not just the document. A blameless write-up read aloud in a meeting where the tone still assigns fault has changed the paperwork without changing the culture — the practice lives or dies in how the review conversation actually goes.

Honest caveats: what doesn't transfer cleanly

☺ Like you're 10: One blog post from 2012 doesn't automatically make any company's postmortems blameless — that takes ongoing, deliberate work.

• This page describes one company's published essay, not a verified before-and-after study. There is no independently audited dataset showing Etsy's incident rate, mean-time-to-resolution, or engineer retention improved by some specific number because of this practice. The case for it, as made by Allspaw and the safety-science literature he draws on, is a reasoned argument about information flow — not a controlled experiment with a measured effect size.
• "Blameless" is easy to say and genuinely hard to sustain. It requires leadership that doesn't quietly use postmortem content in performance reviews, facilitators willing to redirect blame-flavored language in the room in real time, and enough organizational trust that people believe the policy is real before they'll test it by admitting an honest mistake. None of that is automatic just because a wiki page says "we do blameless postmortems here."
• The accountability boundary is genuinely hard to operate, not just to state. Distinguishing "an honest mistake a similarly-trained peer would plausibly have made" from "reckless disregard" sounds clean in a diagram and is often contested in the room, especially when the same incident has caused real customer harm. Just-culture literature gives a tool (the substitution test) for approaching that line, not a formula that removes judgment from the decision entirely.
• Etsy's specific engineering culture — high trust, high deploy frequency, deliberate investment in this literature — isn't automatically present just because a team adopts the vocabulary. A company can rename its incident review "the blameless postmortem" without changing anything about who gets to speak candidly in it, or whether admitting a mistake there is actually safe. The label transferred far more easily than the underlying trust did.

Where this connects in the course

☺ Like you're 10: This one company's essay touches several other lessons — follow whichever one matches what you're building next.

The full mechanics of running a postmortem — the standard template, the five-whys technique, and closing the loop on action items — are covered in depth on postmortems & blameless culture, and a full worked example is on the course's own incident case study. What happens upstream of the write-up — who gets paged, how an incident gets declared and escalated — is incident management & on-call, and for genuinely large, multi-team incidents specifically, incident command for large-scale incidents. The organizational trust this whole practice depends on is the same territory as organizational impact of SRE and anti-fragility & learning from failure. For another real company's postmortem culture — one built around publishing incident write-ups externally rather than just internally — see Cloudflare's public postmortem culture; for the error-budget policy that decides which incidents get this level of scrutiny in the first place, see Google & the error-budget policy. To practice the actual writing discipline this page describes, try the postmortem-writing drill or, for the full end-to-end version, capstone part 4. And for the operating-model view of what separates a functioning blameless practice from theater, see best practices & the SRE operating model and SRE anti-patterns & pitfalls.