“The Phoenix Project” is an IT book in the form of a novel. The main character, Bill, is suddenly promoted and has 90 days to fix a giant mess. It reads like a novel – good characters, good story, good flow, colloquial language, etc. There are some stereotypes of different departments. And dismisiveness. For example, I recognized some negative perceptions against developers as a developer myself. But those exist in the real world and made it feel real.
The problems read like a case study in a tech or business book. Except that they are greatly expanded and tied together to make a story. For example, payroll breaks, everyone goes to Brent (their favorite IT person), they are in danger of credit card fraud, they have an external audit.
There's a list of characters at the beginning which I found myself frequently referencing. There were a few times where I needed to know who someone was that wasn't on the list. But it only impacted readability a small amount. I could have used more names or an org chart though.
Bill gets coached by a potential board member Erik and discovers the four types of work (business work, internal IT work, changes and unplanned work.) He also learns about the “three ways” (flow, feedback and culture.) I would have liked these to be spelled out at the end as a reference/review.
Reading how they got themselves to DevOps was fun. Early on, they implemented a change management system with index cards. They gated work to Brent. They created a new project (Unicorn) that actually used DevOps and could deploy frequently. At the end, they have DevOps, the cloud, got back to profitability, everyone gets promoted and they live happily ever after. Despite expecting that outcome, I enjoyed reading the story.
Throughout the book, there was a lot of office politics. At the beginning it was all over. At the end, it was just Sarah. But early on, I was actually tempted to put the book down over the high level of internal politics. Made them feel real though.
The book actually has three parts. And at the end of part one, Bill quits because he isn't able to be effective. He's back in part two with the ability to actually fix things.
I think this is a great book for someone discovering DevOps. Or for those along the journey and trying to sell it. Or for anyone who wants a light fun read on the topic.