---
title: "The DevOps Handbook and the case studies where it always works"
description: "The DevOps Handbook's case studies all end well, and the failure it never shows is a new silo."
url: "https://michael.zazon.us/notes/the-devops-handbook-and-the-case-studies-where-it-always-works"
published: "2026-02-28T12:00:00-05:00"
kind: "book-notes"
subject: "operations"
tags: ["devops"]
---
I think DevOps has a bad habit of overselling what it can do.

[The DevOps Handbook](https://itrevolution.com/product/the-devops-handbook-second-edition/) is a non-fiction companion to The Phoenix Project (the novel that inspired [The Phoenix Project and the work nobody planned](https://michael.zazon.us/notes/the-phoenix-project-and-the-work-nobody-planned)), written by Gene Kim, Jez Humble, Patrick Debois, John Willis, and Nicole Forsgren. It's structured around the [Three Ways](https://itrevolution.com/articles/the-three-ways-principles-underpinning-devops/) (flow, feedback, and continual learning), which are based on Lean and Agile. The second edition (IT Revolution, 2021) includes new case studies from adidas, American Airlines, Fannie Mae, Target, and the US Air Force. I think the ideas in the book are great.. I wouldn't argue with any of the Three Ways.

The ideas seem fine.. I'd poke at the evidence. The case studies all share a common pattern: a big organization that was stuck, a 2-3 year transformation, and now they ship faster and their teams are calmer. There isn't a single case study where things were worse at the end than they were at the beginning.

Instead, it's almost like apocryphal stories about how DevOps always fixes every problem.

It's a map made only from those who made it to the destination, and it's silent about the routes where teams got lost or quietly quit. But it's along those routes that most of the valuable warnings are found.

So you hire a DevOps team because of the handbook, and two years later you end up with a new silo with a fancier name. Sound familiar? This frustration is common among small and mid-sized companies that have fully committed to a dedicated DevOps team.

They've invested in something that itself becomes overly complicated and then there's a lot of tech debt and then there's a lot of resentment and you get back into this old dev versus ops situation, but now you have this very expensive DevOps team versus what you probably had before.

But you're right back up against that wall again. The whole point of this book is to tear down the wall between dev and ops. If you put a team in place and call them DevOps, they can quickly become the newest, most expensive part of that wall.

What would a failed DevOps case study teach us that success stories can't? Would any company be willing to write one up so others could read it before repeating the move?