The Phoenix Project
A book review.
The Phoenix Project
A Novel About IT, DevOps, and Helping Your Business Win
by Gene Kim, Kevin Behr, and George Spafford
published: 2013
ISBN: 9781942788294
genre: Business (Management)
reviewed:2019.09.12
👍🏼 recommended
This is one of the most important books I've ever read, as an IT practitioner. It chronicles the promotion of a manager to an executive position at an auto-parts manufacturer during an existential crisis at that firm. The problems the hero faces are harrowing for their familiarity: no one knows what's being changed, and changes are causing problems; key staff are overloaded, and are threatening the success of the firm by retaining too much knowledge and responsibility; developers are working to constantly shifting requirements, and dumping half-baked code into production; chaos in production is burning everybody out; etc. As a result of all of this, key business targets cannot be met and the company faces extinction.
It's not elegant story craft, I'll say that right from the top. The threats to the hero are real but because of a lack of dimensionality in certain key supporting characters there are parts of the story that feel like short-cuts (there's a board member for instance that is walking-talking exposition and deus ex machina. But this book doesn't have to be elegant, it has to convey ideas that are coming at a crucial time for the IT profession. Because the profession has been fucking things up for decades. Not just causing all of the above problems, but failing to learn that those problems arise from our attempting to do things in outmoded ways that came about from the very early days before things had to scale. So while the "story" works in that it is at least partially based on a true story experienced by one or more of the authors, it's not the story-telling but the tales that matter.
And boy, do the tales drive a lot of punch. The characters here go about uncovering the various kinds of work being done in IT today, and why they all simultaneously must get done despite being mutually impossible: e.g. stable production, constant change, regulatory abeyance, scaling with business, and shrinking budgets. From this realization, they move on to discover that any change to process that doesn't address a bottleneck is wasted. From there, they move on to figuring out what changes matter and which don't. And from there they make the final realization: that one can't have separate development and production teams, it's never worked and it will never work.
Designed to introduce readers to the "DevOps" (Development-Operations) way of working, this book succeeds in illustrating the importance of our many error-prone ways and serves as a template for how to get to the next step.