Book Notes: The Phoenix Project

Manufacturing figured out decades ago that a factory floor in chaos is not a production problem—it is a management problem. IT has been slower to reach the same conclusion. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford, makes the case that the principles Eliyahu Goldratt laid out in The Goal apply to software delivery just as cleanly as they apply to shop-floor operations. The novel format—a struggling VP of IT inheriting a burning platform—makes this case through story rather than prescription, and it lands harder for it.

I had read The Goal years before I was in a position to truly absorb it. Drawing parallels between a factory and a software team always felt like a stretch. The Phoenix Project closes that gap. What follows are my working notes, reorganized around the themes that struck me most.

Chaos, WIP, and the cost of not knowing

The book’s earliest and most visceral lesson is that when everything feels urgent, the first act of leadership is to impose structure—not to fight harder. You cannot completely escape firefighting at first, but you can stop treating every fire as equally important. Prioritizing and estimating work, even roughly, immediately distinguishes the real emergencies from the noise.

Equally corrosive is operating on guesswork. When a team’s default response to a production incident is “I think the bug is caused by…”, that hedge is not modesty—it is a symptom of missing visibility. We are flying without instruments. Good observability is not a luxury; it is a precondition for making any rational decision.

Work in Progress is the silent mechanism through which chaos compounds. The book borrows directly from lean manufacturing here: one of the most critical management levers in any operation is controlling the release of new work into the system. When we release work faster than we can complete it, WIP accumulates, context-switching multiplies, and every task slows down every other task. The connection to software teams is immediate and uncomfortable. Most of us have worked on teams where the sprint board was essentially a list of everything anyone had ever thought of doing, with nothing actually done.

The book identifies four types of work flowing through IT Operations: business projects, internal IT projects, changes and maintenance work, and unplanned work. The fourth type is the one that destroys the other three. Unplanned work—incidents, urgent requests, emergency patches—consumes capacity without warning, disrupts planned work mid-flight, and makes every estimate a fiction. The goal is not to eliminate unplanned work entirely, which is impossible, but to reduce it by fixing the underlying fragility that generates it.

The constraint

Once you have imposed some order on the chaos, the next discipline is identifying the constraint—the single bottleneck through which all work must pass. This is Goldratt’s core insight: in any system with a chain of dependent operations, the throughput of the entire system is determined by its slowest step. Every improvement made anywhere other than the constraint is, in a meaningful sense, an illusion. You may speed up work that arrives faster at the bottleneck, but the bottleneck still determines how fast work exits the system.

Protecting the constraint matters as much as identifying it. The constraint should never be waiting on unscheduled work, unclear priorities, or missing inputs from upstream steps. A work center—a person, a machine, a set of methods and measures—working at the constraint should be focused exclusively on the highest-priority items. After the constraint is protected, the next step is to focus the whole organization on the single most important project required for survival. Not the ten most important projects. One.

The improvement kata—the practice of deliberately and frequently injecting faults into the system—follows from this. Resilience engineering says we should make failures happen on our terms before they happen on production’s terms. Repetition in controlled failure scenarios builds the muscle memory that prevents catastrophic surprises. Habits formed through repetition enable mastery; mastery enables speed.

Flow, takt time, and deployment frequency

The goal of the Three Ways is to maximize flow—the movement of work through the system in one direction, without interruption, toward the customer. Two manufacturing concepts translate with almost no modification.

Wait time is a function of utilization. If a shared resource is 90% busy, the wait time for work to reach that resource is not 10% longer than when it was 50% busy—it is nine times the idle time, or 90 ÷ 10 = 9 units of wait for every unit of available capacity. This is why high utilization rates feel productive and are actually dangerous. A resource running at 90% capacity is generating enormous latency that never shows up on a status report. We optimize for looking busy and wonder why things are slow.

Takt time is the cycle time required to meet customer demand. If customers need a new feature shipped every two weeks and your deployment process takes three weeks, you have a structural deficit that no amount of heroism will close. In IT terms, if environment setup, testing, or release approval takes longer than your delivery cycle, you have identified the constraint—and it is probably a process, not a person.

