Etsy: Deploying Fifty Times a Day
also called Code as Craft
Etsy demonstrated that very frequent small deployments reduce risk rather than increasing it, and paired it with blameless postmortems.
The context
In the early 2010s Etsy became one of the most visible demonstrations that a substantial commercial site could deploy many times a day. The prevailing belief at the time was the opposite: releases were risky, so they should be batched, scheduled and heavily reviewed.
Why frequent deployment is safer
The mechanism is batch size, and it is worth being precise about it because the conclusion is counter-intuitive.
A deployment containing one change has one suspect when something breaks. Diagnosis is immediate, rollback is unambiguous, and the change is small enough to have been reviewed properly. A deployment containing forty changes has forty suspects, an entangled rollback and a review that could not have been thorough.
So the change failure rate per deployment may be similar, but the cost per failure and the time to recover are dramatically lower — and because failures are cheaper, the team is willing to deploy more, which keeps batches small. The loop reinforces itself.
This is the finding the DORA research later confirmed at scale: teams deploying most frequently have lower change failure rates, not higher.
The cultural half
Etsy paired this with blameless postmortems — the practice of investigating incidents to understand the systemic conditions that allowed them rather than to identify who erred.
The two are inseparable. Frequent deployment means engineers will cause incidents. If causing an incident is career-damaging, engineers will stop deploying frequently, batch their changes and hide problems — and the whole system reverts.
The transferable lesson
If deployment is frightening, the response is to deploy more, not less — but only after building what makes that safe: automated tests, fast rollback, progressive delivery, and observability good enough to detect a problem in minutes.
And the cultural precondition is not optional. An organisation that responds to incidents by asking who is responsible will get slow, batched, heavily-gated delivery no matter what tooling it buys.