The Phoenix Project (book review)

There are a lot of books which you read and then you later forget about, or in my case I even forget who are the main characters midway reading the same book.

This book is not one of them.

Despite that the authors could have cut down a little from the over-drama to avoid a lengthy book, their choice of narration in a style that matches a fast-pace action novel makes one hell of a way to explain the idea of DevOps and how the structure of an IT department should never remain the same in any traditional company.

The book narrates the fictional story of a man named Bill Palmer (main character) who gets promoted to VP of IT operations in a fictional company called Unlimited Parts that manufactures and sells auto parts across the US. Bill picks up the leadership of a battered department that is being accused as the source of all failures, inefficiency and negative publicity that this company is facing. Bill leads the department through a series of IT disaster events such as failing servers, failing deployments, and even failing leadership. Along the way, he learns The Three Ways, and he transforms the IT department that integrates well with the company business goals. Some of the concepts that Bill learns and experiences along the way include applying the theory of constraints where he learns how to improve his process and reduce bottlenecks and constraints. He also learns how to classify his departments types of work and he guides his team to reduce the work in progress items and implement a kanban board. There is a chapter as well where the upper management do a session of vulnerability sharing inspired by the book, the five dysfunctions of the team.

Eventually Bill brings his department from the end of the line and engage them early in the process with the Developers team to iron out all deployments, testing and ops work from early on in the process, so there’s less firefighting, and their huge work items are reduced enough that they can focus more on the other departments business projects and create guarantees of delivery.

This book is a great primal for anyone who wants to understand DevOps and the concepts behind it and how it relates to the factory floor. For many engineers in some companies, they are already a team that practices these concepts, but for some it can even give you further context why these practices are helpful and what it takes to reach there, especially for companies who are in the traditional model of IT.

This book is followed by the DevOps Handbook (I haven’t read this one yet) by the same authors, who dig deeper in the concepts mentioned in Phoenix Project book and talk about how to integrate Product Management, Development, QA, IT Operations, and Information Security.

Originally written in September 2018. Reposted from a private blog.