Review of Gene Kim’s Novel, “The Phoenix Project”

Over the Christmas holidays, I read an advance copy of Gene Kim’s first novel, “The Phoenix Project.” Gene’s co-authors were Kevin Behr and George Spafford. It was a better read than I was expecting. It is about 350 pages. Here’s my review.

The book aims to describe how to bring TQM and “lean” (as in, “manufacturing”) disciplines to IT. Although TQM is especially important in the context of operations, the book shows how “systems thinking” that spans the development and IT operations organizations, and reaches upstream into finance, sales and marketing is critically important for technology-reliant companies. Because all but the most hidebound companies rely on IT to run (and transform) their businesses, the lessons in this book are generalizable to every company.

The book is less of a dramatic novel than a disguised set of parables about IT and DevOps, using a fictional company, crisis and characters to illustrate them. Most lessons are imparted by a mysterious “board member” named Erik, who serves as a combination Greek chorus, Zen master, drill sergeant and mentor to the main protagonist, a generically named midrange IT operations manager named Bill. Bill receives a battlefield promotion into a role he is unprepared for while, all around him, systems are crashing and strategically important projects are running horrifically off track. Most of us who have been in IT roles for a while can relate.

The authors are at their best when they focus on the technology and related (often broken) processes that permeate most companies’ IT processes. The protagonist Bill’s evolution as a manager from fire-fighting and free-fall, to productivity and proactivity, is well-done. As he embraces his new job, he slowly begins to understand the four types of work: business projects, IT projects, changes, and unplanned work. He also learns the tools he needs to increase his ability to do all four types of work using techniques such as simple change management meetings, kanban boards, monitoring processes and targeted, cross-functional “tiger teams” that automate the ability to deliver finished work more quickly.

It is very clear that the authors have a soft spot for the Agile and Lean styles of application development, the hallmarks of which feature short two-week development “sprints,” tight feedback loops between operations and development, and continuous integration workflows that build, test and deploy finished systems in minutes or hours rather than in weeks. The type of skills and tools needed to successfully implement these types of processes are loosely called “DevOps,” and they are what have enabled companies like Flickr and Twitter to innovate quickly. By the end of the book, Bill’s company has embraced this thinking, too. Although there is a certain amount if hand-wavey “and then a miracle occurred” glossing over of how Bill and his formerly bedraggled band of IT misfits manage to pull it all off, it’s fun to watch.

In contrast to the care and attention spent on describing IT processes, the characters through which the various lessons are imparted are paper-thin; we don’t really get to know them all that well, and it is not obvious why we should care about their fates. Like in a typical Tarantino film, the dialogue is mostly one voice spoken by multiple characters. I don’t think that is a major flaw, though; most readers are not going to read Gene’s book expecting another Navokov, or even the Second Coming of Crichton.

Overall, the book succeeds in its goal of communicating complex processes by way of extended example. If you want to understand the most important ways in which modern, technology-reliant companies need to transform their IT organizations, this book offers a valuable introduction. If I had one criticism, it is that I found myself wishing that the “lessons” from each chapter were summarized at the end of each major section, textbook-style. And although I had some trouble getting through the first 20 pages or so — which bogs down with exposition and character development — the rest of the book flew by.

I read “The Phoenix Project” in essentially one sitting with a break for lunch. I liked it much more than I thought I would, and recommend it.