Practice & Reference · Case Study · Real company

Etsy — a blameless security culture

This is a real, named company's story, and this page sticks to what's publicly documented — Etsy's own "Code as Craft" engineering blog, and conference talks and writing from the engineers who actually built this culture. Unlike the other named companies in this set of case studies, this isn't a breach story: Etsy has never disclosed an incident anywhere near the scale of Capital One's, Equifax's, or SolarWinds'. What Etsy gets cited for, constantly, in the DevOps and security literature is something quieter and arguably more durable — an operating model built around blameless postmortems, a security team that embedded itself inside engineering instead of gatekeeping releases, and an unusually strong internal-tooling reflex, all of it forced into existence by a deploy cadence at which a single late-stage manual review gate was never going to survive contact with reality.

The setup: a deploy cadence that made a manual gate structurally impossible

☺ Like you're 10: Etsy wasn't shipping once a quarter — it was shipping dozens of times a day, and whatever's supposed to check code at that speed has to run at that same speed or it just gets skipped.

Flickr, 2009, and the talk credited with helping start DevOps

In 2009, John Allspaw and Paul Hammond gave a talk at the Velocity conference called "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" — about Flickr, not yet Etsy. Alongside Patrick Debois coining the term "DevOps" at DevOpsDays Ghent the same year, that talk is one of the two moments most consistently credited, across the DevOps literature, with kicking off the movement: a public, concrete demonstration that development and operations working as one team, deploying constantly, produced a more reliable system than the alternating throw-it-over-the-wall model most companies still ran.

Allspaw brings the model to Etsy

Allspaw joined Etsy shortly afterward, around 2010, as its SVP of Technical Operations, and brought the same continuous-deployment discipline with him. Etsy's engineers built Deployinator — an internal, self-service deploy tool with one big button per application, described in the team's own "Quantum of Deployment" write-up on the Code as Craft blog with a tagline that stuck: "push button, get bacon." Etsy open-sourced it not long after. Over the following years, Etsy's own engineers described — in multiple public talks and blog posts — deploy volumes in the dozens per day, a number that became almost as widely cited in DevOps circles as the original Flickr talk itself.

That cadence isn't a side detail — it's the reason everything else on this page exists. The bottleneck math covered on What is DevSecOps? — a single manual security gate, staffed by a team smaller than the engineering org it reviews, becoming the thing every release queues behind — isn't a hypothetical at dozens of deploys a day. It's arithmetic. A handful of security reviewers cannot individually eyeball that many releases without either becoming the company's single point of failure or becoming the team everyone quietly routes around. Etsy's culture wasn't built because someone decided gatekeeping was philosophically wrong; it was built because gatekeeping was, at that deploy volume, physically impossible to sustain.

Blameless postmortems: turning failure into a shared, searchable lesson

☺ Like you're 10: If admitting a mistake gets you in trouble, people learn to hide mistakes — so the company that wants to actually learn from mistakes has to make admitting one the safe, boring, expected thing to do.

"Blameless PostMortems and a Just Culture" (2012)

In a widely cited May 2012 Code as Craft post titled "Blameless PostMortems and a Just Culture," Allspaw laid out the argument in plain terms, drawing on the human-factors research of Sidney Dekker (Just Culture) and James Reason's work on the "Swiss cheese model" of how failures actually happen. The core claim: an individual's action that looks, after the fact, like an obvious mistake almost always made sense to that person at the time, given what they knew, what the tools showed them, and the pressures they were under in that moment. Treating "human error" as the root cause and disciplining the person closest to the failure doesn't fix the conditions that produced the error — it just teaches everyone else watching to hide their own near-misses rather than report them, which is precisely the information the organization needs to actually prevent a repeat.

Just culture, not zero-consequence culture

