At a colleague’s recommendation I picked up a copy of “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” [Amazon affiliate link] months ago. It sat in my Kindle queue ever since – the last thing I was looking forward to reading most days in my free time was a “Novel About IT”. On a whim last week, however, I finally took a look at the first few pages and found myself coming back to it through the weekend.
“The Phoenix Project” is closely modeled after Eliyahu Goldratt’s “The Goal” – a famous business book that used a novel storytelling approach to get across the idea that a manufacturing plant’s bottleneck point is what most constrains the flow of production, and therefore the effectiveness of the whole plant. “The Goal” is well know for introducing Goldratt’s “Theory of Constraints” in a highly understandable way. Not only does “The Phoenix Project” model itself after the “The Goal” in structure, but it also translates many that book’s ideas from a manufacturing viewpoint to an IT focused one. In fact, the authors’ main argument is that in many ways the work of modern IT department should be considered much like a traditional manufacturing facility, and that many of the techniques that helped revolutionize manufacturing - such as kanban board, automation, managing the flow of work, focusing on reducing the impact of bottlenecks and constraints - can be applied directly to how IT work is done. Using these manufacturing-based methods to improve the “flow of work” can help us in IT transcend many of the limitation we take very much for granted.
One way that “The Phoenix Project” succeeded (almost too well) was in bringing to life many of the challenges and dysfunctions that are all to common in IT departments today. It then demonstrates how ideas from manufacturing, along with organizational techniques such as team-building and bridging across functional areas, can hope to transform this dysfunction. The story illustrates in a more real way what alignment between business goals and IT can look like. In this way, the novelization approach used by the authors succeeds in illustrating general concepts such as “IT/business alignment” and the more specific ideas behind “DevOps” to transcend the buzzwordiness one typically associates with discussions of this type.
Through the course of the book the protaganist, Bill, is led by his fictional mentor, Erik, to discover the 4 kinds of work that IT does – business projects, IT Operations projects, changes, and unplanned work – and the “three ways” to revitalize how his team can do that work better.
The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that’s what’s between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.”
The book introduces several ideas for improving the work of IT, many of which can be easily implemented at even an individual or a team level. Erik, in fact, challenges Bill to share what he’s learned to help others break through the all-to-common frustrations of IT work.
“Life in IT is pretty shitty when it’s so misunderstood and mismanaged. It becomes thankless and frustrating as people realize that they are powerless to change the outcome, like an endlessly repeating horror movie. If that’s not damaging to our self-worth as human beings, I don’t know what is. That’s got to change”
By illustrating in an easy-to-read manner how life in IT can be less stressful, the book sets out a vision for how this change can be achieved. Even if you are not a manager or director there are many good ideas to take away. All-in-all, an easy and worthwhile read.
os x 
