Book Review: Phoenix Project

The Kinzua Kid is a Blue Collar IT guy, through and through; always has been, always will be.  That’s why I generally eschew management philosophy books and complicated process models that fail to account for the way people actually, well, work.  I find the literature harder to ignore these days because you’re automatically on the outs when you aren’t quote-battling in a conversation.  It drives me crazy, so I finally broke down and read The Phoenix Project by Gene Kim, Kevin Behr and George Spafford.

The great American novel, it’s not, but that’s not the point, either.  This one is all about a simple plot, straightforward characters and a step by step progression from failure to success.  It’s a parable in novel form.  As simple as this novel-ette is (can a 330-page, 10 point book really call itself a novel?) the story is an infectious read for any IT person.  One LA to NY plane ride should polish off this book for you.

The protagonist, Bill Palmer, is thrust into a sink or swim situation and must draw upon the talents of or do battle with a small but recognizable IT cast.  They include a politically ambitious executive, the overbearing CISO, the “hero” cowboy technician, an indecisive marketing team, a religious process architect, an abrasive operations lead, the incompetent developer and a soul searching CEO.  They are joined by a muse, the mystery man who seems to know IT Jiu Jitsu and waxes philosophical or practical in turns like an IT Miyagi.  Spoiler Alert: the good guys win.

What struck me about the book was twofold.  First, the stereotyped characters are hilarious because of their accuracy.  I’ve had the pleasure of visiting hundreds of large IT shops over the past decade and with the exception of the muse, every one of these characters is present, accounted for and described to a tee.  The authors have clearly spent time in the trenches, or at least interviewing the folks in the trenches.  While the setup was a bit overreaching (unless Bill succeeds, everybody will be outsourced) the actual problem on display was reasonable and happens daily in my experience.

The second striking component hit this Blue Collar IT Guy right in the gut.  In the end, the solution was on the manufacturing floor.  Dispel any illusions you might have that IT work is somehow different from manufacturing work; it’s not.  I’ve never believed that it was and this confuses the Kinzua Kowboy greatly, since the Kid frequently turns to the Kowboy for situational advice.  “I have no idea how this helps you,” he says, “I worked at a steel forge and assembly plant for 30 years, you’re in a computer room or something…how is that even close?”

They’re not close.  They are the exact same thing.

All of the conversation, messaging and product development surrounding cloud and IT Transformation thus far has talked about agility, process, instrumentation, elasticity and automation.  All of that is important but they’re the side buffet to the main course.  Servers get virtualized.  Portals get built.  Automation is developed and integration is performed.  All these verbs- virtualize, build, develop, perform…they’re all the same damned thing as stamp, press, bolt and paint:

Work.

When I talk about cloud and transformation, like I just did at the Raleigh CIO Forum, I reinforce the importance of changing business’ engagement with IT just as much as I do about IT’s engagement with the business.  When I helped build Legoland, I spent time every day trying to understand how every department worked and how IT intersected with that work.  When we execute a consulting engagement the first interviews we perform are with the business consumers of IT services.  If we don’t understand how work is done for both the business and IT, neither group is effective.  IT is a roadblock and the business is a fickle master.  It doesn’t have to be that way.  IT is the new manufacturing floor and once we master the flow of work from conception through completed product we have, in fact, transformed.  It’s a difficult transformation and no amount of cloud, automation or great technology will affect that change.  This transformation requires slaying a lot of sacred cows, starting with our roles in this endless tale.

I’m admittedly suffering from confirmation bias because the book clearly reinforces and articulates core principles I could not fully describe for myself until now.  That bit of business out of the way, I am emboldened to speak more openly about heretical ideas to my clients.  Why are you still buying desktops?  What’s wrong with IT “making a profit?”  Have you ever learned to say “no?”  Do we really need this process or security control?

I’m sure just asking those questions will be fodder for more interesting posts.  Hopefully, some of them are successful.  In the mean time, I’ve got to go.  Dad has a lesson for me on how they kept production moving when the drop forge seized up.