The nuance matters, and it's the part that gets flattened the most in casual retellings. Dekker's "just culture" is not "nobody is ever accountable for anything" — it draws a line between an honest mistake made under normal conditions (protected, treated as a source of learning) and a small number of genuinely reckless or deliberate rule violations (still handled as a conduct issue, rarely the actual cause of a real incident). Etsy's postmortem process assumes almost every incident falls on the first side of that line, because in practice almost every incident does.

Morgue: making incident history a queryable asset, not tribal memory

Etsy paired the postmortem process with an open-sourced internal tool called Morgue, released around the same period, for tracking every postmortem document, tagging the systems and services each incident touched, and making the whole history searchable. The practical effect: instead of "ask the one senior engineer who remembers this happened before," anyone could query whether a given service had a pattern of contributing to incidents over a quarter. A postmortem that lives in one person's memory teaches that one person something. A postmortem that lives in a searchable, tagged system teaches the organization something — the same shift incident response & forensics covers as the difference between closing a ticket and actually reducing the recurrence rate.

Security engineering embedded in the pipeline, not gatekeeping it

☺ Like you're 10: Instead of one small team standing at a locked door checking everyone's homework before they're allowed to leave, the security folks sat down at the desks and did the homework together.

Why a security team can't run a manual gate at this pace

Zane Lackey, Etsy's Director of Security Engineering through the early-to-mid 2010s, has described in numerous conference talks and later writing what Etsy's security team did instead of running a pre-release review queue: it stopped trying to be a gate at all. At dozens of deploys a day, a centralized approval step isn't a security control — it's a queue that either becomes the org's bottleneck or gets bypassed the first time a release is time-sensitive, which in practice is most releases. The team's response was to redesign the security function around the deploy cadence instead of asking the deploy cadence to slow down for security.

Pairing, tooling, and a bug bounty instead of a review queue

Concretely, that meant several things Lackey has described consistently across his public talks on the era:

• Security engineers embedded with feature teams — attending the same standups, working from the same backlog — rather than sitting in a separate team that only saw a change once it was "done."
• One pipeline, no separate slow lane. A security fix went out through the exact same continuous-deployment pipeline as any other change — see security in CI/CD — instead of a special "security release" process that moved at a different, slower speed and therefore accumulated risk while it waited its turn.
• Findings routed straight to the owning engineer, through internal tooling the security team built itself, rather than sitting in a ticket queue only the security team could see. A finding nobody but security can read is a finding that waits for security's attention; a finding that lands directly on the owning team's board gets fixed at engineering speed.
• Treating outside researchers as extra coverage, not adversaries. Etsy ran one of the earlier public bug-bounty programs, per Lackey's own later talks about the period — essentially formalizing, and paying for, the exact instinct Rocky the Raccoon represents throughout this course: something unlatched will eventually get found, so you're better off inviting the search than hoping nobody looks. See Offensive Security for DevSecOps for how a modern bug-bounty and pentest program is actually run.

The tooling reflex: if it's not measured, it's not managed

☺ Like you're 10: Etsy didn't just say "we care about reliability and security" — it built dashboards that made caring the easy default instead of a special effort.

StatsD: measure anything, measure everything

In a February 2011 Code as Craft post titled "Measure Anything, Measure Everything," Etsy engineer Ian Malpass described building and open-sourcing StatsD, a small daemon (inspired by a similar internal tool at Flickr) that made emitting a metric from application code close to free — a single line, no ceremony, aggregated and shipped to Graphite. The stated philosophy was blunt: if engineers have to ask permission or write boilerplate to instrument something, most things won't get instrumented, and anything not instrumented is invisible until it fails loudly. StatsD's protocol went on to become something close to a de facto standard — most modern observability platforms still speak it, or something compatible with it, over a decade later. The same instinct — instrument continuously rather than review occasionally — is the direct ancestor of what Detection Engineering & Security Observability teaches for security signals specifically.

Feature flags: a kill switch that doesn't require a redeploy

