The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford has been out for about 10 years now, and most people I’ve spoken to about it have read it. I, however, have just gotten around to reading it, after it was recommended to me quite some time ago by Huw Bristow.
The sub-title of the book is
A Novel about IT, DevOps, and Helping Your Business Win
This is an accurate summation, but it also does the book an injustice. DevOps is ubiquitous now, but when the book was first published it wasn’t as well-established a discipline, and many IT organisations (internal and external) suffered the pain of rigid, Waterfall style project management (rather than product management), and the friction between operations (governed predominantly through ITIL) and development - and, in many ways, the rest of the business, or clients - was a constant source of stress. In many organisations this is still true.
The book has an interesting and unique style; it’s told from a first-person perspective, but also in present tense. The story progresses through a high-stress and high-stakes scenario, and this approach helps lend a sense of immediacy and urgency to the narrative.
The purpose of the book was to evangelise the discipline of DevOps and help business understand how it can lead to lower stress and increased value through automation, allowing workers to focus on important tasks. But it does a lot more than this - it also espouses the relevance and value of management theory and principles originating in the automotive industry for IT and development teams and organisations.
In this review, I’ll look at the core lessons from the book in terms of management principles, and then give my overall impression and takeaways.
This review contains minor spoilers. If you haven’t read the book and are intending to, I think it’s unlikely these would impact you, but it seems fair to provide warning.
Management Principles
One of the key inspirations for the book is The Goal by Eliyahu M. Goldratt and Jeff Cox. Like The Phoenix Project, The Goal is a novel that is used to convey a management principle; in this case, Goldratt’s theory of constraints. Originally published in 1984, it illustrates the principle that all work in the pipeline is dictated by a single constraint or bottleneck. I haven’t read this book yet, but it’s now on my list.
Another key inspiration for the book are the Lean Manufacturing Principles originating in the Toyota Production System. In the book, the protagonist Bill Palmer encounters a mentor called Erik, who coaches Bill through his struggles in his now role as VP of IT Operations at Parts Unlimited, a fictional (yet all-too-real feeling, as we will see) automotive parts manufacturer (and retailer, one of the sources of tension in the book). Erik tries to impart to Bill his wisdom and knowledge of manufacturing management, and how these principles apply to IT management as well. Erik’s knowledge is distilled down to two main areas: the Four Types of Work, and the Three Ways.
Four Types of Work:
- Business Projects: These are the traditional projects that IT works on, often coming directly from business needs. They might include creating new features, entering new markets, or any task that provides direct value to the business.
- Internal IT Projects: These projects do not always directly provide value to the business but are essential for the internal workings of the IT department. Examples might be upgrading a database, transitioning to a new platform, or other infrastructure changes.
- Changes: This type of work originates from the ongoing need to keep systems up-to-date, efficient, and in accordance with business needs. Changes could be the result of either Business Projects or Internal IT Projects and may involve updates, patches, or other modifications.
- Unplanned Work or Recovery Work: This is the reactionary work that is required when things go wrong. It can often be disruptive and take precedence over all other types of work. The goal in any efficient system is to minimize unplanned work as it often comes at the cost of other value-adding activities.
The Three Ways:
- Flow of Work from Left to Right (First Way): This focuses on the performance of the entire system and not just a specific silo of work. The goal is to achieve a smooth and fast flow of work from Development to IT Operations to the customer. Key practices in this way include continuous integration, continuous testing, and continuous delivery.
- Feedback from Right to Left (Second Way): This is about creating a culture where feedback from one stage of the value stream is used to prevent problems in previous stages. It emphasizes the importance of understanding and responding to all customers, both internal and external. Key practices involve creating short and fast feedback loops to ensure that any defects are identified and corrected as quickly as possible.
- Culture of Continual Experimentation and Learning (Third Way): This encourages a culture where risks are taken, and a resilient system is built. The emphasis is on constant experimentation and learning from failures. It also values repetition and practice, believing that the more something is practised, the more proficient an organization becomes.
Realism…
Works of fiction depicting a particular industry or profession are usually criticised for their sensationalised or overly-dramatic representations of the working life of professionals, with little representation of the true mundaneness of the field. Some prominent examples that come to mind would be hacking/cybersecurity, medicine, and politics.
The Phoenix Project masterfully weaves a compelling narrative that resonates with the realities of IT department life. Many readers, including myself, have found its portrayal strikingly authentic, as if the authors had a window into our professional experiences.
The tension and drama in the story arises from the protagonist and his colleagues contending with an overwhelming situation which threatens the future of their company, while contending with competing internal and external priorities, amid a maelstrom of corporate politics and self-interest. While there is definitely drama there, the characters and scenarios are incredibly realistic, and you will feel like you recognise these people and these situations. Even the technology and processes, and descriptions of the work being done, are realistic representations. They certainly don’t go into technical depth, but they also don’t embellish or alter what really happens.
As I mentioned, it’s unusual and refreshing to see a dramatic representation of a profession that remains faithful while simultaneously delivering a compelling narrative. It’s certainly far removed from the movie Hackers (although I do still love that movie, silly as it is).
…and Fantasy
While the characters and scenarios are grounded in reality, some solutions presented come across as streamlined or idealized, which might not always reflect the complexities of real-world scenarios. To be fair, while this is a common criticism, I personally don’t mind it. When you read any text book on business or technology processes, the solutions are always presented in a similar way (see, for example Adaptive Code via C# by Gary McLean Hall, a non-fictional book covering similar topics, recommended to me by Michael Ridland, which is also very good).
While the portrayal of the DevOps practices were idealised and simplistic, it’s the resolution of the political and character-driven tension that I found most unrealistic. It was this that broke my suspension of disbelief (minimally required as it was), and made me stop thinking of this book as the most realistic representation of a profession I had ever encountered, and instead consider it pure fantasy.
This is no doubt tied to my own experiences - prior to becoming a software developer, I had a career in IT Management and management consulting where I encountered many people and scenarios that were startlingly mirrored by those in the book. It’s rare in the corporate world to see a CEO or executive publicly apologize to a subordinate or take full accountability. Similarly, characters like Sarah Paulson, while familiar, often navigate the corporate landscape without facing significant consequences. In fact, they tend to flourish in these environments and be very successful.
Towards the end, the protagonist’s offer of a three-year fast-track program with “15 specific performance targets” for a COO role felt a bit idealised, as real-world promotions often come with more ambiguous criteria.
These are observations, not criticisms. In my opinion they in no ways undermine the value of the book; but in their stark contrast to the sometimes alarmingly realistic nature of the rest of the book, I found them somewhat jarring.
Conclusion
You might notice the absence of an in-depth discussion on the DevOps principles the book strongly advocates. This could be attributed to the evolving landscape of IT, where these practices have become more commonplace. While I certainly found the accounts of them in the book valuable, they weren’t new to me, which is probably why I didn’t focus on them.
Instead, I found the other aspects of the book more compelling. And also perhaps like many people who have read it, got swept up in how amazed I was at how frankly it captured and mirrored my own experiences.
In any case, I enjoyed the book, and I found the lessons to be valuable. I certainly wish I’d read it 10 years ago when it was first published!
Overall, The Phoenix Project is fun, entertaining, lightweight, and easy to read. At the same time it provides valuable business lessons. It would be incredibly hard not to recommend it - and, in fact, I think that anyone with even a passing interest in IT, development, DevOps, or management, should add it to their reading list.