****** Non-Spoiler Alert ******
If you’re reading The Phoenix Project and are sitting on the edge of your seat, just waiting to know the outcome, then…feel free to keep reading this post. This is a novel about IT, and there’s certainly no reason to think it doesn’t have a bit (or a lot) of fantasy to it.
With that in mind, on to my review of The Phoenix Project…
***************************
Whenever I read a book review, especially if it’s from someone that provides recommendations I trust, I really just want to know one thing; should I spend the time and money and invest in the book? With The Phoenix Project, I give a hearty “yes.” I will warn you though; if you’re looking for a book to help guide you through the current trending buzz of DevOps, then this isn’t the book. I’ll admit, I was disappointed that the novel only hit on DevOps for the last few pages, and even then it referenced it more as a possibility in IT. It was courteous of the authors to put in a segue way to another book, The DevOps Cookbook, but if you follow anything from Gene Kim, then you probably already have a good idea about DevOps anyway. I’m sure the letdown came more from a recent local DevOps MeetUp in which I asked where I could learn more about DevOps, and The Phoenix Project was the #1 recommended book.
If you want a novel on how to apply methods in The Visible Ops Handbook, another book by Gene Kim, George Spafford and Kevin Behr, then you’ve hit on the right novel. As I read The Phoenix Project, it was obvious Kim, Spafford and Behr were taking the reader through a Visible Ops transformation from start to finish. In the first few pages of the novel the authors took every dysfunctional IT department cliche, and put it into a single corporation. This is where I started to feel like I was reading Fifty Shades of Grey. Sorry, there’s no weird kinky scenes in the book, but as someone that has heard about the writing in FSOG (honestly, I have not read the book), E L James took every woman’s fantasy and put it into a single male character; smart, very wealthy, never working, and with lots of time to devote to a single love interest. FSOG contains a lot of unrealistic scenarios (and some realistic, but I’m not going there) that just places the reader into a fantasy land. The Phoenix Project pretty much does the same thing with how a corporation goes from being the most dysfunctional IT entity to have ever existed, and in the course of three months, becomes a leader in innovation and is in a position to upset competition. Unlike FSOG, The Phoenix Project doesn’t have any reference to whips and chains, even though those are commonplace tools in IT. Of course, at the end the main character is put into a position to be groomed to enter the C-level world within the corporation. While I know the general message is to promote the trend that IT is to meld with the business and it’ll probably happen as more IT leaders move into the business world, there’s definitely an appeal to my personal ego that someone would one day recognize my genius and give me an opportunity, a mentor, and political clout to go and cause a revolution within an organization. It’s an awesome fantasy and one that I’ve had well before this book.
The one final comparison of The Phoenix Project with Fifty Shades is the writing. The authors are really smart guys, and they certainly did not have a writing method reminiscent of the 7th grade style I’ve heard is commonplace in FSOG, but at times, it did feel like some dialogue and explanations were created for a less experienced audience. Between the highly descriptive technical explanations from one character, to thoughts from the narrator, this book does a great job in explaining IT and processes, but if you’re reading it before bed I’ll warn you that it’s possible to fall asleep. I understand though, terminology and concepts need to be explained in case the reader simply doesn’t know.
The characters themselves are quite interesting. Once again, I have a comparison to make, and this time it comes from the Haggadah, which I get to read every Passover (which is, incidentally, within a week – חג שמח). In the Haggadah there are four sons. One is wise. One is wicked. Another is simple. The final son simply doesn’t know what to ask. In The Phoenix Project, There are four main characters that fit these personalities perfectly. Believe it or not, the main character, Bill, is more of the simple one, with needing his mentor to take him through finding the faults in the department. Bill’s closest co workers, Patty and Wes, definitely fit in as the wise and “don’t know what to ask” sons, respectively. Patty is always the person that immediately picks up on the concepts and just seems to “know what to do,” while Wes really seems to be there more for a bit of realistic comic relief (we all know those kind of people). The final “son” is that of the primary antagonist, Sarah. Sarah is symbolic of “the business” that doesn’t understand how to efficiently run IT, always pulls resources in for “shadow IT” projects, and ultimately represents the aging business perspective that IT is subservient to the rest of the organization. I’m sure everyone in IT can identify at least one Sarah type of person, maybe even several. Unfortunately, often these people are the ones that stay on top, preventing IT from becoming that strategic partner as outlined in The Phoenix Project.
When I started this review, I gave an absolute “yes” to the purchase, and here’s why: As The IT Skeptic outlined in his own review, the book is a great selling tool. Could a company follow the exact same timeline as that shown in The Phoenix Project? Probably not. But everyone can identify with the dysfunctions shown in the book, and there are several current methods that are explained to have positive results in helping with transformation. Many of these are brilliantly illustrated in The Phoenix Project, and there are even examples on how an efficient and effective IT department can run. Not only that, but if a director or VP reads the book, identifies with the dysfunction, there’s hope that there can be some political push for improvements. It’s not likely, but it could happen, and I’m assuming that’s why The DevOps Cookbook is published by a company with “revolution” in its name.
While I’m a little late to giving a review, I’m still happy for the purchase and am excited to continue on with my DevOps journey. There’s now inspiration to read The Goal, and eventually move on to The DevOps Cookbook. Who knows, maybe I can reference Hunger Games and Christmas in the next post?
Comments