The Phoenix Project
One book, placed in its field — what Gene Kim, Kevin Behr & George Spafford's book gets right, where it goes further than the rest, and what the rest of the field adds.
Mike West, Editor · Leading With Data · bicycle.guide/guides/profile-the_phoenix_project
Arrow keys or swipe to move · N for notes · F for full screen
The Phoenix Project
One book, placed in its field — what Gene Kim, Kevin Behr & George Spafford's book gets right, where it goes further than the rest, and what the rest of the field adds.
Mike West, Editor · Leading With Data · bicycle.guide/guides/profile-the_phoenix_project
The problem
Deployment Lead Time erodes when it is left to instinct instead of method.
You were taught the moves piecemeal, never the whole model.
The Phoenix Project · Mike West, Editor · Leading With Data
The model
- 01Constraint Identification and Exploitation
- 02Work-In-Process Control
- 03Change Management Process Maturity
- 04Deployment Pipeline Maturity
- 05Deployment Batch Size
- 06Technical Debt Level
- 07Knowledge Hoarding and Tribal Concentration
- 08Cross-Functional DevOps Collaboration
The Phoenix Project · Mike West, Editor · Leading With Data
Step 1 of 5 · Constraint Identification and Exploitation
Find the one resource that everything waits on, and treat protecting its time as a scheduling policy, not a courtesy.
Misconception
Practitioners believe the constraint is whichever team complains loudest about overload or has the fullest ticket queue.
Reality
The constraint is the resource whose pace determines the pace of delivery for the whole system, which is often a single overloaded individual whose work is invisible in dashboards, not the team with the most visible backlog. A busy team is not automatically the bottleneck.
The Phoenix Project · Mike West, Editor · Leading With Data
Step 2 of 5 · Work-In-Process Control
A resource at 100% utilization guarantees long queues; plan for slack at the constraint, not for full loading.
Misconception
That maximizing how many projects run in parallel maximizes output, so idle capacity is waste to be eliminated.
Reality
Delivery time is dominated by wait time in queues, not touch time; the more work you release, the longer everything waits, so a partially idle resource is often faster overall than a fully loaded one.
The Phoenix Project · Mike West, Editor · Leading With Data
Step 3 of 5 · Change Management Process Maturity
Visibility precedes control: you cannot authorize or sequence changes you cannot see, so recording every change is the first milestone.
Misconception
Practitioners believe a rigorous Change Advisory Board that reviews and approves every change is what maturity looks like.
Reality
Heavyweight approval boards drive teams to make changes off the books, which destroys the visibility the process was meant to create; mature change management makes standard low-risk changes frictionless and reserves scrutiny for the small fraction that is genuinely fragile.
The Phoenix Project · Mike West, Editor · Leading With Data
Step 4 of 5 · Deployment Pipeline Maturity
You cannot ship in small batches until environments are reproducible from version control, not hand-configured.
Misconception
Practitioners believe pipeline maturity means buying a CI/CD tool and wiring up automated builds and tests.
Reality
Tooling automates the easy middle; the maturity that actually constrains you is on-demand, version-controlled environment creation—if staging and production still drift by hand, your automated tests validate a fiction and deployments stay fragile.
The Phoenix Project · Mike West, Editor · Leading With Data
Step 5 of 5 · Deployment Batch Size
Small batches make failures cheap to locate because there are few candidate changes to blame.
Misconception
Bundling many changes into one release is more efficient because you 'deploy once' instead of paying deployment overhead repeatedly.
Reality
Large batches don't amortize risk—they compound it, because debugging effort scales super-linearly with the number of simultaneous changes and you lose the ability to isolate which change broke production.
The Phoenix Project · Mike West, Editor · Leading With Data
The Phoenix Project · Mike West, Editor · Leading With Data
The cheat sheet
- Constraint Identification and ExploitationFind the one resource that everything waits on, and treat protecting its time as a scheduling policy, not a courtesy.
- Work-In-Process ControlA resource at 100% utilization guarantees long queues; plan for slack at the constraint, not for full loading.
- Change Management Process MaturityVisibility precedes control: you cannot authorize or sequence changes you cannot see, so recording every change is the first milestone.
- Deployment Pipeline MaturityYou cannot ship in small batches until environments are reproducible from version control, not hand-configured.
- Deployment Batch SizeSmall batches make failures cheap to locate because there are few candidate changes to blame.
- Technical Debt LevelUnplanned work is the observable symptom of technical debt; measuring its rate tells you how much debt you're actually carrying.
- Knowledge Hoarding and Tribal ConcentrationAny task or failure resolvable by exactly one named person is a single point of failure you can list, count, and shrink.
- Cross-Functional DevOps CollaborationShared on-call and shared metrics create collaboration; shared tooling and job titles do not.
The Phoenix Project · Mike West, Editor · Leading With Data
Sources
- The Phoenix Project — Gene Kim, Kevin Behr & George Spafford
The Phoenix Project · Mike West, Editor · Leading With Data