The Phoenix Project
Summary
Kim, Behr and Spafford wrote a business novel about an information technology organisation in crisis, deliberately modelled on Eliyahu Goldratt's The Goal, which taught manufacturing constraints through fiction.
The narrative follows Bill Palmer, unwillingly promoted to run operations at a struggling manufacturer, as a critical project fails, deployments break production, audit findings accumulate and the business considers outsourcing. He is guided by a board member who teaches him to see technology work through the framework of manufacturing operations.
The framework has two parts. The four types of work are business projects, internal projects, changes and unplanned work, and the authors argue that unplanned work consumes the capacity that the other three need, so reducing it is the first priority. The Three Ways are the underlying principles: the first is optimising the flow of work from development through operations to the customer, which requires seeing the whole system rather than individual departments; the second is amplifying feedback loops so that problems are detected and corrected close to their source; the third is creating a culture of continual experimentation and learning, which requires accepting that failures will occur and treating them as information.
The operational content applies constraint theory directly. Identify the bottleneck, which in the novel is a single overloaded engineer through whom all critical work passes; subordinate everything else to it; protect it from non-essential demand; and then expand it. The authors also argue for small frequent releases over large infrequent ones, for automating deployment, and for making work visible.
The novel form makes the ideas accessible and also makes the characters thin and the resolution implausibly smooth. The technical practices described have become standard since publication, so a reader in a mature engineering organisation will find them familiar. The DevOps Handbook by the same lead author covers the practices directly.
Key takeaways 7
- Unplanned work consumes the capacity that planned work requires, so reducing it is the first priority in an overloaded technology organisation.
- Technology work divides into business projects, internal projects, changes and unplanned work, and organisations track only the first.
- A single overloaded individual through whom critical work passes is a constraint, and no improvement elsewhere increases throughput.
- Work in progress must be limited, because starting more work than the constraint can process increases delay without increasing output.
- Small frequent releases reduce risk relative to large infrequent ones, because the change being deployed is smaller and easier to reverse.
- Feedback loops must detect problems close to their source, since defects found late cost far more to correct.
- Making work visible is a precondition for managing it, and most technology organisations cannot see what their people are actually doing.
Who should read it
Executives outside engineering who need to understand why technology delivery fails, and engineering leaders who want a shared vocabulary for constraint-based improvement.
Where it sits in the reference 3
Similar books 6
Chosen by shared topics, the entries that hold them, and the people who recommended both.
