Reliability & operations · Book notes
The Phoenix Project and the work nobody planned
The Phoenix Project is a terrible novel with one idea that survives every complaint about it: unplanned work is work, and nobody puts it on the board.
There’s a sysadmin thread where people were arguing that The Phoenix Project was a book all IT should read. Then there’s a DevOps thread a couple years later where people were arguing that it was a terrible book with insufferable characters and dialogue heavy on corporate lingo. The interesting thing to me was that both threads were about the same novel, and the people arguing about it did roughly the same job.
The Phoenix Project is a business novel by Gene Kim, Kevin Behr, and George Spafford, published in January 2013. Bill Palmer becomes the VP of IT Operations at Parts Unlimited, an auto parts company whose survival depends on the late and troubled project Phoenix. With the help of his mentor Erik, he learns ideas adapted from manufacturing. It gradually becomes clear that every outage and urgent fix goes through one engineer, Brent.
The people who hate this novel are totally right about the characters and the lingo, but I don’t think that matters too much. It’s not for engineers who are living this every week. But as an allegory? It’s great. The audience isn’t the engineers, it’s the people who work next to the engineers and don’t understand why the team is always behind.
The idea that I think survives the eye-rolls is that there are four types of work: business projects, internal IT projects, changes, and unplanned work. These are laid out in IT Revolution’s summary. Bill can name the first three types pretty quickly, but the fourth one takes him the longest. The summary says that this type of work “is highly disruptive and prevents IT from focusing on strategic initiatives.” Unplanned work is still work.. it takes real hours from real people, but since it’s not on anybody’s list, it makes the team look slow to the people watching the list.
If I were picking one book for a non-engineer who couldn’t figure out where the team’s time was going, the obvious alternative is the non-fiction. The DevOps Handbook and Accelerate describe the same ideas in a more precise way and with a lot less melodrama, but I wouldn’t give those to this person. A reference book requires a patience that someone who’s never been paged doesn’t often have, and they’d probably stop reading after the first chapter.
I’d give them the novel. The characters are caricatures, but they’re caricatures of people you’ve met, which helps the four types of work stick. It’s written as a retelling of Goldratt’s The Goal, but with Brent as the constraint. The person who’s never carried a pager will recognize Brent faster than they will a definition of a bottleneck, and then they’ll notice the queue of interruptions in front of him.
You can reframe the eye-rolls.. engineers know unplanned work exists, so the story’s neat fixes feel too easy. But at least now they have a name for it that others will accept. For any team, the question is whether the unplanned work is on the board next to the planned work, or whether it’s only in the heads of the people getting paged about it.