The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim has been on my reading list for a while now. The Phoenix project has been one of the most mentioned and recommended books related to the DevOps movement. You couldn’t hop around two blogs before seeing a mention of it as a ‘must read’. So, naturally, I was eager to get my hands on it. I finally did, managed to read the book in snatches and complete it, while on a vacation a few weeks ago.
I can now kind of understand the reasons for its popularity. For one, it is written as a fast paced fictional novel. Needless to say, this format is highly unusual for a technical topic and definitely unlike any other technical book I’ve read as far back as I can remember. So the format kind of makes it an easy read and I did find myself getting pulled into the story once I started. I digress, but I’m mostly inclined to finish books end to end, irrespective of the quality of the content. Being an optimist or more likely suffering from reading inertia, the book might turn a corner on the next page right ? So I keep turning (read swiping on my devices), and just like that, before I know I am reading the epilogue. Such is the life of an itinerant, inertia afflicted optimistic bookworm, you read the good, the bad and the ugly.
Back to the book in hand. Second off, given the rather dry nature of the topic, adding in the drama, the twists and turns keeps it interesting, although admittedly, I found them incredulous at times.
So the story goes like this. The protagonist is Bill Palmer, who has been unwillingly trust into the position of VP of the IT department at ‘Parts Unlimited‘, an automotive parts manufacturer and retailer company. Unwillingly, because the company is in a ‘do or die’ crisis mode and Bill has the threat of outsourcing the entire IT department, hanging on his head, if he fails to turn things around. The eponymous project which is at the heart of the maelstrom is the ‘Phoenix project’ and is the last raft for the sinking company. The launch deadline has been set in stone and the world is eagerly waiting to see if they can indeed deliver on the promise.
Each day brings raging fires that Bill has to put out, thankfully with the aid of a few helpful colleagues. What is a novel without a villian right ? So Sarah, the villian, is ever present, trying to sabotage Bill every step of the way. Adding some more intrigue to the thickening plot is Eric Reid. He is a mysterious Yoda-esque character (but nowhere as endearing as Yoda) who is being recruited to be on the board of the company by the CEO. Eric takes on Bill as his disciple to enlighten him about the ‘Three ways‘ that will eventually lead to DevOps epiphany and success. The three ways are of course the key principle takeaways from the book.
1. The Flow – The core concept is that the entire project must flow smoothly from development to operations (left to right) just like in manufacturing. The point is repeatedly made in the book that manufacturing and software development are more akin in this respect than not and hence the same principles as in manufacturing can be applied to software successfully. Think Lean principles.
2. Feedback – As the flow goes from left to right, so should the feedback at each step (testing, deployment, production, operations) flow back from right to left.
3. Continuous experimentation and learning – With the flow, feedback and the breaking of departmental silos, the entire company moves to a culture of continuous experimentation and learning.
With Eric’s help, Bill, slowly over the course of weeks, realizes the errors in the way his company operates and sets them right one at a time. The developers, IT, marketing, the audit team – everyone comes together with a unifying purpose, except for Sarah who in the end exits the company. The Phoenix project is a success and Eric Reid fades away into the night, with his work done. Bill is set on the path to become the company CTO (I think ). And thus it ends – a fitting happy ending for all.
So my final thoughts, although the novel format felt novel to me (pun intended), it was an OK read. I fell into the groove after a few chapters. Perhaps it’s just me, but I prefer to read books which are more rigorously technical. With novels I tend to gloss over the story since I associate them with leisurely reading , meaning I set aside the critical thinking and assessing. The point is to just enjoy the good plot. With that being said, I would definitely recommend reading this book once, especially if you are in a company looking into adopting DevOps or transitioning into it. You might just relate to some of the chaos and fires yourself and then see the way out as Bill did.