A novel about IT in a corporation? Not interested, I have seen too much of it in real life.

This was my first reaction when I heard about the book. But I was wrong. "Phoenix Project" is both entertaining and insightful. After reading it I decided to give a copy to my DevOps Team.

The main character, Bill, is an IT manager who has just been promoted to CIO. Now it's his job to navigate the company's rough waters of technological and organizational transformation.

And he fails—a lot.

Failing and learning from failures is what makes the story worth reading. The challenges and failures Bill was facing sounded strangely (sometimes painfully) familiar to my experience as CTO.

Learning from a fictional story

On one hand, the story helps us understand the mindset and culture behind the DevOps revolution which changed the IT industry for good.

On the other hand, it also gives a lot of actionable insights crucial for understanding modern software development and IT operations.

Two key takeaways for me were the concepts of "The Three Ways" and "For Types of Work".

Let's leave The Three Ways for another time and dig into the Types of Work, especially the impact unplanned work has.

4 Types of work

1. Business Projects - projects providing value for internal or external customers,

2. Internal IT projects - infrastructure, tools, automation, the backbone needed for the company to strive.

3. Updates and changes - a stream of little jobs to keep systems running. Everyday operations, and deployments of changes coming from both project types above.

4. Unplanned work or recovery work - incidents, bugs, crashes, escalations. The work keeps people awake at night.

Unplanned work is what keeps the teams from actually moving forward with plans and delivering other types of work. It's a productivity killer.

That’s why Erik called it the most destructive type of work. It’s not really work at all, like the others. The others are what you planned on doing, allegedly because you needed to do it.

Unplanned work is what prevents you from doing it. Like matter and antimatter, in the presence of unplanned work, all planned work ignites with incandescent fury, incinerating everything around it. Like Phoenix.

That is why it is so crucial to limit the amount of unplanned work. The problem is that mistakes and shortcuts resulting in unplanned work, are often made long before they are discovered. So it's not possible to limit it by just tuning operations alone. It has to be a coordinated effort across the organization.

Some of the ways to limit unplanned work:

• the quality has to be built in from the start, automated testing is a way to go,

• plan for the unplanned - never plan 100% of the team capacity, make room for unplanned work,

• smaller, more often, and automated releases are crucial for limiting the risk and allowing to recover faster,

• plan time to pay the technical debt, by refactoring and covering it with automated tests

P.S. You can read more about the book or grab a copy here