Novels of IT: The Phoenix Project

Nerd alert: it’s an exciting day for me when someone releases a new “novel of IT”. I’ve made it my mission to find and review several of these (now four) over the past couple of years, and I may be one of the few people out there who has read and reviewed all of them.

To recap: what do I mean by a “novel of IT”? It’s a term I coined to describe a fictionalized depiction of life in a corporate IT environment, usually bearing a number of intended lessons in tow about IT best practices, approaches, pitfalls. They’re generally not works of serious fiction; their audience is usually the lot of IT professionals rather than the broad public. (For example, I don’t include in this category two fine and recommended works that in fact aspire more to literature than to IT didacticism: Douglas Coupland’s Microserfs and Ellen Ullman’s The Bug).

As I’ve traveled through the fictional scenarios depicted in these four books, I’ve evolved criteria for what makes them successful (or not) in my eyes. In a novel of IT, I’m looking for a book that is both reasonably engaging as a novel and one that accurately portrays a broad swath of the inner workings, nuances, and personality types that are typically part of the landscape of IT in today’s world. Reading the book should provide a window into common dilemmas and disagreements regarding IT issues, lending perspective and insight into all parties’ motivations and interests.

I looked forward for many months to the release last week of The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford,  after meeting and chatting with Gene Kim at a conference back in May of last year. I was greatly impressed at the time with Gene’s general demeanor, enthusiasm, and articulateness. He gave a rip-roaring presentation at the conference on “ITIL at Ludicrous Speeds: Rugged DevOps”: I recommend seeing him speak if you get the chance. I felt certain that his long-promised “novel of IT” would be a worthy addition to the collection of works in this category.

And I wasn’t wrong. In fact, as the cliche goes, I couldn’t put the book down. It’s the longest of the four novels I’ve covered here, but it’s by far the most gripping and cohesive read. Paradoxically, even though the characters often come off as stereotyped and oversimplified, they still ring true: I guess one could say that the IT world is unusually replete with cliched and oversimplified characters even in real life. We’ve all met and known colleagues throughout our career that map directly to the people in this book. Thematically, the book’s thrust is to show how the Theory of Constraints can be adopted to bolster IT success, implemented via techniques such as DevOps, Agile, etc. It’s extremely unified and cogent and articulate in how it shows the background rationales and the success that can come from adopting those approaches.

I feel as if the authors have been peering in the windows of my career, scribbling notes.

Equally, the book is gratifyingly right-headed on so many important factors that influence IT success or failure: most notably, the key issues of managing work intake, technical debt, resource allocation, capacity and demand. What’s more, the incidents it describes are downright painful, yet in a cathartic way: I feel as if the authors have been peering in the windows of my career, scribbling notes. My copy is highlighted throughout with examples of true and eloquent insights about IT management. I both learned from this book, and had many of my existing learnings affirmed. Just one example:

“You guys in the business are punch drunk on projects, taking on new work that doesn’t have a prayer of succeeding. Why? Because you have no idea what capacity you actually have. You’re like the guy who is always writing checks that bounce, because you don’t know how much money you have and never bother opening your mail.”

But for all its strengths, there are notable irritations about the book as well: first, the entire action of the novel takes place in an incredibly unrealistic mere three months, taking the company of Parts Unlimited from unmitigated IT disaster to essentially a fine-tuned machine, and even seeing its IT protagonist, Bill Palmer, elevated to the position of being groomed to be COO, due to his success in turning IT around. Granted, that’s part of what Nabokov called the “easy swing of a well-oiled novel”, but here the extreme time compression can foster the false sense that the answers to the IT crisis are simple and quick, if only people would wise up.

Second, when it comes to wising up: a lot of the insight and enlightenment that brings Bill to his success emanates from the “wise guru” influence of the elusive and eccentric Erik Reid, described as little more than “potential new board member” and “technology hotshot”, who pops up at sundry key intervals in the novel to pose some Socratic questions and then disappears while Bill puzzles over their answers and stumbles his way towards solutions. This isn’t an uncommon technique in these novels of IT: FruITion, of course, is the most annoying and unrealistic case: its IT characters are little more than dolts, and there the external wisdom comes from the sage and apparently infallible strategists elsewhere in the business, who chortle at being able to “turn the tables” on “those bastards in IT.” But Haunting The CEO does it too: it features Carol Lee as the wise and seasoned CIO advisor, guiding embattled CIO Brian Kagey to enlightenment on IT management issues; Adventures of an IT Leader has the enigmatic “kid in the bar” regularly offering new CIO Jim Barton advice over drinks. (The kid, of course, then turns out to be a zillionaire board member of Jim’s own company. Of course.)

Hey, I’m as much in favor of mentoring and seeking solid advice as anyone, but the suggestion in such novels, implicit and explicit, that there are people out there (if only one would listen to them!) with ready-made, fluid answers to the very real, complex dilemmas confronted by IT is ultimately absurd and insulting. It’s turning messy, thorny IT leadership issues into little more than a parable of Mr. Miyagi. In the harsh reality of IT/business trade-offs, things are rarely that simple, and never that quick.

In fact, one of the criteria I’ve evolved for these novels is that I look for nuanced presentation, not pat answers that amount to a “one true way” advocacy. (In The Phoenix Project, the one true way consists of Three Ways, but I digress). I’m looking for realistic situations and conversations that expose the important IT nuances and dilemmas without simply pointing fingers of blame or positing quick fixes. But in this novel, the SVP of Marketing really is evil, and the Chief Information Security Officer really is foolish and tunnel-visioned. That suits the goals of the novel, perhaps, but it doesn’t satisfy my desire for a nuanced presentation.

So let me make my own nuanced and balanced assessment here with respect to this book: I strongly recommend it as a powerful and well-executed exposition of the case for certain IT management techniques that should be carefully considered and well understood by IT professionals. It is entertaining and insightful and well targeted to that end: for IT practitioners. However, I worry about the ability of this book to give non-IT senior management, such as the CEO or COO, a rounded insight into IT issues: instead, it could feed into their already prevalent tendency to oversimplify IT, gravitate to pat solutions, expect instant fixes, or even bolster their unfortunately common perception that it’s mostly IT’s own lack of business insight (not to mention poor attitude) that has led to IT-related failures.

Bottom line, though, despite some of my misgivings: a solid thumbs-up, and a recommendation to all IT professionals to put this on your reading list.

Lagniappe:

“Where To Learn More About Concepts In “The Phoenix Project” (Part 1)”: Additional background and reading material, by Gene Kim.

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mastodon