I never thought I would actually read a book that is both a technical book and a novel, that would really excite me enough to want to write a review about it. But this hardly imaginable situation has now occurred. First of all, I would like to state that I was not promised any benefits for this post and that I purchased the book quite regularly in a store. It is the book The Phoenix Project - A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford.

The Phoenix Project inimitably tells the story of Bill Palmer, a midrange computer department manager at Parts Unlimited, an auto parts manufacturer. Parts Unlimited’s market situation is very tight, with competitors always one step ahead. Bill’s survival tactic has always been to fly under the radar and not stand out. So the day comes when Bill, running late for work, is called into her office by the HR manager on his way to work. Once there, he learns that his boss and his boss’s boss, the CIO, are no longer with the company and that he is now to become the head of IT operations and that this choice was made by the CEO himself. Bill firmly intends to refuse the promotion, but somehow the charismatic CEO Steve Masters manages to run him over in conversation so that he does not manage to refuse the promotion.

During the conversation with Steve, he learns that there are IT problems with the payroll and that he should contact Dick, the CFO. Finding the cause is not easy, since there is also a failure in the SAN parallel to the problems with the payroll. This is how the story takes its course. At first, Bill tries to cope with the chaos through precision and discipline, as he learned in the Marines, and to put structures in place, as he was taught in business school.

During the book, Bill meets Erik. Erik is supposed to join the board if the chairman of the board Bob Strauss and Steve Masters have their way. Erik doesn’t fit the profile of the classic businessman at all. He explains to Bill in worn pants and a T-shirt, using one of Parts Unlimited’s factories as an example, that classic production and IT (development and operations) are actually no different and that it is therefore very easy to derive corresponding procedures for IT from the optimizations and processes of classic production.

Thus, there are all kinds of problems that need to be solved in the book, and you learn about the necessary considerations and steps for DevOps on the basis of the three paths. The often difficult relationship between developers and administrators is also highlighted. You can imagine the situations/problems described really happening in reality. The book is also a wonderful reference work, as the essence of the book is also summarized in the appendix, which is easy to understand and detached from the actual story.

In conclusion, this book should really be a standard work, whether you are a developer, administrator, or especially if you are part of management and wonder why IT departments don’t tick the way you think they do.