The Phoenix Project

Surprisingly, my wife came across this book, and suggested I would read it. And as her turn had arrived to have it as a loan from the public library,it was placed in my hands.

As I looked at the cover, reading the text: “A novel about IT, DevOps, and helping your business win”, I have to admit a burn to read this book was not ignited at first. The silver badge on stating that the book I held in my hand was a 5th anniversary limited edition maybe got me a little interested. Flipping the book around, and reading the back-cover, which contain quotes, there was the first one, which made some definite sparks fly for me. The first quote was from Jim Whitehurst, who’s President and CEO of Red Hat Inc.

“The Phoenix Project is a must read for business and IT executives who are struggling with the growing complexity of IT.”
-James Whitehurst

So I started reading the book. I was pretty fast on some level hooked on the book, although it wasn’t of hook of which sort I’ve had before with some other books. My wife even asked me after the first reading session, what I thought of the book, and I honestly answered: “It’s ok, nothing special, but probably worth the read.”

But the book still managed to keep me hooked, and I found myself pretty soon grabbing it again and continuing reading. As a IT professional myself, the language and terminology was familiar, and in the beginning of the book, I was now and then finding the book even a bit boring. But then after some more pages, there was a new event or plot that made me continue reading…just a little bit more.

As the reading went on, I actually found some interesting comparable strings between my real life work, and the book. And although the book didn’t really bring much new information to myself, I found some things I’ve tried to explain, or verbalize in real life before, but unsuccessfully, the book in question explained it well. I got some official (?) terms on issues and functions that I’ve tried to explained. Like the four fundamentals in this book, and in IT&DevOps world. And they are:

Business Projects,
IT Operations Projects,
Changes,
and Unplanned Work.

As the pages kept on flipping, there was one crucial part that caught my attention, which I fear many leaders don’t take into consideration, even today in many companies.

“…You’ve just described ‘technical debt’ that is not being paid down. It comes from taking short-cuts, which may make sense in the short-term. But like financial debt, the compounding interest costs grow over time. If an organization doesn’t pay down its technical debt, every calorie in the organization can be spent just paying interest, in the form of unplanned work.”

If this would be discussed with colleagues, many would try to point on to only the large scale technical debts, but what many won’t think of is the smaller tech debts. And if a company has several of these, they can gather up to be very costly later on. Let’s take an example. If you drag your feat with renewing PC:s, and only exchanging them when some sort of indication of problems, or even worse, problems occur, the effect can be devastating later on. If for instance in stead of a PC, it would be a server, the effect multiply’s.

Or if the tech debt is maintenance on key object’s in a business critical software, they at some point in the future can escalate to serious problems for the new functionality development. And every now and then one hear’s from friends or by acquaintances, how somebody complains that the grassroots, or base data is not up to the standard it should be, and therefore new development slows down, or even has to be postponed, which then can generate a lack of income for the company.

So James Whitehurst compiled a very sensible and good conclusion of this book, and I agree and concur to it: “The Phoenix Project is a must read for business and IT executives who are struggling with the growing complexity of IT.”