Mike's Reviews > The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

The Phoenix Project by Gene Kim
Rate this book
Clear rating

This is the first book I've read cover-to-cover in an extremely long time. And what follows in this review are less my final impressions and more the way the book hit me as I dove into it. I still believe my criticisms are valid, but they have less impact on my enjoyment and my ability to absorb the interstitial lessons than I had expected. You are so forewarned.

As I'm reading the first few chapters, this book reminds me of my attitude towards the Agile Manifesto these days - "nobody understands how *hard* our job is - if only they'd listen - this is the bile-backed rant I'd give them - and everyone else will have to take a back seat to pitting the Developer's needs above everyone else's!" Yes I want to understand how you view the world, but when you take an extremely bitter and slanted view to everyone else's situation and needs, you aren't engendering a lot of sympathy from me in return.

I suspect for those who've been mired in the dungeon of the back office, underappreciated and never heard, this book is a godsend - "finally someone gets it!"

But here's a protip: if you cajole management (or any other players who aren't on your team) to read this, don't expect them to encounter their funhouse-mirror stereotypes in the book and make it all the way through with an open mind. Nor to wade through the pedantic, condescending lectures and be magically transformed into taking your side over everyone else's.

This is a lesson in managing up that I've learned the slow, hard way, and which I'm passing along as someone who's now part of the management layer: keep in mind that sometimes management hears you, even sometimes understand you, and *still* don't decide things your way. We generally have to take into consideration many competing perspectives, needs and constraints, and we often end up convinced of a different decision outcome than he one that most players want us to accept.

You might not like to hear that, and you may not sympathise with others' needs, and that's not something others can control. Don't like the decision?

Take a moment to imagine what other factors could have been more convincing (or constraining) *even if you don't agree they are important*. Chances are, most others in the organisation have just as unique a viewpoint as you, and rarely do they match.

The weirdest premise of the book that you're expected to swallow without question is that newly-promoted CIO-stand-in Bill, a previously mid-level-manager with no executive grooming, in a company where CIOs rotate every two years and whose initiatives are all aborted failures, will somehow be prepared for executive politics, know how to navigate the financial and interpersonal challenges at his new level, *and* will be wildly successful with this whole "DevOps" initiative than every other CIO initiative that preceded him (presumably some that even come from successful, highly experienced, externally-hired CIOs). Especially in an organisation so full of hostility towards any ideas that come from IT. When everyone around you treats you as the enemy, even objectively-successful initiatives are rarely recognised as "success".

Retroactive history-writing always goes to the victors of course, and they get to re-frame events however they like, so through that lens it's easy to see how Bill's choices are expected to be considered a deliberate winning strategy.

In the back of my mind, as they're setting the premise for how Bill will succeed at pulling the Phoenix Project from years-long delay into deployed and operational, I feel like asking someone, "Is this fairy tale grounded in any actual experience of pulling this off? Is there any reason for me to believe that by pulling the same levers Bill pulls, I too will have a great chance of succeeding at making giant software efforts live and breathe in production?"

And oh my gods are the condescending treatises thick in this book. For something attempting to read like a thriller, it takes on the start-halt style of Tom Clancy - no, more like Isaac Asimov - with stultifying regularity.

The tale of the complete clusterfuck in act one gets entertaining, but the authors lose all credibility when they create an excuse to drop a ridiculous deadline (that wouldn't be possible for an organisation 1/10 the size we're talking) on the team (and me knowing the punchline going in: our John Galt hero, knowing nothing of DevOps until now, invents, designs and implements perfect DevOps to turn a front-page disaster org into a model of efficiency and capability).


And YET, I found myself up 2 hours past my bedtime reading this sucker two nights in a row - which must mean despite all my protestations, there’s something compelling about the story that I’m not acknowledging in all my criticisms.

Friends of mine who I talked to at the halfway point said, “it’s not exactly high literature”, “the supporting characters are more like paper dolls” and “didactic fiction isn’t meant to be enjoyed as pure storytelling”. I feel like this is an exercise in voluntary indoctrination, and I think I still have too much of an ego to submit and immerse myself into someone else’s biased point of view, without a whole lot of reflection and complaints.

By about page 300, I've finally noticed that I can't stop paying close, willing attention to every discussion (to understand exactly what change is being discussed, and how that should impact the larger efforts) and worrying what new surprises will screw with our heroes' Herculean progress.

My friggin heart is pounding, I'm stressed on behalf of Bill and crew, and I'm dying to see the evil villain Sarah smacked down hard. Maybe dragged away in chains, or pilloried for the undermining, posturing and backstabbing.

It occurs to me near the end that without an antagonist of this magnitude, the story wouldn't have such a tight lock on my attention. Dammit, for all my complaints about how painful the writing is, I still end up reading it like a madman.

My final impressions? As much as I bitch about the structure and players of this book, I'm here having made it ALL the way through (a first for me in a looong time) and I'm genuinely excited to put many of the lessons into practice myself. As skeptical as I can be of cults of personality, overall I have gratitude in my heart for Gene Kim and his co-authors, and I'll likely be an advocate for this book to others who were in my shoes just one week ago.

=== Edit ===
Looking back on this a while later, I recognise this for what it is: a religious text, meant to convert the suggestible novices over to a growing cult, told not through historical truths but through a series of parables, believable to the willing.

I can see now that nearly none of the “lessons” in the book prepared me for succeeding in a DevOps world, other than to make me suggestible for further ideas umbrella’ed under the DevOps Banner. Maybe the “working, good, fast” principle? But I suspect that comes from any systems design discipline.

But it was a fun, fictional read.
12 likes · flag

Sign into Goodreads to see if any of your friends have read The Phoenix Project.
Sign In »

Reading Progress

April 21, 2014 – Shelved as: not-comics
April 21, 2014 – Shelved
April 21, 2014 – Shelved as: to-read
March 31, 2015 – Shelved as: found-via-meetups
January 7, 2017 – Started Reading
January 8, 2017 –
page 129
37.39% "Occasionally entertaining and informative, but too often condescending and one-sided."
January 8, 2017 – Shelved as: agile
January 9, 2017 – Shelved as: why-did-i-wait-so-long-to-read-this
January 9, 2017 – Shelved as: better-than-it-deserves-to-be
January 9, 2017 – Finished Reading

No comments have been added yet.