The first time I read The Phoenix Project I was running a small platform team that had inherited a build pipeline made of seven cron jobs and a Confluence page. By the time I finished, I had renamed two of those cron jobs to “Brent.” I am not proud of this. I am also not the only person who did it.

Re-reading it now, I wanted to know whether the book still earns its place on the recommended-reading lists. The honest answer is yes, with caveats. The book is older than the careers of half my current team. Many of the things Bill Palmer struggles with — change advisory boards, spreadsheet-based capacity planning, a build process that no one understands end-to-end — are still in production at companies that pay six-figure consulting fees to be told they have a “DevOps maturity problem.”

What it still gets right

Three things hold up beautifully.

The Four Types of Work. Planned work, unplanned work, changes, and internal projects. Kim’s taxonomy is the most useful framing I have ever handed to a steering committee that wanted to know “why we can’t move faster.” It costs nothing to draw on a whiteboard and immediately exposes the ratio that no one wants to look at. I have personally used the Four Types of Work in roadmap conversations more often than any framework taught in any TOGAF module.

Constraint thinking, lightly applied. The book wears its Goal-style Theory of Constraints scaffolding on its sleeve, sometimes a little too proudly. But the core lesson — that an hour saved at a non-bottleneck is a mirage — is the right lens for almost every “we just need more developers” conversation I get pulled into. Bill’s slow education in this idea is, I think, the book’s strongest dramatic arc.

Brent. Every org has a Brent. Naming the pattern lets you talk about it without making the actual Brent feel personally attacked, which is the only way you ever get to fix it.

What feels dated

The deployment cadence the characters celebrate at the end — multiple deployments a week! — is now the floor for any team that wants to keep running engineers above the age of thirty. The book also leans hard on a particular flavor of mid-2010s enterprise IT pain: heavyweight ITIL, a CIO who reports to a CFO who treats engineering as cost-center overhead, a sales team that promises features without asking. Some of those structures have softened. Many have not.

What dates the book more than the technology is the cultural assumption that the engineering organization is downstream of everything else. That is no longer true everywhere, but it is true in most large enterprises where the EA function still lives. Which is precisely why I still hand the book out.

The DevOps Handbook problem

I think you can skip The DevOps Handbook unless you are specifically auditing a transformation program. The Phoenix Project does the storytelling work; the Handbook does the listicle work. If you read the Handbook without the parable you get a checklist that looks like every other consulting deck. If you read the parable without the Handbook you get the lesson without the homework. Most practitioners do not need the homework.

Who I’d give this to

  • A new engineering manager who has never thought about the operations side of the house.
  • A product leader who keeps asking why “DevOps” is not done yet.
  • A director-level EA peer who is about to walk into a transformation program and needs the shared vocabulary before they get there.

I would not give it to a senior platform engineer. They have either already read it or they have lived it, and either way the book will not change their day.

Reading note

The audiobook is fine but the print edition is better. The diagrams matter more than the narrator does, and the Three Ways framing reads better when you can flip back to it. The IT Revolution paperback is the standard edition; ignore the various anniversary tie-ins unless you have a specific reason to want the extra essays.

What changed for me on the re-read

Two things.

First, I noticed how much of the book is really about organizational design rather than tooling. The build pipeline is a McGuffin. The story is about a company that has accidentally optimized for the wrong unit of work — individual ticket throughput — and pays for it everywhere downstream. That framing tracks tightly to the team-design conversations I have now about platform teams, stream-aligned teams, and the boundary between them. If you read this book and then read Team Topologies, the second one becomes much more legible.

Second, the book’s treatment of risk feels almost quaint now that we are all reasoning about agentic systems that ship changes without a human in the loop. The CAB meeting in chapter four is funny, but the principle — that you need a way to reason about blast radius before you change production — has never been more important. If anything, the modern version is harder, because the changes are now coming from systems that do not explain themselves. I think about that every time I read a deployment plan written by a model.

Bottom line

The Phoenix Project is the cheapest org-design lesson on the market, and it is still the right one to hand to a peer who has not internalized the Four Types of Work. Buy the paperback, read it in two evenings, and lend it out aggressively. It will pay for itself the first time you stop a mid-quarter “let’s just hire more engineers” conversation in its tracks.

If you want the operational lens it implies but applied to the data layer, the obvious follow-up is Designing Data-Intensive Applications. If you want the org-shape lens, go to Team Topologies next.