Flickr's '10+ deploys a day' talk ends the war between developers and operations

In 2009 Flickr, the photo-sharing site inside Yahoo, was updating its service constantly, and the industry's default split — developers ship features, operations keep the site stable — made every change a fight. Change is the root cause of most outages, so the teams that 'protect' the site hardest are the teams that ship slowest.

Make change safe instead of rare: shared tools — feature flags, one-step deploys, shared metrics, chat robots — plus no-blame culture make 10+ deploys a day routine.

Operations-side manager John Allspaw and engineering-side manager Paul Hammond rebuilt releases around joint ownership: automated infrastructure, one shared version-control trunk, one-step build-and-deploy, feature flags, shared metrics dashboards and IRC chat robots — paired with an explicit culture list: respect, trust, a healthy attitude about failure, and avoiding blame.

Their June 2009 Velocity session drew more attention than any other talk at the conference, and the tools-plus-culture framing became the core of the DevOps playbook: months later the movement named itself at the first devopsdays in Ghent, and 'deploys per day' turned into an industry benchmark.

By 2009 Flickr, the photo site inside Yahoo, was shipping constantly: on a normal day it made ten or more full deployments of the website to production. At O'Reilly's Velocity conference in San Jose that June, the two managers who ran Flickr's operations and engineering sides, John Allspaw and Paul Hammond, explained how, in a talk titled '10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.' Data Center Knowledge's report from the conference called it the presentation that generated the most buzz of the event.

Their argument attacked the industry's default org chart. The stereotype — developers add features, operations keep the site stable and fast — turns change into the enemy, since change causes most outages. Allspaw and Hammond inverted it: ops' job is to enable the business, the business requires change, so the real work is lowering the risk of change through tools and culture. The toolkit: automated infrastructure, a shared version-control trunk, one-step build-and-deploy, feature flags that ship code dark, shared metrics, and IRC robots that let anyone watch releases happen.

The other half was cultural: respect, trust, a healthy attitude about failure, and avoiding blame — including fire drills so even junior engineers have practiced production incidents before a real one, because failure will happen. That October, Patrick Debois organized the first devopsdays in Ghent, Belgium; the movement that took its name from that event carried the Flickr talk's framing — small, safe, frequent releases by teams that share tools and blame no one — into engineering organizations everywhere.

It named the real constraint: in a web business the release train is the business, and a team that can deploy safely ten times a day simply outlearns one that ships monthly.

Shared tools manufactured shared fate — one trunk, one dashboard, one deploy button — so neither side could win by making the other lose.

It redefined ops from keeper of stability to enabler of change, letting automation and culture be judged by a single question: how often can we safely ship?

It treated blame as an engineering defect, not a character flaw: if people hide mistakes, risk compounds silently; fire drills and no-blame reviews keep information moving.

Throughput comes from making change safe, not rare. Shared tools create shared fate; blame teaches engineers to hide risk; ops enables the business, it doesn't guard uptime from the business.

The recording of the session is still online and still shown as a founding artifact of DevOps. That October, Debois's first devopsdays in Ghent gave the movement its name, and 'how many deploys a day?' became both a benchmark and a dare. Allspaw carried the approach to Etsy, where its cousins — blameless postmortems and continuous deployment — became famous in their own right. A decade and a half later, deployment frequency is a standard engineering metric, and 'dev versus ops' survives mostly as the strawman this talk demolished.