English language
Published Oct. 16, 2014 by Paperback.
Bill is an IT manager at Parts Unlimited. It's Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
The company's new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill's entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone …
Bill is an IT manager at Parts Unlimited. It's Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
The company's new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill's entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they'll never view IT the same way again.
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.
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.
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.
I am working in IT, but not in a corporate environment. On the one hand, I got the feeling that I recognized certain things. On the other hand, I found myself often wondering why I would be listening to somebody else's (fictional) work-related problems in my free time.
Someone recommended this to me and I got it for free on Kindle, so I thought I give it a go.
I kind of like the concept of a novelized version of a DevOps book.
I also liked the main characters and the general setup. It seemed a bit weird that a lot of best practices seemed completely unknown in the fictional company, but I guess this might also exist in the real world.
For most of the book I was question myself why I would even read it, it is close enough to what I had to deal with in some of my jobs and I don't really find my life exciting enough to be made into a book.
One of the problems I see is how rapid change is shown in the book. A very large company is turned around in less than a year and this is …
Someone recommended this to me and I got it for free on Kindle, so I thought I give it a go.
I kind of like the concept of a novelized version of a DevOps book.
I also liked the main characters and the general setup. It seemed a bit weird that a lot of best practices seemed completely unknown in the fictional company, but I guess this might also exist in the real world.
For most of the book I was question myself why I would even read it, it is close enough to what I had to deal with in some of my jobs and I don't really find my life exciting enough to be made into a book.
One of the problems I see is how rapid change is shown in the book. A very large company is turned around in less than a year and this is even managed in spite of the awful internal company politics.
As an IT/education guy, this story stressed me out with a constant, "OMG! This situation is insane! What are they going to do now?" The story is good. If this book was just about the story, the details needed a bit more fleshing out. As an introduction to DevOps, this book is outstanding. I've already had a few discussions with folks about the theory of constraints, the three ways, and technical debt. I'm not sure how the knowledge from this book will affect my management, but I'm sure it will.
