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 is The Second Way from The Phoenix Project? Why is a quick feedback cycle essential to IT departments?
In The Phoenix Project, Kim, Behr, and Spafford demonstrate how work management principles developed on factory production lines can be applied in an IT environment. The three foundational pillars of production can be summed up as 1) fast workflow, 2) quick feedback, and 3) continual improvement.
Continue reading for an overview of The Second Way and how to implement it.
Quick Feedback Cycles
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.
(Shortform note: In The Design of Everyday Things, Don Norman describes the “small product” feedback loops recommended in The Phoenix Project as a cycle of iteration that’s intended to generate errors as fast as possible so that they can be quickly corrected. Norman favors this approach for small projects only, arguing that for large projects, implementing constant testing and feedback is cost-prohibitive. Kim, Behr, and Spafford don’t dispute this point, and it may be part of the reason why adherents to their design philosophy argue against large, resource-intensive projects altogether.)
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.
(Shortform note: To shape the beginning of the development process, feedback loops must transmit information all the way back from the end of the process. In User Friendly, Cliff Kuang and Robert Fabricant explain that designers must understand the end-user by observing and empathizing with customers’ experience—what they enjoy about using the company’s software, and what frustrates them about it. An effective information loop provides feedback in the user’s direction as well. For example, an effective online store design will unambiguously let customers know if they’ve successfully completed a purchase—and if not, then why.)
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.
(Shortform note: There’s a lot more to documenting institutional knowledge than simply writing down the steps people take to solve problems, though that’s certainly a place to start, as it is in the authors’ scenario. In order to be useful, that documentation has to be easily accessible to any employees who need it. In practical terms, it can take many forms, such as flowcharts, training manuals, and internal databases, all of which take time and effort to design, organize, and curate. None of this can be done haphazardly, but must be part of a company’s overall knowledge management strategy.)
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Gene Kim, Kevin Behr, and George Spafford's "The Phoenix Project" at Shortform.
Here's what you'll find in our full The Phoenix Project summary:
- Why a poorly-run IT department will destroy a business
- The three pillars of IT management recommended for any modern business
- A fictional case study about a man who turns around an auto parts company
