A Novel about IT, DevOps, and Helping Your Business Win
Gene Kim, Kevin Behr, George Spafford: Phoenix Project (2018, IT Revolution Press)
English language
Published 2018 by IT Revolution Press.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is the third book by Gene Kim. The business novel tells the story of an IT manager who has ninety days to rescue an over-budget and late IT initiative, code-named The Phoenix Project.
It’s a good way to introduce business and DevOps concepts to folks new to them from either direction. My biggest complaint is that in service of that mission, the storytelling plays out somewhere between a bad case of “plot armor” and “wish fulfillment”.
I don’t work in IT. I’m a data person leading a team at a large national political organization. But I was unloading all my problems (misunderstanding of data among org leaders, too many meetings, too much work, technical debt) to a technical mental of mine who insisted I pick up The Phoenix Project. While reading this book, I actively had to translate the IT jargon into something more relatable for my reference frame. Yet despite having no knowledge of IT or “DevOps” this book was a wealth of knowledge with tangible insights that I could take back to my team. I had many moments empathizing with Bill as he recovered from one crisis to another and battled various business and external challenges as well as “a-ha” moments as Bill learned to navigate his hectic workplace. Some of the books takeaways aren’t useful to me. Some I already knew. But if …
I don’t work in IT. I’m a data person leading a team at a large national political organization. But I was unloading all my problems (misunderstanding of data among org leaders, too many meetings, too much work, technical debt) to a technical mental of mine who insisted I pick up The Phoenix Project. While reading this book, I actively had to translate the IT jargon into something more relatable for my reference frame. Yet despite having no knowledge of IT or “DevOps” this book was a wealth of knowledge with tangible insights that I could take back to my team. I had many moments empathizing with Bill as he recovered from one crisis to another and battled various business and external challenges as well as “a-ha” moments as Bill learned to navigate his hectic workplace. Some of the books takeaways aren’t useful to me. Some I already knew. But if anything I felt seen — knowing that others deal with what I deal with, across industries, was enough for me
As a novel, this is as bad as it gets. The dialog is awful, the plot is nonsensical, and the characters are like bizarre cardboard cutouts; totally one-dimensional, yet totally unrealistic.
The message that the book is trying to get across may have been more impactful in 2013, but it feels like ancient history now in 2023. There are better books about DevOps that don't spend hundreds of pages telling a hokey story about why it's important.
One step above the typical corporate training video; sort of a casual primer on lean thinking and DevOps. Michael Crichton would’ve made it a lot more interesting.
Corporate fanfic where the Mary Sue uses the principles of DevOps to save the day. A relatively good intro to the underlying concepts though I found myself wanting a more formal text to accompany it. Which it turns out they wrote and is called "The DevOps Handbook", and the audible version includes the first few chapters, so guess what I'm reading next...
I find it very compelling, really.
Yes, the style and the entire narrative are somewhat absurd and reads like a bad 3-dollar novel you buy at the gas station (the ghost writers did some lousy jobs at times, NO ONE talks like that).
But if you swallow it a couple of times, you won't get mad every time someone uses the agile manifesto's language as a common office language... well, you will be onto something.
It is my second time reading this, after I've got into the PO/PM world some things are still a mystery to me. As the projects I was involved in were of average sizes, I've never dealt with the whole spectrum which defines Product Management as a discipline.
Still, 2-3 jobs later some parts become crystal clear.
p.s.
for a moment I hated the main protagonist - he was moaning like a retard about him losing …
I find it very compelling, really.
Yes, the style and the entire narrative are somewhat absurd and reads like a bad 3-dollar novel you buy at the gas station (the ghost writers did some lousy jobs at times, NO ONE talks like that).
But if you swallow it a couple of times, you won't get mad every time someone uses the agile manifesto's language as a common office language... well, you will be onto something.
It is my second time reading this, after I've got into the PO/PM world some things are still a mystery to me. As the projects I was involved in were of average sizes, I've never dealt with the whole spectrum which defines Product Management as a discipline.
Still, 2-3 jobs later some parts become crystal clear.
p.s.
for a moment I hated the main protagonist - he was moaning like a retard about him losing a job, yada yada.
this modern day slavery hooked up with loans, mortgages and small-time villages one calls cities - people force themselves into slavery by living above their means.
Damn I need the 'fuck you money' in my life too.
I find it very compelling, really.
Yes, the style and the entire narrative are somewhat absurd and reads like a bad 3-dollar novel you buy at the gas station (the ghost writers did some lousy jobs at times, NO ONE talks like that).
But if you swallow it a couple of times, you won't get mad every time someone uses the agile manifesto's language as a common office language... well, you will be onto something.
It is my second time reading this, after I've got into the PO/PM world some things are still a mystery to me. As the projects I was involved in were of average sizes, I've never dealt with the whole spectrum which defines Product Management as a discipline.
Still, 2-3 jobs later some parts become crystal clear.
p.s.
for a moment I hated the main protagonist - he was moaning like a retard about him losing …
I find it very compelling, really.
Yes, the style and the entire narrative are somewhat absurd and reads like a bad 3-dollar novel you buy at the gas station (the ghost writers did some lousy jobs at times, NO ONE talks like that).
But if you swallow it a couple of times, you won't get mad every time someone uses the agile manifesto's language as a common office language... well, you will be onto something.
It is my second time reading this, after I've got into the PO/PM world some things are still a mystery to me. As the projects I was involved in were of average sizes, I've never dealt with the whole spectrum which defines Product Management as a discipline.
Still, 2-3 jobs later some parts become crystal clear.
p.s.
for a moment I hated the main protagonist - he was moaning like a retard about him losing a job, yada yada.
this modern day slavery hooked up with loans, mortgages and small-time villages one calls cities - people force themselves into slavery by living above their means.
Damn I need the 'fuck you money' in my life too.
Reading this book felt like a dejavu. So many situations the authors describe have happened almost exactly as they describe them. We've made the same mistakes and hopefully have learned from them. It's very well written and relatable. Especially people who've not have worked for 20 years in the industry might find this an interesting read to possibly understand certain situations and avoid some of the mistakes we all use to make along our way.
As a novel, this book is horrible. But it's probably the best management book I've read. Although I've been working with devops for years, this book is an invigorating boost and a reminder of why devops is so important and why I should continue to always advocate it for my clients.
At times the management lingo in the book just makes me giggle, especially how business terms are used unironically by the characters in everyday dialog. But that doesn't matter - I couldn't put this book down. Particularly the first third, where the old way of working and the all-too-familiar downward spiral is so precisely described, is fantastic. It's like a thriller set in my professional world.
This book was also a much-needed reminder for me, as a developer, not to forget the importance of IT ops. Not to fall into the thought trap of putting development at the top …
As a novel, this book is horrible. But it's probably the best management book I've read. Although I've been working with devops for years, this book is an invigorating boost and a reminder of why devops is so important and why I should continue to always advocate it for my clients.
At times the management lingo in the book just makes me giggle, especially how business terms are used unironically by the characters in everyday dialog. But that doesn't matter - I couldn't put this book down. Particularly the first third, where the old way of working and the all-too-familiar downward spiral is so precisely described, is fantastic. It's like a thriller set in my professional world.
This book was also a much-needed reminder for me, as a developer, not to forget the importance of IT ops. Not to fall into the thought trap of putting development at the top of the value chain and IT ops at the bottom. New features are worth nothing if the existing features don't work.
The Phoenix Project is a seminal read on the accumulation of thoughts and processes surrounding DevOps as we know it today. The story is a fictional take on a workplace that is rife with unplanned work and misuse of the process. You might find it similar to something you see in your organization. It has some great insights and relevant stories you can apply to your own practices. In 2020, these things should be less and less relevant, but in fact, they seem to be more relevant than ever with COVID-19 and companies shifting more and more to the cloud with their digital transformation, demanding quicker time to market, just like Parts Unlimited in the book. The characters used in the book are great, and the protagonist gets the shake at the end. I can't help but think one of the characters, Wes, is a bit over the top. To …
The Phoenix Project is a seminal read on the accumulation of thoughts and processes surrounding DevOps as we know it today. The story is a fictional take on a workplace that is rife with unplanned work and misuse of the process. You might find it similar to something you see in your organization. It has some great insights and relevant stories you can apply to your own practices. In 2020, these things should be less and less relevant, but in fact, they seem to be more relevant than ever with COVID-19 and companies shifting more and more to the cloud with their digital transformation, demanding quicker time to market, just like Parts Unlimited in the book. The characters used in the book are great, and the protagonist gets the shake at the end. I can't help but think one of the characters, Wes, is a bit over the top. To summarize, it's a great read on how you and your organization can start thinking about bringing Development and Operations people closer together and get their decisions aligned, ultimately leading to more quality output and faster.
DevOps is gradually explained through a story. What an exciting way to describe a technical concept!
While reading this book, I was able to get the ideas and apply them to a real-world problem in my company: setup a continuous pipeline for automated testing and deployment. Now the cycle lasts for the whole day long is cut down to less than 30 minutes.
I dunno. It started out fun then became less fun.
Sounds like they spied on my workplace. I'm not fully certain, what exactly Phoenix meant to do, but that might be because I listened to the audio book and I missed some info due to not listening very closely all the time.
On the first night, when I opened the book, it was 22:30. I stopped reading at 1:00. On the second and third night, the story repeated. Luckily, the weekend came and I managed to get back lost sleep.
When I say exciting I'm not joking: The main character gets a sudden promotion from IT manager to VP of IT Operations in a big company ($4 billion per year). What he doesn't know is that the whole IT organization is completely crippled and he got the job is to get it healthy again.
Having to manage severity one incidents, doing weekend long deployments, getting impossible constraints and requirements from business and security are just a few of the obstacles that he encounters in his new role.
Various IT problems keep on appearing in the first part of the book. After that, things start stabilizing and you are rewarded with a happy …
On the first night, when I opened the book, it was 22:30. I stopped reading at 1:00. On the second and third night, the story repeated. Luckily, the weekend came and I managed to get back lost sleep.
When I say exciting I'm not joking: The main character gets a sudden promotion from IT manager to VP of IT Operations in a big company ($4 billion per year). What he doesn't know is that the whole IT organization is completely crippled and he got the job is to get it healthy again.
Having to manage severity one incidents, doing weekend long deployments, getting impossible constraints and requirements from business and security are just a few of the obstacles that he encounters in his new role.
Various IT problems keep on appearing in the first part of the book. After that, things start stabilizing and you are rewarded with a happy ending ;)
Although a work of fiction the book introduces various currently-used-in-IT concepts: kanban, the theory of constraints, DevOps, wait time is %busy divided by %idle, simian army, The 3 ways, the 4 types of work. People working in/with IT will appreciate the quick intro into DevOps and IT management. I doubt that non-techies will find the book interesting.
The idea that impressed me most was the comparison of the IT organization with a factory. Thinking back at my development experience, I observed that there are a lot more similarities between a factory worker and a software engineer than I'm comfortable to admit.
The main ideas are summarized at the end of the book. Along with them, you will also find the books (1, 2) that the authors used when building up the plot. I warmly recommend that you read at least this part of the book.
References
1) itrevolution.com/learn-more-about-concepts-in-phoenix-project/
2) itrevolution.com/resource-guide-for-the-phoenix-project-kanbans-part-2/
I'm a believer in the DevOps movement, and this book does a good job of illustrating the difference between a traditional IT operation and one that has implemented DevOps best practices. As a story, it's not that interesting, but that really wasn't the point of the book.
