Page Contents
Relatively speaking, I read a lot of books. I probably average about 2 books a month and have a healthy backlog of books I still want to read. You can take a look at my reading list to get a better idea of what interests me. That said, there are only a handful of books that I would put into an Information Technology (IT) Leader’s Must-Read list and The Phoenix Project is one of those books.
What is The Phoenix Project
The book itself is an IT Novel about a project called the Phoenix Project. So before I give you an overview, I want to share what “the Phoenix Project” is within the book. I think that sets the stage for why the book is so important and worth a read. So here’s the run-down.
The Phoenix Project is a project that is being ram-rodded into production by Marketing in an attempt to keep up with consumer expectations. The hope is that the project will stop their ever dwindling market share and save the company.
The project is millions of dollars over budget and over a year late. And unfortunately, IT operations, IT development, Security and Compliance, Marketing, and business operations are all pointing fingers at each other for why it’s late. Additionally, none of them have confidence that the upcoming “go-live” will go well.
Personally, I’ve been a developer, a data engineer, a manager, or a director on well over a hundred projects – probably closer to 200+ and am about 2 decades into my career. Of those projects, probably 75-85% have went close to plan, and the ones that went royally wrong looked a lot like The Phoenix Project – late, excessively over budget, and all because of marketing….just kidding about marketing. It’s only sometimes their fault. 🙂
A couple of other things that caught my attention. There is a heroic IT guy named Brent that seems to be the only person that knows anything about everything, and executives in the business know it. He gets pulled into conversations as a SME on security, development, database work, networking, hardware, and just about everything else you can imagine. And while he seems to be the one that knows everything, there is concern that his heroics and non-standard way of working are actually causing more problems than they solve.
Security seems to be focusing on things that are considered functionally irrelevant to the project, while trying to account for even the smallest possible threat. And everyone in IT abhors and avoids the change control process because it never seemed to work or add value.
And I’ll just say when the authors put this book together, they made sure when it rains, it pours, which also seems to be a common theme I’ve experienced over several years in IT. It is obviously a work of fiction, but there were many aspects of it that resonated with me and several different chapters and themes challenged my thinking and have impacted my current focus.
What is the book about?
!!SPOILER ALERT: I’m going to give the premise of the book away… Look away if you intend to read 330+ pages of nothing less than glorious IT fiction.
The Phoenix Project is subtitled, A Novel About IT, DevOps, and Helping Your Business Win. It’s a fairly long book with over 300 pages and an audio version that is a hefty 14 hours long.
The book starts out with both the CIO and VP of IT Operations for Parts Unlimited, the fictitious company in the book, being let go. The Director of Operations, Bill Palmer, gets promoted to the newly vacant VP role, somewhat unwillingly and a great deal of expectations are laid squarely on his shoulders. The CEO personally selected him, and asks him to get the IT organization in order. As if that isn’t enough, he has to get the Phoenix Project out the door, or risk being outsourced or worse, having the company picked apart and sold.
From chapter one through about the middle of the book things only seem to get worse. One problem seems to impact the next. When one thing seems to get course corrected, something else starts to cause problems. And all throughout the story there is fairly eccentric candidate for the board of directors who sort-of mentors Bill by drawing parallels between development and operations with lean manufacturing.
Around the middle of the book, Bill quits because of executive tolerance of poor leadership and a total disregard for the common sense recommendations he brings to his leadership. Don’t fret though, he comes back. There’s a kum-ba-ya moment that gets a little sappy, and he’s back in the game.
By the end of the book he’s started a different project, Project Unicorn, that focuses on how to improve internally, he’s found a way to protect Brent, and he finally gets the Phoenix Project out the door saving the company and landing him a sweet new position in the organization.
Who should read it?
Every leader in information technology/services, and any leader interested in influencing IS/IT processes. If you aren’t an avid reader, go get the audio version on audible and listen to it. It will be worth your time.
The story does tend to draw you in. I asked all of my immediate team members to read the book and have started to hear feedback. One read it over the weekend. Another mentioned they were several chapters deep and really enjoying the story line. I will say there are a lot of places in the story-line where coincidentally, the outcomes were overtly positive. In my experience there is a lot more randomness to outcomes in the real world, but the authors stayed within the realm of plausibility.
As you read the book, the three topics I highly recommend you look for are takt, the law of constraints, and the ways of work. I’ll touch briefly on the law of constraints because it was probably my biggest takeaway.
What is the law of constraints?
The law of constraints is basically described as follows: Within a process any effort spent on improving efficiencies on anything other than the bottleneck, is wasted effort. Think about that for a second. Whatever your process is, the biggest bottleneck is the one thing limiting your output and speed to deliver products.
One practical takeaway, of which there are many, is to first identify the products your team is responsible for delivering. Second, map out the process you use to deliver those products, and third, to relentlessly identify and eliminate bottlenecks in that process.
If deployments are your the biggest bottleneck, don’t waste time getting your developers to code faster. You’ll have lots of code you can’t get to market. That’s the IT version of inventory, and like inventory, it goes bad as soon as soon as your production environment changes.
What should I do?
Go get the book and start reading. Here’s a handy link you can use. Then come back here, Chester, and tell me what you learned. I’m really glad I finally read it.