Book review: the Phoenix Project

The Phoenix Project is a novel about IT management. Writing a fictional account is a powerful effective way to get the message across, used by others such as Ely Goldratt with The Goal. It is written by Gene Kim, Kevin Behr and George Spafford, the team who gave us Visible Ops, one of the more talked-about books in IT (I really must review that one day). I liked the book; you should read it, but I have a few big problems with it. The Phoenix Project is an important-enough book to warrant taking the time to discuss what those problems are.

The Phoenix Project is a runaway success: sales are booming. And Gene, Kevin and George are some of the nicest guys in IT. No wait, that's not a high benchmark. They're nice guys, period.

So if I criticise what is rapidly becoming a cult classic, readers are going to look at my own obscure works and accuse me of sour grapes. In my defense let me say (a) I had a proof copy sent to me and I wrote what follows before the book went on sale and (b) it's the IT Skeptic's job to hose down irrational exuberance. It's a good book which made my list of favourite reads, but that doesn't mean there aren't some fundamental issues that folk should think about. And judging by the reviews I've seen to date, they're not.

I decided I was going to speed-read my way through it - too many books in the stack - but I found myself actually reading much of it: it is well written, engaging. I wish I could write this well. It is as good as Jim Finister's Brandon Lane series.

The characters and situations are stereotypical, but that is not a criticism. The intent is clearly for us to identify with the people and events, for the Phoenix Project to be typical.

By being typical, it is accessible. Readers recognise their world; they relate. If some of those readers are not from IT operations, and better still not from IT at all, then that relating might translate to empathy which would be a fine thing.

So what didn't I like?

There are those of us who don't like allegory as a learning tool. I found myself thinking "this is fun, but I'm sold already". This could be a few pages of theory. It's a good story but not such a great story that I'd read it for its own sake.

Which brings us to the next issue: the modern world is impatient, we don't have the bandwidth for over 300 pages. This book could be 1/3 the size as an academic discussion. What is that book? I'd love to own it.

There are bigger issues with The Phoenix Project. Fictionalising allows you to paint an idealised picture, and yet make it seem real, plausible. Skeptics know that humans give disproportionate weight to anecdote as evidence. "It worked for Mum". "My auntie saw a ghost". Bill Palmer saved the Phoenix Project. It is an almost unfair tactic, that one might resort to if one were evangelical about something, wanting to sell it without having to resort to rational debate. Adopt manufacturing techniques and you too can be a hero. The superhuman Erik can't be wrong.

The book is there to sell, not to reason. [The reasoning comes in the follow-up book, the DevOps handbook, which I eagerly await.] It is pure Hollywood, all American feel-good happy endings. An American movie wants you to believe that cars can jump and still be drive-able, that shooting people solves problems, that the nice homely guy gets the girl with a few heroics, that a hug from Mum erases the trauma of a child being kidnapped, that you can take a bullet or ten plus multiple blunt trauma to the skull and still be relaxed and laughing in the finale. The Phoenix Project wants you to believe that within weeks the staff are complying with the new change process, that business managers are taking no for an answer, that there are simple fixes to complex problems. Heck there is even a mystic sensei who magically appears (with explicit references to the Karate Kid); our hero is an ex-Marine who just wants to be a good Dad; the psycho CEO has a road-to-Damascus conversion; the anal security bastard gets drunk once (another classic Hollywood solution) and changes his lifetime ways; a small team automate multi-environment builds and application deployments in a few weeks during a crisis; all the answers are found in the ancient wisdom of the manufacturing plant; the whole IT culture is transformed in months; and [spoiler alert] the baddie gets hers in the final reel... Sorry but it is all too good to be true.

I found myself longing for a European twist: I wanted Bill to yell at his kids, John to commit suicide, Sarah to bed Steve and crush everyone else, or Paige to walk out forever. I wanted the Phoenix Project to still be crashing at the end and Brent to move on to a better job offer.

There are other things I do like:

The book is packed with good ideas from various disciplines :

• Kanban boards
• WIP up means delivery performance down
• Wait time is proportional to percentage busy
• Protect and elevate your constraint
• kata
• The Three Ways
• The COBIT goals cascade (though they don't call it that, they call it "magic glasses")
• Agile
• Chaos monkeys
• ... and of course DevOps automation

Speaking of evangelical zeal, the book's only acknowledgement of service management is to talk about a failed ITIL implementation of change management (which makes the most classic of errors of having no standard change). Many of the good improvements Bill makes are pure ITSM but you don't hear that. Many of the good ideas of ITSM could have been presented here too. This won't help bridge that DevOps-ITSM gulch.

I know it sounds smug and I shouldn't say it, so please forgive me but I can't resist: I found it gratifying how much the book lined up with some of my past favourite concepts that I have promoted:

1. Dead Cat Syndrome, with the need for operations to maintain an 'outreach programme' to embed NFRs in standards, templates and system designs (see ITIL Service Design)
2. Eating ourselves: manage by service portfolio (which take a balanced view encompassing both projects and BAU) not programme portfolio (which only sees projects not BAU). Though the book doesn't explicitly call it service portfolio, even though that's exactly what it is.
3. Dysfunctional relationship between business and IT. The book describes it as a bad marriage, I described it as bad parents. I still think the business is senior and responsible for providing guidance, it is not a peer partnership between IT and the rest of the business. (Once again a lot of the stuff in the book could have come out of ITIL Service Strategy).
4. Incremental improvement based on an agile, Scrumban approach: Tipu CSI (yes ITIL is weak here)
5. Factory floor approach where it fits, and empowered knowledge workers where it doesn't; Standard+Case. Actually this is another issue which can wait for another blog: the book is way too zealous about the applicability of factory-floor techniques to IT. There is potential still to be exploited there - hence I say read this book - but we can go too far with the application of Lean, TQM, Six Sigma etc to IT. It is different, even though the book demolishes that suggestion. When someone of the calibre of Charles Betz says "IT solution development and service delivery are more variable than stereotypical manufacturing processes" I listen.

But here's the biggest problem I have with this book. There's another of my Favourite Concepts that's not there, the most important one of all: He Tangata, IT Is the People. Despite the story being told wholly through conversation and introspection, and despite the politics it describes and a few hints of leadership methods, none of the answers are about people or culture or behaviour. They're about tools and techniques and processes. I simply don't believe that introducing new THINGS changes people. Where are the education, collaboration, communication and motivation activities? Bill doesn't even work to transform his direct reports and colleagues: he just stays strong and silent and issues orders like the ex-sergeant he is. Wes magically sheds his tech cynicism. John must have a fairy godmother to make him over so quickly without any apparent cause. Then there are all the other staff - barely mentioned - who accepted a new manager instantaneously and leapt on board new ways of doing things without a peep or hiccup. Bill doesn't have to take anyone on a journey of cultural change: he just throws a bunch of Hollywood-style quick fix magic things at them and the sun comes out. IT is far too believing in the myth of "things as solutions" and this book doesn't help. To paraphrase a mantra oft repeated in the USA right now; "Things don't fix people. People fix people." Things just make it easier. Things facilitate: they don't do. Balanced Diversity is one of the most important things to happen to IT in years. It deserved a role.

I enjoyed reading The Phoenix Project more than I thought I would, and spent more time on it than I intended, and got lots out of it as I expected I would. It is a powerful book that will get lots of attention, spread some really useful ideas, and promote the Devops cause.

Read it. Learn from it. Just don't fall for it.

They kindly sent me a proof copy to review. Guess they won't do that again. Sorry guys.