A companion Code as Craft post by Mike Brittain, "Flags and Levers," described how Etsy decoupled deploying code from releasing a feature to users: a flag shipped disabled, then got turned on gradually — for internal staff, then a small percentage of traffic, then everyone. The security-relevant consequence is the part that's easy to miss: a flag is also a kill switch. If something built this way turns out to be risky once it's live, killing it is flipping a flag, not rolling back a deploy and re-running the whole pipeline. That's the same underlying discipline this course covers under progressive rollout patterns, and it's a big part of why "ship continuously" and "stay in control of what's actually live" aren't in tension the way they first sound.

What Etsy actually published as outcomes

☺ Like you're 10: A lot more safe deploys per day, and a couple of the ideas Etsy's engineers built spread so far outside Etsy that most people using them today don't know where they came from.

As with any company's own account of its own culture, treat the following as evidence the model clearly produced results Etsy was proud enough to describe publicly — not as an independently audited case study with a published methodology.

• Deploy volume. Etsy's own engineers described deploy counts in the dozens per day across multiple public talks and blog posts through the early-to-mid 2010s — the concrete, sustained proof that the Flickr talk's premise (development and operations moving as one, at speed) scaled past a single demo.
• StatsD's reach. A tool built to solve Etsy's own instrumentation problem became a metrics protocol implemented by observability vendors well outside Etsy, and is still referenced in monitoring tool documentation today — a genuinely unusual amount of downstream influence for an internal side project.
• The postmortem model's spread. "Blameless postmortem" has become close to standard vocabulary in site-reliability and incident-response writing since Allspaw's 2012 post — cited directly in later, widely read books like The DevOps Handbook and Google's own Site Reliability Engineering materials as a named influence.
• What the people who built it did next. Lackey and colleagues from Etsy's security-engineering team went on to co-found Signal Sciences, a web-application security company built around the same "security embedded in the deploy pipeline, not bolted in front of it" philosophy — later acquired by Fastly in 2020 for a reported figure in the hundreds of millions of dollars. Allspaw left Etsy around 2018 and co-founded Adaptive Capacity Labs with resilience-engineering researchers Richard Cook and David Woods, turning the incident-analysis practice this page describes into an ongoing research and consulting discipline.

What to steal for your own team

☺ Like you're 10: You don't need Etsy's scale to copy the habits — make honesty cheaper than hiding, hand findings straight to the person who can fix them, and instrument the things you care about.

• Make "report immediately" cheaper than "hide it." The entire postmortem process depends on an incentive gradient that actually rewards fast, honest disclosure. If a near-miss report has ever led to a quiet consequence for the person who filed it, the gradient points the wrong way and people will notice, regardless of what the culture deck says.
• Route a finding to its owner directly — don't hoard it in a security-only queue. A finding that only security can see is a finding that waits for security's bandwidth. A finding on the owning engineer's own board gets fixed at engineering speed.
• Match your review cadence to your deploy cadence, not the other way around. A security process that runs slower than your release process isn't a review — it's a queue, and every queue eventually gets routed around under deadline pressure.
• Build one searchable incident history, not a folder of one-off docs. Morgue's real value wasn't the individual postmortem — it was making the pattern across postmortems queryable, so "hasn't this service caused trouble before" has an answer nobody has to remember by hand.
• Treat outside researchers as coverage you're paying for, not a threat you're defending against. A bug-bounty program is, structurally, the same idea as Rocky the Raccoon's whole job description, purchased at scale instead of hired in-house.

Honest caveats: what doesn't transfer, and what's less publicly documented

☺ Like you're 10: A culture built by a specific group of people, at a specific company size, over specific years doesn't fit in a weekend — and some of the harder details never made it into a blog post in the first place.

