Book review: The Phoenix Project

A business novel about IT operations, with a title that sounds like a failed ERP rollout. I did not have high hopes for The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. Three different people recommended it to me in the same month so I gave in, and then read the whole thing in two evenings, which I suppose says something.

Bill Palmer is an IT manager at Parts Unlimited, a car parts company losing to its competitors. On page one he gets abruptly promoted to VP of IT Operations because the people above him have been fired. The company’s future is riding on Phoenix, a huge, late, over-budget software project that’s going live in a few weeks whether it’s ready or not. Meanwhile payroll is broken, the auditors are circling, and every outage somehow ends up on the desk of one engineer called Brent. Bill gets a mentor in Erik, a prospective board member who keeps dragging him onto the factory floor and asking annoying Socratic questions about manufacturing.

The thing that stuck with me most is the four types of work. Erik makes Bill figure out that IT does business projects, internal IT projects, changes, and unplanned work, i.e. firefighting. The unplanned work never shows up in any plan and it quietly eats everything else. After reading this I tracked my own team for three weeks, and unplanned work came out at about 40% of our time. I’d have guessed 15.

Then there’s Brent. Every company has a Brent, the one person who knows how everything really works, gets pulled into every crisis and so never has time to write anything down. The book is good on how he’s a symptom of the organization depending on one person’s head. The fixes it proposes are dull and correct: protect his time, make him teach instead of fix, stop routing everything through him. I’ve been the Brent on a couple of teams. It feels great right up until you want to take a vacation.

The rest of the big ideas come straight from Goldratt’s The Goal, which this book is openly imitating: limit work in progress, make the work visible, find the bottleneck. Erik’s “Three Ways” (optimize the flow of work from dev to ops to the customer, build fast feedback loops in the other direction, and make experimentation and learning from failure normal) is the best short explanation of “DevOps” I’ve come across, which is a word I mostly hear used to mean “we bought Puppet”.

It is a novel written by consultants and boy can you tell. The dialogue is wooden, Erik is a magical guru who exists purely to deliver lessons, and the villains are cartoons. The ending is way too tidy. Once Bill gets the principles right the company goes from disaster to deploying ten times a day in what feels like a few months, and anyone who has actually tried to change an organization knows it doesn’t move that fast. It’s also very much about a big traditional company. Change advisory boards and hostile auditors aren’t problems a 20-person startup has, so you have to do some translating.

I’ve already lent my copy to a non-technical exec. It explains why “just add one more project” doesn’t work better than I’ve ever managed to.