Book Review - The Phoenix Project

NOTE: May contain spoilers.

Recently I have been reading books about DevOps–its (short) history and (old) influences. That meant reading The Goal by Eliyahu M. Goldratt, which is a business novel about managing a factory using lean manufacturing concepts. The Goal is heavily referenced in The Phoenix Project, and in fact Kim et al’s book mirrors the style and format of Goldratt’s book. (Though it leaves out much of the home life drama of the main character that is included in Goldratt’s book.)

In short the allegorical novel is about Bill Palmer, an IT manager who is suddenly promoted to VP of IT Operations in a large, struggling auto parts manufacturing company. Every IT department and project is a mess and will be familiar to anyone who has worked in the field. The book also uses the same Socratic method as The Goal in that there is an eccentric Guru character, Erik, who helps Bill along the path to success using questions that force critical thinking along the DevOps paradigm.

The first part of the book is about connecting with the reader.

…the first 170 pages of the book is really designed to create the response of “holy cow, this is me that they’re describing in the book,” regardless of your role in the organization. Why? It’s because it happens everywhere where DevOps practices and culture isn’t embraced. – Gene Kim, infoq

Coming from an information security background, I was struck by how the Chief Information Security Officer (CISO) was depicted in the book, but I was not surprised, because I’ve also read Kim et al’s book Visible Ops Security, in which statements such as the following are made:

[P]eople may use the following words to describe information security: hysterical, irrelevant, bureaucratic, bottleneck, difficult to understand, not aligned with the business, immature, shrill, and perpetually focused on irrelevant technical minutiae.

In the context of the Visible Ops Security book I absolutely agree with the above statement, and have always felt that something needs to change in information security in order for it to become more aligned with the business, and instead of saying no all the time, be able to say yes to new, valuable projects, and to help those projects in achieving reasonable security.

In The Phoenix Project the CISO, John, hits rock bottom after a series of security project failures. In fact there is a scene with him extremely drunk in a bar, with all his belongings packed in a U-haul attached to his Volvo (of course he drives a Volvo). The VP IT Operations gets him a cab home and afterwards John doesn’t come into the office for two weeks. When he finally returns to work he is a “new man,” complete with a shaved head, new attitude, “Euro discotheque” style, and game to implement security in a way that is acceptable to his peers, as well as Erik, the wealthy, eccentric, lean business (and auditing) Guru. While the transformation is a bit obvious, this is an allegorical novel, and the point’s well taken. I assume at some point he sells the Volvo and buys a Porsche.

I don’t think the book is as compelling as Goldratt’s novel. What I do like about The Phoenix Project is its focus on information security, and to a lesser extent auditing. I think there are a lot of improvements that can be made in the way information security practitioners integrate into their organizations culturally, and that this book begins giving examples as to how to accomplish that. However, it does not go far enough down that road, and I would love to read another information security specific book from these authors, one advancing the work done in Visible Ops Security and The Phoenix Project, though I think it will be some time before they can get to it as they are still working on the book The DevOps Cookbook.

In the end, The Phoenix Project is a good read which is differentiated from other business and technical books by its storytelling approach, and it is about DevOps, which likely makes it required reading for anyone in, or wanting to know more about, the difficult to define field.