The Phoenix Project - A Novel About IT, DevOps, and Helping Your Business Win


Gene Kim, Kevin Behr & George Spafford




IT Revolution Press

The Phoenix Project - A Novel About IT, DevOps, and Helping Your Business Win

If you had ever told me that I’d enjoy a book following the fictional tale of an IT manager’s valiant efforts to restore order and productivity to his department, I’d have laughed in your face. Somehow, though, The Phoenix Project managed to be not only enjoyable, but engrossing and educational! Honestly, I’ve sat through quite a few “leadership development” lectures on project management, agile processes and the like, but none of them really captured how critical these processes can be across the entire product pipeline or how you can go about implementing them from scratch. I’ve heard the term DevOps being thrown around quite a bit, but just assumed it was yet another buzzword management likes to claim we do. Of course, it is a buzzword, but as this book demonstrates, there’s some substance behind all that management mumbo jumbo.

The best part is that it all fits very well next to the agile processes I’ve embraced throughout my time in software. In fact, I would argue that several programs I’ve had the fortune of working on have been using a watered down version of DevOps as part of their agile process without needing any buzzwords to validate it. We were able to embrace rapid deployment processes mostly because our software engineers (such as myself) were also our IT engineers since we had no dedicated IT Operations department. So we naturely opted to automate as much of our recurring work as possible so we could focus on development. Unfortunately, the challenge we always ran into was getting buy-in from other departments (-ahem- security and QA -ahem-) to complete our deployment pipeline. More often than not, they agreed the improvements we wanted would be great, but no one was willing to foot the bill for them.

The Special Sauce

What makes The Phoenix Project unique compared to other books covering similar topics is that instead of telling you about the three ways of DevOps, it shows you them. The book follows Bill, a former Marine, who was content in his lowly IT manager role before being promoted against his will to VP of IT Operations. Our reluctant hero then proceeds to face struggle after struggle as he tries to save his department from being outsourced and dig his company out of the downward performance spiral its stuck in.

During Bill’s journey, he encounters the usual list of suspects. There’s leadership that ignores Bill’s concerns and continues demanding full steam ahead on doomed projects, the brown-nosing co-worker that makes everyone’s lives miserable but the boss unconditionally loves, and the CISO who only manages to bury the team deeper in work without providing any real value. There’s the development team who fails to work with IT to make sure IT can support new deployments and a common hatred across departments of the IT department that is constantly at the heart of every failed project. Bill, however, isn’t completely on his own. He has the Yoda-like support of a DevOps sage, Eric, whose fondness of riddles drives Bill up the wall. Eric lends an ear to Bill’s problems and constantly takes him on trips to a manufacturing plant that has it’s shit together to help him see the light.

Through it all, Bill manages to gain the trust of his peers, build an innovative team, and put in place a process that helps his team win. There is no 10 step process to success. Bill stumbles his way through the three phases, implementing pieces and parts along the way. You also get a taste of Bill’s homelife, the family that keeps him getting up and going to work each day. By the end, I found myself properly rooting for Bill and invested in his success.

The Meat and Potatoes

At the core of this book is “The Three Ways” of DevOps. While the ways are worked through abstractly in the book with each hurdle Bill jumps, the final chapters officially codify it for the reader. I wrote a separate post outlining these principles here.

It became clear while reading The Phoenix Project that following “The Three Ways” alone is not enough. Bill’s efforts to implement the Ways ran into several road blocks. Leadership and co-workers were constantly undermining his efforts due to lack of trust in his leadership. It took drastic measures by Bill to get the CEO, Steve, to pull his head out of his ass and take a different approach with his team. A lack of trust between leaders, seeds a lack of trust between their teams causing chronic underperformance and strife. There had to be a culture shift towards trust before Bill’s efforts could really start taking off.

A Special Shout Out to John the CISO (Chief Information Security Officer)

Being the InfoSec enthusiast that I am, I couldn’t help but focus on John the CISO’s role in The Phoenix Project. He fell victim to a common mistake made by many InfoSec teams: a focus on compliance rather than the organization’s needs. He was constantly harping on development and IT about the thousands of security tweaks that needed to be made before they were audited. Most of these tweaks had little impact on how secure anything was and cost hundreds of man hours to implement correctly. Then when the audit actually happened it turned out that many of his concerns were already mitigated by different processes used in accounting or other departments.

John’s journey is perhaps the most this book strayed from realism (or rather took some artistic liberties). He actually ended up suffering a mental breakdown when confronted with how useless he was in his job. After this breakdown, he returned to work with a completely different personality now conducive to DevOps. This seemed a little harsh to me, but regardless it did paint a night and day picture on a CISO wasting everyone’s time versus actually being a productive member of the team. The new John went around interviewing key stakeholders within the company, from the CEO to marketing, and asked them what a good day vs a bad day looked like for them. With that information, he and Bill could determine where IT was hurting the company and what their primary goals needed to be for the organization as a whole to win.

This really resonated with me as one of the turn offs of some InfoSec jobs has been the fear of being in a job where I am just running through checklists and pushing out patches everyday. For each checklist item pushed on an organization, the InfoSec team needs to be asking the “who what when where and why” of that item. The risk that that item is intended to mitigate may already have been sufficiently mitigated somewhere else making the effort to implement and maintain that item a waste of time and resources. Additionally, if the team is focused only on completing checklists and passing audits, it is likely that they are overlooking huge security gaps in their infrastructure that there isn’t a checklist item for. I appreciated this being called out in The Phoenix Project as I’ve seen it over and over again in industry.


Throughout my 10 year career I have worked as a web developer, systems administrator, software engineer, security analyst and now cybersecurity engineer. I currently develop software applications to automate security vulnerability and compliance scanning and reporting for a multinational financial institution.