This is why deployment frequency matters so much. The book targets ten or more deployments per day in production. That number shocks people who are used to quarterly or monthly releases, but the logic is sound: frequent, small deployments reduce the blast radius of any individual change, accelerate feedback, and force the automation of every manual step in the pipeline. Only about ten percent of features deliver the expected business outcome, so the faster we can get features in front of real users and measure the result, the sooner we stop investing in the 90% that do not work. Value Stream Mapping—tracing every step a piece of work takes from idea to production—is the tool for finding where time is genuinely being wasted versus where it is creating value.

DevOps as culture, not tooling

Technology adoption alone does not change outcomes. Organizations that move to the cloud or adopt containers while keeping the same handoff-heavy, ticket-based relationship between development and operations do not become faster—they move their dysfunction to a new platform. The constraint follows the org chart, not the infrastructure.

The book’s argument is that development and operations share a single goal: serve the business. When they treat each other as adversaries—developers throwing code over the wall, operations resisting changes to protect stability—both lose. The business loses more. IT is not a department in the sense of a discrete function. It is pervasive, the way electricity is pervasive. Decisions about IT architecture are decisions about business capability. They cannot be made in isolation.

Building systems for operations means designing in visibility, controls, and recovery paths from the beginning rather than retrofitting them after the first major incident. Feature toggles and canary releases decouple the moment of deployment from the moment of release, giving operations a dial rather than a switch. Netflix’s Chaos Monkey—deliberately killing production instances to expose fragility—is the extreme version of this thinking, but the principle scales down: inject faults deliberately and frequently, learn from them cheaply, and build the confidence that comes from having already survived failure.

Business agility, in this framing, is not about moving fast in a straight line. It is about sensing change in the market and responding to it with calculated risk—backed by the infrastructure to experiment rapidly and recover gracefully when experiments fail.

Color-coded work tracking

The book describes a visual management system that makes work and its priority legible at a glance. Purple cards represent changes supporting the top five business projects. Green cards represent internal IT improvement work, with a target of 20% of total cycle time allocated here—that investment in improvement is what compounds over time into a healthier system. Pink sticky notes mark blocked tasks, reviewed twice daily to prevent blockages from aging invisibly.

The balance between purple and green is the balance between delivering for the business today and building the capacity to deliver better tomorrow. Organizations that run at 100% purple are spending their improvement budget without knowing it—they are taking on technical and operational debt they will eventually have to repay at a much higher interest rate.

How to prioritise projects

When evaluating which projects deserve attention, three questions cut through the noise. Does this increase the flow of project work through the IT organization? Does this increase operational stability, or reduce the time needed to detect and recover from outages or security breaches? Does this increase the capacity of the identified constraint? A project that answers yes to all three deserves to move. A project that decreases throughput, overloads the most constrained resource, or reduces scalability, availability, survivability, security, or supportability should be deprioritized or dropped entirely—regardless of how compelling the business case sounds in isolation.

Further reading

The book pointed toward several threads worth following. Goldratt’s The Goal remains the source text for the Theory of Constraints and is worth reading alongside this one. Continuous Delivery by Jez Humble and Dave Farley provides the engineering mechanics that underpin the deployment frequency argument. The Toyota Production System and broader lean manufacturing literature show how these ideas were developed in physical production before being translated to software. Scott Cook’s experimentation culture at Intuit is a useful case study in what high deployment frequency looks like at an established company. The Three Ways are explained further at itrevolution.com/the-three-ways-principles-underpinning-devops.

What stays with me

The novel format is doing real work here. The principles land differently when you watch a character live through the consequences of ignoring them, rather than reading them as numbered recommendations. The discomfort of recognition—yes, that is exactly what our standups feel like—is more persuasive than any argument.

Design your systems for operations from day one. Build in the visibility, the controls, and the feedback loops before the chaos arrives. And it will arrive. The question is whether you will be able to see it coming.