The Phoenix project is allegory: fiction that is intended to teach us about the real world. It’s the story of Bill Palmer, an IT Operations manager at a company called Parts Unlimited who is suddenly promoted by the CEO and given the high profile responsibility of turning around Project Phoenix, an over-budget, under-resourced waterfall disaster, while making sure nothing else is disrupted. The “nothing else is disrupted” part is particularly difficult because something seems to go wrong with every change to every system in the business.
I am very fond of this book, having learned some foundational lessons from it. The worst I can say about it is that it doesn’t feel as believable as a “real” novel. I imagine that the allegory forced some less believable moments into the story.
Nonetheless, as a software engineer I found it both gripping and highly stressful. Bill Palmer’s marching orders are more or less, “do better than your frequently changing predecessors, with no extra budget or people. Don’t screw up”. The situation of someone who doesn’t understand tech wanting better results from the same inputs is a familiar one (albeit a little distant from my current job).
This brings me to a possible weakness of the book these days: In the first few pages I thought: “I push to github and then CI runs, and then my code gets deployed”, and, “I can barely remember the last time an IT Operations person was in charge of deploying my code”. I wondered if the book was really relevant. I pushed through because it came highly recommended by people who have inspired me in the devops space.
Later on I realised the importance of the book:
First, I sometimes have to communicate with business types from an older world who haven’t experienced IT in a company that embraces devops culture. For instance when there is an outage, or I spend time gathering metrics and talking to users to diagnose bugs I might be asked, “Where are the IT Operations people?”
For this case, The Phoenix Project has given me some good answers: separating Development and IT Operations teams creates artificial conflict between delivering new features and living with maintenance of the current features. The reality is that writing software is new features AND ongoing maintenance, there should be a cyclical (deploy/learn/improve) relationship between the two, and if you don’t have the same people doing all of the above, you hurt your capacity to do any of them.
Second, Devops culture is something we often live in without understanding its value, and we can easily give up some of the important values of devops culture because we don’t understand their importance. An example could be splitting your team into bug fixers and people who write new code. The Phoenix Project has helped me understand that this strategy would break valuable feedback loops, separate team members and hurt collaboration.
Put another way, The Phoenix Project teaches the values of devops culture, and I still need to understand those values even though technology makes some aspects of Devops much easier.
Finally, I have some experience of life before agile and Devops, but I was too inexperienced to draw good conclusions. The Phoenix Project helped me reflect on those times and reframe my experience. Here is an example from my early career of Bad Things that happened, which I now undestand as The Opposite of Devops. (If you’ve never experienced software development without feedback loops like retrospectives and technology to automate releases and monitoring, reading that post may help you relate more to the book)
More recently, Gene Kim has written The Unicorn Project, which I understand as an attempt to locate the same story inside a modern software development context. A review will happen when I’ve finished it.
I highly recommend this book.
subscribe via RSS