The phoenix is a long-lived, immortal bird associated with Greek mythology (with analogs in many cultures) that cyclically regenerates or is otherwise born again.
Phoenix (mythology) - Wikipedia

When I decided to read The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ( The Phoenix Project ), I never thought that it'd be a quite reading journey. The book makes its impact, sure, but, at the same time, it marvelously manages to give you a whole range of completely opposite emotions: it motivates and discourages, it provides some valuable insights (and "aha!" moments) and, on a next page, makes you cringe from the triviality of solutions that described as magic.

Three aspects of the book definitely impressed me:

• unbeatable humor
• great illustration of what impact misplaced office politics and irrelevant management ambitions might have on overall motivation and effectiveness of work
• insightful overview of optimizing daily work processes (Four categories of work and Three Ways etc),

Let's start with the humor in the book which is really a great part of The Phoenix Project 's impact . The description of ever-changing CIOs, for example:

For the last decade, like clockwork, new CIOs would come and go every two years. They stay just long enough
to understand the acronyms, learn where the bathrooms are, implement a bunch of programs and initiatives to upset the apple cart, and then they’re gone.
CIO stands for “Career Is Over.” And VPs of IT Operations don’t last much longer

Or viewing developers as a threat to a would-be-otherwise-smooth work of an impeccable devops team:

The only thing more dangerous than a developer is a developer conspiring with Security. The two working together gives us means, motive, and opportunity.

Or how a devops team describes pesky disruptions:

They [Security] are always coming up with a million reasons why anything we do will create a security hole that alien space-hackers will exploit to pillage our entire organization and steal all our code, intellectual property, credit card numbers, and pictures of our loved ones.

The description of how releases are run is definitely sounds as a thriller:

One of the developers had actually walked in a couple of minutes ago and said, “Look, it’s running on my laptop. How hard can it be?” Wes started swearing, while two of our engineers and three of William’s engineers started poring through the developer’s laptop, trying to figure out what made it different from the test environment.

And this one as an unforgettable grand finale of a night when important deployment was happening:

In the corner, a developer is asleep under some chairs. It’s been a night of heroics.

In a sense, it's a dark humor. As the readers we observe the neverending chaos and the helplessness of otherwise capable and smart people. People who are dragged into a doomed whirlpool of work that has random deadlines and no structured processes, when no one is assigned a clear responsibility for the product and only could have a glimpse of understanding of how the results would be achieved.

What causes that stressful environment? The management? The curious thing about The Phoenix Project 's management in is that they obviously must have a great stamina to survive and cope with the everpresent hellish level of stress. Unsurprisingly, two (at least) main characters in the book - Steve Masters (the CEO) and Bill Palmer (the narrator and the VP of IT) both have that. They are former Marines. Quite often they reflect on their Marines experience to see if it's applicable to constantly unfolding crises around them (a spoiler: such experience was not relevant):

Each year, it gets harder. We have to do more with less, to simultaneously maintain competitiveness and reduce costs. Some days, I think that it can’t be done. Maybe I spent too much time as a sergeant in the Marines. You >learn that you argue your case as best as you can with your officer, but sometimes you have to say, “Yes, sir,” and then go take that hill.

Bill Palmer, described as "dependable, pragmatic, and willing to say what [he] really thinks", makes this logical conclusion:

I’ve figured out that the trick to a long career in IT Operations management is to get enough seniority to get good things done but to keep your head low enough to avoid the political battles that make you inherently vulnerable.

How such management views get translated into daily workflows, product and operations planning, into seeking feedback and getting everyone motivated? The following summarizes it all:

They [the management] are so freaked out about hitting their deadlines, they’re only now starting to think about how to test and deploy it.

One noticeable thing in the book - a QA team (and QA work) is mentioned only vaguely, like an unnecessary (and almost decorative) stage of a product development. Not recognizing the value of QA processes makes any product development unpredictable and stressful.

However, the most important part of The Phoenix Project is about finding ways to bring an order into the vicious circle of persistent crises and failures. As the phoenix who starts its new life after destruction, the teams in The Phoenix Project struggle to see what needs to be done to emerge from unpredictability and frustration with strength and clear vision. Here comes deus ex machina, Erik Reid, a board member, who has almost supernatural knowledge of how engineering processes should be organized. He guides Bill Palmer, by showing him the similarities between manufacturing plant processes and software development work and deriving from that analogy several valuable concepts. These concepts are presented with catchy titles - the Three Ways, the Four types of work, the Three Acts of Downward spiral, Seven major types of Non-value Adding items (aka "waste" in the manufacturing world). Even though it is a well-known trick to keep readers' attention, that gives a good structure and, hence, makes it easier to remember.

One of the main concepts - the Three Ways. The following description (taken from Book Summary: The Phoenix Project):

• The First Way — Continuously find and implement ways to improve delivery. This is synonymous with the - concept of Kaizen.
• The Second Way — Get fast feedback and work from strong failure signals to ever-weaker failure signals to get advance warning of quality issues.
• The Third Way — Use the efficiencies gained in The First Way and the safety enforced by The Second Way to introduce rapid experiments that help create qualitative gains.

Although those principles are hardly new, they would, indeed, have a tremendous impact on the productivity. Proposing "short and quick cycle times to integrate feedback", "reducing batch size, enabling fast feature flow" are key ingredients for success.

And the last important aspect of any efficient system - the allocating time for knowledge transfer. The Phoenix Project provides several examples of when the commitment to document procedures (and constantly updating it) would pay off:

[...] help convert individual expertise into artifacts that the rest of organization can use.

Was it worth reading the book? Undoubtedly, yes. The Phoenix Project shows what would happen when the processes are not in place, when they are disjointed or incorrectly implemented. The great tsunami of unplanned work (stalled deployments, bugs in production, not diligent maintenance etc) would encroach, inevitably destructing any islands of good work. To avoid the dangers of unplanned work, as one of my favorite quotes emphasizes, there should be a never ending search for improvement:

[it] is almost doesn't matter what you improve as long as you improve something. Why? Because if you are not improving, entropy guarantees that you are actually getting worse.