The Phoenix Project
Gene Kim, Kevin Behr and George Spafford · 2013
A DevOps novel: flow, feedback and continuous learning, told through an IT department in crisis.
What it’s about
A novel about Bill, an IT manager suddenly put in charge of a failing, business-critical project at a company called Parts Unlimited. Outages, late releases and endless firefighting pile up until a mentor figure walks him through lessons borrowed from manufacturing. Along the way the book introduces the “Three Ways” of DevOps: flow, feedback and continual learning.
What I learned
Make work visible, then limit it. Bill’s team can’t improve what they can’t see. Once work is on a board, the real problem shows itself: far too much in progress at once.
Four kinds of work. Business projects, internal projects, changes and unplanned work. Unplanned work is the one that eats the others, and it’s mostly caused by the shortcuts taken in the rest.
Brent is a bottleneck, not a hero. Brent is the engineer everyone depends on, who fixes everything and is therefore involved in everything. Every flow problem eventually runs through him. Protecting his time and spreading his knowledge helps more than adding people.
Improve the whole system, not one heroic part. Optimising a step that isn’t the constraint changes nothing.
What I applied
The Brent lesson is the one I’ve acted on most directly. When I moved on from Sky, a lot of how the workflow platform worked lived in my head, and I was at risk of being the team’s Brent. I ran structured knowledge-transfer sessions, each backed by written documentation and a tidy backlog, so the most common changes no longer needed me (Knowledge Transfer Before Moving On). My honest lesson from that: start much earlier, because knowledge transfer should be continuous.
Making work visible came up too. I made the case that UI engineers scattered across backend-shaped scrum teams were invisible: their work wasn’t planned, demoed or prioritised like everyone else’s. A shared guild board fixed some of that (Chairing a Cross-Team UI Guild).
And flow: faster lint checks and coverage shown in every merge request shortened the feedback loop without adding process (A Testing Strategy Teams Actually Adopted). It’s why I measure delivery by flow (DORA Metrics) and see platforms as a way to remove the bottlenecks people end up becoming.
Where it connects
DORA Metrics · You Can’t Serve Two Masters · Shift Left Testing · Knowledge Transfer Before Moving On · Deloads Are Tech-Debt Sprints · The Five Dysfunctions of a Team
↩ Mentioned in (2)
Twenty-odd books across code, platforms, teams, trading and science fiction turn out to make the same five arguments. Here's the thread that connects them.
book · Patrick Lencioni
The Five Dysfunctions of a TeamA leadership fable: trust, conflict, commitment, accountability and results, each built on the one before.