This review of the book The Phoenix Project will be the first in a new series on PackIT Forwarding. Earlier this year I realized that I hadn’t read any books without the Cisco Press imprint in quite a long time. This was one of the books that have so far made it to my reading list.
For a while now DevOps has been one of the buzzwords in our industry. The Phoenix Project uses an allegory to explain the concept and how it makes sense in the context of an “average” enterprise. The authors establish several stereotypical IT and corporate characters. Each one you will find yourself identifying as either someone like yourself or someone in your organization. Just like Dilbert, I was pretty sure that the authors had surveillance devices in my office building.
For me, I identified most with the character of Brent. Some would say he’s an example of a bad system administrator. They would say that he epitomizes the type of administrator that creates a fiefdom of power. While that definitely could happen, I would suggest that his character is the type that wants to get the job done. Brent is a pleaser, he wants everyone to be happy and to solve their problems. I would say that there are two types of Brents. The first would be the type that hoards knowledge and does create that fiefdom. The other would be the type that tries to spread the knowledge but is so busy that it’s easier to just do the work.
I’m definitely more of the second type which is both good and bad. In the book, Brent becomes the bottleneck for projects. Ironically at the time, I was reading the book I was that bottleneck for several projects. Try as they might, the project management office seems to always end up with several critical projects going live at the same time. In networking, this means that we have several projects going live at the same time as well because it’s always the network. I try to get ahead on project work, but sometimes changes at the last minute make for a lot of work at the deadline.
The Phoenix Project and DevOps show the way for removing people like I from being a constraint on delivering IT projects. From what I’ve learned so far though, DevOps really must be implemented holistically to work well. Trying to do it halfway probably will result in more problems. Even so, just being more aware of where I fit into the IT machine has helped me. I highly recommend anyone in IT read this book. It’s definitely a quick read and will pull you in. If you feel so inclined to purchase it, I would appreciate it if you used my affiliate link.
For those of you that have already read The Phoenix Project, who did you relate to most in the book? What did you learn? Comment below.