The Three Ways From The Phoenix Project—Explained

This article is an excerpt from the Shortform book guide to "The Phoenix Project" by Gene Kim, Kevin Behr, and George Spafford. Shortform has the world's best summaries and analyses of books you should be reading.

Like this article? Sign up for a free trial here.

What are The Three Ways from the book The Phoenix Project? How can you make your IT development teams run more smoothly?

None of the problems of IT are insurmountable, but authors Kim, Behr, and Spafford argue that addressing them requires completely rethinking how IT work is done. The Three Ways from The Phoenix Project can be summed up as fast workflow, quick feedback, and continual improvement.

Continue reading for a detailed overview of The Three Ways.

What Are the Three Ways?

In their fictional case study, the authors demonstrate how work management principles developed on factory production lines can be applied in an IT environment, where the production of software, databases, and networks can be likened to manufacturing physical products. The Three Ways can be summed up as 1) fast workflow, 2) quick feedback, and 3) continual improvement.

Because the authors’ point-of-view character is a vice president of IT operations, one might assume that their advice is intended for readers in corporate management positions. However, understanding the principles that follow will be essential for everyone in the production process, since implementing the authors’ recommendations will require buy-in from many people in a company and certainly everyone in IT.

(Shortform note: The authors’ core concepts evolved from principles of ITIL, Lean, and Agile production methods, which are mentioned in The Phoenix Project but not explained in depth. ITIL (Information Technology Infrastructure Library) is a set of best practices for delivering IT services that were introduced in the 1980s and have continued to develop over time. Lean production is a manufacturing process first developed at Toyota that minimizes waste within a production system. Agile project management is a system that takes Lean principles and applies them to software development.)

The First Way: Fast Workflow

The first of The Three Ways, “fast workflow,” may sound like a goal and not a place to start. However, the authors lay out a series of procedures that can establish a faster flow of work through IT from the outset. These include creating a visual tracking method to monitor and schedule work through IT, reducing the paths by which work enters the pipeline, breaking projects down into smaller, independently manageable components, and opening up your bottleneck so that work flows through it as quickly as possible.

To begin with, managing workflow is impossible without a way to monitor its progress. The authors repeatedly recommend using a kanban board (a visual tool that shows the status of tasks as they pass through IT) both for tracking work and for scheduling tasks as they come in. A visual tracking tool lets you document how much time a task takes at each station, and therefore it indicates how much work you can afford to take on. If certain tasks are regularly repeated, then documentation will allow you to plan for exactly how much time they will take. It will also make you aware of how many time-consuming handoffs occur as a task is passed from one station to the next and whether you can reduce those handoffs in order to speed up workflow even more.

As you monitor your department’s workflow, you’ll also become aware of all the different avenues by which work—often unexpected work—enters and confounds the flow of operations. People in many organizations have grown used to calling IT staff directly to fix what they perceive as “urgent” computer problems, interrupting and backlogging whatever projects your staff was meant to be working on. Identifying where and how unexpected work interrupts production is the first step in limiting the amount of work in progress. The authors stress that doing so is vitally important to speeding up IT production.

Another key component of speeding up workflow is to reduce the size of the projects you take on. Huge projects meant to accomplish multiple business goals at once, such as the authors’ disastrous Phoenix Project, are so unwieldy that identifying design problems and errors is that much more time-consuming and difficult. Dividing large projects into small, discrete units can let each part move through design, testing, error-fixing, and rollout in a timely manner, sometimes on the order of days or weeks instead of months or years. If there’s any fundamental flaw in one of the smaller components of a project, it can be caught and corrected that much sooner, before it can have a devastating impact on the whole.

The Second Way: Quick Feedback

In order for a streamlined, faster workflow to be beneficial, your system must generate and implement corrective feedback all along the production chain. Feedback cycles, like your projects themselves, should be small and efficient so that problems can be identified quickly, connecting both Development and Operations, and resolved in a way that generates new information.

The authors note that systems such as large software packages and sprawling computer networks are far too complex for any one person to fully understand. Therefore, work on those systems must be designed in such a way that errors can be detected and corrected quickly. Small project sizes let you catch and fix problems before they become disasters, but to enable this, your production process must generate feedback at every step in which work is performed. One example of a way to create this kind of feedback is to institute checklists for every task being done, especially at any point in the process where work is passed from one station to another.

Feedback cycles can’t be confined to Operations—they must include Development as well. Developers must know if their code is effective or problematic as quickly as possible, not months down the line after they’ve moved on to other projects. The authors say that feedback from Ops must be incorporated into the very beginning of the Development process, in effect merging the two departments into one cohesive DevOps gestalt. Ideally, the feedback and response time between designing and installing new systems needs to be fast enough to keep up with customer demand, whether those “customers” are clients of your company or other departments inside your organization.

The moment your feedback measures detect a problem, it should be fixed immediately, not patched with a workaround and put off until later. The authors insist that problems should be tackled by the people closest to them as part of their regular responsibilities. More than that, those people should bring in as much help as they can get from their department to resolve the issue. This way, the issue becomes a learning opportunity that generates new knowledge for the organization. By documenting the whole solution process, that knowledge becomes embedded in IT’s procedures and toolkit for future problems.

The Third Way: Constant Improvement

The last and perhaps most important component to harnessing IT’s—or any system’s—full productivity is to create a culture of continual improvement through practice, repetition, experimentation, and useful failure. Using the story of their fictional company’s ill-conceived “Phoenix Project,” the authors provide a negative example of a company with a toxic workplace culture and a blueprint for a better way to encourage growth, development, and innovation that benefits your business as a whole.

The defining characteristic of a toxic workplace is that employees’ behavior is guided by a constant fear of failure. In such a culture, administrators address mistakes and malfunctions by assigning blame and taking punitive action. As a result, people are discouraged from identifying errors and problems in a system. Feedback is silenced, because who will provide it when the default cultural response is to kill the messenger? Toxic work cultures stifle any improvement, and without constant improvement, a system will stagnate and problems will fester until they become catastrophic.

On the other hand, a productive company culture will encourage people to report problems at once. The authors show that if employees can trust that they won’t be reprimanded—and may in fact be rewarded—for identifying and helping solve issues detrimental to the company, then those employees will feel an ownership stake in seeking out ways to improve the whole system. If they’re encouraged to take risks in the process by trying solutions that may or may not work without fear of reprisal from on high, then your company will foster a culture of innovation in which even failed attempts at improvement are seen as a way to generate knowledge that can be shared across the organization.

Finally, the authors state that businesses should formalize their systems of continual improvement. IT staff can hone new solutions and practices while refining them through repetition and practice. Teams within DevOps can root out flaws in their products by pushing their products’ limits, forcing errors to emerge before they crop up on their own. One way to accomplish this is to deliberately introduce faults and design flaws into the production line so that staff can practice identifying errors, providing feedback, and coming up with resolutions. Not only can you identify systemic deficiencies in this way, but you’ll also promote a culture in which experimentation, risk-taking, and learning become an institutional way of life.

The Three Ways From The Phoenix Project—Explained