• The scale and hiring bar were specific to Etsy at that time. This was a company of a few hundred engineers, not a few thousand, with a famously senior, deliberately curated engineering culture. A blameless model assumes a baseline of trust and competence that's easier to sustain in a smaller, carefully hired org than in one with high turnover, heavy contractor use, or thin management bandwidth.
• "Blameless" is easy to claim and hard to sustain — and the hard part is invisible from outside. Whether leadership actually follows through, quarter after quarter, when a costly incident traces back to a specific person's decision, doesn't show up in a conference talk. The public record here is the policy Etsy described, not an audit of whether every manager honored it every time.
• Etsy is a payments-processing marketplace, which brings PCI DSS-style change-control expectations that aren't the part of this story Etsy has documented in as much public detail as the postmortem process. Don't read this page as "no gates existed anywhere at Etsy, ever" — regulated payment flows generally require some form of documented control, and exactly how Etsy reconciled that with continuous deployment is far less publicly discussed than the culture pieces covered above.
• Much of what's cited today describes Etsy circa 2010–2015, not necessarily Etsy's security organization today. Allspaw left around 2018; Lackey left years earlier to co-found Signal Sciences. The specific people whose talks and posts this page draws on built this culture and then, in large part, moved on to apply the same ideas elsewhere.
• The figures here are self-reported — talks, blog posts, and press coverage — not an independently audited case study. Treat deploy-count and outcome numbers as "Etsy has said," the same caveat that applies to any company's account of its own culture.

Where this connects in the course

☺ Like you're 10: This one company's story touches the culture, pipeline, and detection modules — read whichever matches what you're building next.

The cultural argument underneath this whole page — why psychological safety is a security control, not just a nice-to-have — is covered directly on Security culture & champions, and the incident-response discipline blameless postmortems feed into is Incident response & forensics. The pipeline mechanics that made "one gate, right before release" impossible at Etsy's cadence are the same ones covered on Security in CI/CD and, at a company-wide operating-model level, Best Practices & the Operating Model — with the specific failure mode Etsy avoided named directly on DevSecOps Anti-Patterns & Pitfalls. The "measure everything" instinct behind StatsD is the direct ancestor of Detection Engineering & Security Observability, and treating outside researchers as paid coverage rather than adversaries is Offensive Security for DevSecOps. For a fictional, fully worked pipeline built around the concepts this course teaches, see the course's own case study. For the sharpest possible contrast — an organization whose response to a real incident was concealment rather than a blameless postmortem — read Uber — a breach and its cover-up, the same fork-in-the-road this page's blame-loop diagram illustrates, played out for real.

Check your answers

1. At dozens of deploys a day, a small security team reviewing every release individually either becomes the company's single point of failure or gets routed around under deadline pressure — the same bottleneck math covered on What is DevSecOps?, just empirically forced by Etsy's actual release volume.
2. Because, per Sidney Dekker's research that Allspaw drew on, an action that looks like an obvious mistake in hindsight almost always made sense to the person at the time given what they knew. Punishing the outcome doesn't fix the conditions that produced it — it just teaches everyone else watching to hide their own near-misses, removing exactly the information the organization needs to prevent a repeat.
3. "Blameless" protects a reasonable decision made with the information available at the time; it does not protect a small number of genuinely reckless or deliberate rule violations, which remain a conduct issue. The distinction matters because a culture that claims "blameless" while still quietly punishing people through other channels isn't running this model — it's running the old model with better branding.
4. Embedding security engineers directly inside feature teams instead of a separate review team, routing findings straight to the owning engineer's own backlog instead of a security-only queue, shipping security fixes through the same pipeline as any other change, and running a public bug-bounty program that paid outside researchers instead of treating them as adversaries.
5. Searchability across incidents. A single filed document teaches whoever reads it; a tagged, queryable tool like Morgue lets anyone ask "has this service caused trouble before" and get an answer, turning tribal memory into an organizational asset instead of depending on one person remembering.
6. The model assumes a level of trust, seniority, and hiring rigor that was specific to Etsy's size and era at the time; a much larger organization, one with high turnover, or one under heavier regulatory change-control requirements can't simply copy the culture without also matching the conditions that made it sustainable.