The Phoenix Project

The Phoenix Project is a novel about an IT department. That sounds like the most boring sentence possible, and I still couldn’t put it down.

Bill Palmer gets promoted, against his will, to run IT operations at a company called Parts Unlimited. The company is struggling. There’s a huge, late, over-budget software project called Phoenix that is supposed to save it. Systems keep breaking. Everyone is firefighting. And Bill has been given a few months to fix it.

It’s openly based on The Goal. Bill even has his own Jonah, a strange board member called Erik who takes him to a factory floor and asks him annoying questions. Reading the two books close together made both of them clearer for me. The Goal shows the ideas in a factory. The Phoenix Project shows that the same ideas apply to work you can’t see.

Four kinds of work

One of the first things Erik makes Bill do is figure out what kinds of work his department actually does. They end up with four:

1. Business projects: things the business asked for, like Phoenix.
2. Internal projects: upgrades, improvements, infrastructure.
3. Changes: updates and fixes that come out of the first two.
4. Unplanned work: emergencies, outages, firefighting.

The fourth one is the dangerous one. Unplanned work doesn’t show up in anyone’s plan, so nobody counts it. But every time it happens, it steals time from everything else. And a lot of unplanned work is caused by earlier work that was rushed, so it creates more of itself.

When I read that, I thought about how many businesses run like this without calling it that. A client escalation. A payment that didn’t go out. Someone who needs an answer right now. Each one feels small. Together, they decide what actually gets done that week.

Brent

My favourite character is Brent. He’s the engineer who knows how everything works. Every incident ends up with him. Every project needs him. Everyone goes to him directly because he’s the fastest way to get anything fixed.

So he’s always overloaded, nothing gets done without him, and when he’s busy everything waits.

Brent is the constraint, and he’s a person rather than a machine. The book doesn’t blame him or ask him to work harder. Bill’s fix is to protect his time, stop letting everyone pull him into small fires, and get what’s in his head written down so other people can do the work.

This is the part that hit closest. The person who knows everything feels like an asset, and in a way they are. But a business where everything goes through one person can only move as fast as that person. In a small company, that person is very often the founder.

A big part of what I worked on at elevraa was taking the founder out of workflows that didn’t need them. With Knox, the whole goal was to build something that doesn’t need me in the middle of the work every day. I didn’t have Brent as a reference at the time, but it’s the same problem.

You can’t manage what you can’t see

A lot of the chaos in the book comes from nobody knowing what’s actually in progress. Requests come in by email, by phone, by someone walking up to a desk. Nobody has the full list.

So one of Bill’s first fixes is making the work visible. They put changes on index cards on a board. Later they use a kanban board for the work going through Brent. Once everything is on the wall, the problems become obvious: too much half-finished work, duplicate requests, things stuck waiting for one person.

I love this because it’s such a low-tech fix. No new software, no big transformation. Just write the work down where everyone can see it, and limit how much is in progress at once. I think a lot of operations work is exactly this: getting the real picture in front of people.

Release work, don’t push it

Another idea from the factory scenes: you shouldn’t release work into the system faster than the constraint can handle it. Starting more things doesn’t make you finish more things. It mostly makes the queue longer and everyone more stressed.

That one is hard for me, honestly. My instinct when there’s a lot to do is to start everything. The book is a decent argument for starting less and finishing more.

The Three Ways

The book ends up at three principles:

• Flow: make work move smoothly from start to finish, and see the whole system, not just your part of it.
• Feedback: find out quickly when something breaks, as close to where it broke as possible.
• Continual learning: build a habit of experimenting and learning from mistakes, and set aside time for improving how the work gets done.

The third one has a line I liked, roughly that improving daily work matters even more than doing daily work. In the book, the teams that never set time aside for that are the same ones stuck firefighting.

What I’m taking from it

• Count the unplanned work. It’s usually bigger than anyone thinks.
• Find your Brent, and protect them instead of leaning on them more.
• Put the work somewhere everyone can see it.
• Limit work in progress. Finish before you start.
• Leave time to improve the system, or you’ll spend all of it firefighting.

It’s a novel, so some parts are a bit cheesy. But it’s the most practical book on this list for anyone who has ever said “we’re so busy and nothing is moving”.