The Phoenix Project - Gene Kim, Kevin Behr and George Spafford

The Phoenix Project is a business novel about IT operations, and one of the books that shaped how many people think about DevOps. Its lessons reach well beyond the technology industry, and the story makes them easy to remember.

The story

Bill Palmer is suddenly promoted to run IT operations at Parts Unlimited, a manufacturer whose IT is so chaotic that it threatens the company's survival. He inherits a flagship programme, the Phoenix project, that is late, over budget and failing. With help from Erik, a prospective board member, Bill starts to see IT work the way a plant manager sees a factory floor: as work flowing through a system, with queues, bottlenecks and hand-offs. The book openly borrows from Eliyahu Goldratt's The Goal, which told a similar story about manufacturing.

The ideas I took from it

Every company is, in part, an IT company. Accepting that is the first step to changing how you work. Technology isn't a support function that sits to one side; it's the business's central nervous system. Once a company accepts that, it can combine what it knows about its business with the speed that good IT practice brings.

Know what kind of work you're doing. Erik teaches Bill to see four types of work: business projects, internal IT projects, changes, and unplanned work. Unplanned work, the firefighting, is the most damaging because it crowds out everything else. You can't manage work you can't see, so the team starts by making it visible.

Find the constraint. Much of the Phoenix project's trouble traces back to Brent, the one engineer who knows how everything works and is pulled into every problem. He's the bottleneck. Improving anything other than the constraint doesn't help the whole system; protecting Brent's time and spreading his knowledge does.

Limit work in progress. Taking on more work doesn't make things go faster. Too much work in progress hides problems and slows everything down.

Make processes transparent and automated. As the characters bring in visible, automated processes modelled on good manufacturing practice, chaos gives way to order. This isn't technology for its own sake. It removes error-prone, repetitive work so that people have time for the thinking only they can do.

The same principles apply to every kind of work. Whether you're making car parts or writing software, flow, productivity and quality follow the same rules. IT shouldn't be a silo; it's part of how the whole operation works.

The Three Ways

The book sums up its approach as the Three Ways:

1. Flow: optimise the whole system, from business request to running service, not one team's part of it.
2. Feedback: create fast feedback loops from operations back to development, so problems are found and fixed early.
3. Continual learning and experimentation: build a culture that takes sensible risks, learns from failure and practises until the work is routine.

The book's point about practising until the work is routine is also why I like running disaster recovery drills as a game.

The story of Parts Unlimited is a warning and a guide. Standing still is the real risk, and the organisations that do well are the ones that treat how they build and run technology as part of how they run the business.