The Pheonix Project is a novel about an IT manager that inherits an IT shop that can’t function without one or two key people, has deployments that are entirely unscripted and only quarterly, makes far too many break fixes and emergency patches, is buried in audit findings and basically sounds like 80% of the IT shops around (especially ones smaller than a few thousand folks). The “hero” of the book turns the IT shop around by embracing manufacturing like principles. If that sounds like it might be boring, it is. The main thing I learned from this book is to never talk about work on dates.
In three words: “Don’t read it”
The one exception is that this book can be useful if it’s read by an entire team. It’s been making its way around my company for the past couple months and now that most of us have read it, it occasionally encourages good conversation. A quick, “well, what if we think about organizing our change management process around one key resource, like they did The Phoenix Project” comes up from time to time.