The Phoenix Project is a fictionalized story about IT life, but it hits so closely to home for those of us in the technology realm that it was pretty stressful to read. Projects are constantly late, resources are over-utilized and scarce, the business is close to being split up because it hasn’t been meeting quarterly estimates, and so on. Anyone who views IT as the department that provides the computers and “keeps the lights on” without appreciating the details of not just the work but the people and politics they have to deal with, this book would provide great insight. This book also provides great insight into four kinds of work and the “Three Ways” of DevOps by example (I do list these in my review so do not continue if you don’t want to be spoiled).

In short, this is a good read. It is much like a self-discovery story where the protagonist is guided along by a guru.

Written in first person, this book may not be everyone’s cup of tea, but it does better connect you to the protagonist, Bill, who has a wife and two sons. Bill’s sudden promotion to CIO from lowly tech worker introduces him to a stressful few months where he is giving up his family life to keep his ship at work running. The first 70 pages or so were the most stressful with things breaking left and right and the added pressure of people blaming him and his people for holding back progress on a crucial project, Phoenix.

Then, Bill meets Erik, a prospective board member who is both eccentric and omniscient. Yet, Erik makes Bill work for the answers and balances hints with advice. Bill’s first task is to figure out what the four types of work are. The first he can name right away and is work-work, or work that benefits the business. Over the next few crises, Bill realizes what the other three types of work are: internal projects, changes, and unplanned.

Note: A couple of my coworkers were discussing this book with me as I was in the middle of reading it, so the next part is unfortunately biased.

Bill works closely with Wes, the Director of Distributed Technology Operations, and Patty, the Director of IT Service Support. There are also a slew of other characters introduced rapid-fire in the beginning that characters began to get jumbled in my mind. However, you have to use some strong suspension of disbelief lenses because a lot of the dialogue and shifting of opinions would not have taken so quickly in real life. The story takes place over the span of about 4-5 months. Most characters were convinced within a conversation or two.

As a novel, it kept the pace moving so I understand its necessity, but as someone who works in that world, it was very difficult to get over how people would get on board with a novel idea. I’m still struggling with teammates, four months into a project as of the time of this writing, who are opposed to picking up and learning to use new technologies.

(End bias.)

The other idea that the book brings about by example is the concept of the Three Ways, or the underlying principles of DevOps patterns. The First Way is about maximizing the flow of value from Development, through IT, to the customer by using small and frequent releases and ensuring defects do not travel downstream. The Second Way is about the reverse flow, getting fast feedback from the customer, back through IT, back to Development to improve quality and daily work, and either reduce crises from recurring or enabling faster detection and recovery. The Third Way is about fostering a culture that supports experimentation, learning by failing fast and early, and repetition and practice in order to gain mastery.

The Phoenix Project is an easy read, but it can easily represent the reality in many companies which also makes it stressful to read. I thought the pacing was a little odd with the most intense parts of the book being at the very beginning, then not too long after Erik is introduced, the pace begins to slow. If my coworker had not told me that the first 70 pages were stressful (though, not the words he used), I might not have finished this book.

I was a little off-put by the generalizations of the common personalities you would encounter in the IT world and the business in general, but the chemistry of the mix makes the story work. There were moments where I was confused by dialogue claiming something along the lines of “development has finished their part, everyone is waiting on IT” when it was clear that development was fighting fires alongside IT.

As a developer myself, it was hard to remember that the main characters were IT and separate from development. The presentation of Brent, a genius of the IT department, reminds me of the heroics some developers do to get code working that I often blurred the lines.

But another point that is made by the book is that IT isn’t a separate department of the business, but an underlying and integral part of it. Bill was tasked to interview the different parts of the company (e.g., chief financial officer) and in doing so, the reader and the characters realize that they can’t just think within the scope of “IT” but much broader in order to have a well-oiled machine. Erik both alludes and hits Bill upside the head with this fact multiple times.

So, after having read this book, I now have an introduction and a notion of the four kinds of work and the Three Ways. I do not yet have any idea how it will help me professionally, but perhaps I can work on improving my daily work somehow.