~ 5 min read
The Phoenix Project - Book Summary
By Gene Kim, Kevin Behr, and George Spafford
Wikipedia, Amazon
The Gist
- Presented in fictionalized novel form (but surprisingly well-done), the book makes the case that any company not making their technology and IT practices one of their core competencies is taking an ill-advised existential risk.
- The book advocates for specific improvements and principles a company can make in the areas of DevOps, IT, Agile, technology, people, processes, culture, and business value alignment, generalized in a quasi Eastern/martial arts/guru style via “The Three Ways.”
- The Three Ways suggests that business value can be maximized by taking a holistic and systems-based perspective in order to better understand how exactly value is delivered to customers and how it can be efficiently and continually refined to stay competitive and keep your customers happy.
Takeaways
- I was surprised how well the narrative form worked. The authors used it well and with purpose. Most of the narrative contained numerous anecdotes that many IT workers will be very familiar with, but they used that embedded specificity to give the often overlooked context that many of these principles rely on – e.g. the centrality of people, pragamitc realities that arise from putting an idea in practice, and demonstrating various false assumptions and common myths.
- All companies now are essentially tech companies.
- DevOps is neat. Let’s do that.
The Three Ways
Gene Kim explains The First Way:
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
The focus is on all business value streams that are enabled by IT. In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service.
The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming). The Three Ways: The Principles Underpinning DevOps — Gene Kim
This advocates for things like optimizing for quality change management (safe, reliable, quick changes), CI/CD (on-demand environments and automatic testing) limiting work in progress, Kanban boards, etc.
Gene Kim explains The Second Way:
The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it. The Three Ways: The Principles Underpinning DevOps — Gene Kim
Gene Kim explains The Third Way:
The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.
We need both of these equally. Experimentation and taking risks are what ensures that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone. And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far.
The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience. The Three Ways: The Principles Underpinning DevOps — Gene Kim
The Second and Third Way can help justify things like process improvement, focusing on understanding actual bottlenecks, avoiding the premature optimization anti-pattern, the cultural value required to reward risk-taking, spending the time needed for seemingly indirectly valuable things like experimentation, learning, and practice, and making the company-wide changes that allow for risks and experimentation to not be detrimental to the company via, e.g., chaos engineering.
The 4 Types of IT Work
Part of understanding a business holistically and as a system, we need to understand the 4 types of IT work:
- Business projects: generate revenue or strategic value for the company
- Internal projects: help internal customers in the organization to become more efficient and productive
- Scheduled changes: work required to stabilize and improve the original output from the 2 categories above
- Unplanned work (or firefighting): disrupts all 3 types of planned work above
The Theory of Constraints
Originally introduced by Eliyahu M. Goldratt in his 1984 book titled The Goal, it advocates for a management philosophy focused on understanding and maximinig operational throughput with a method to help identity and alleviate contraints:
- Identify the system’s constraint(s).
- Decide how to exploit the system’s constraint(s).
- Subordinate everything else to the above decision.
- Elevate the system’s constraint(s).
- Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system’s constraint. Theory of constraints - Wikipedia
The most important take-away is that this requires systems-thinking due to the necessity to know what the actual singular current bottleneck is, since eliminating any local bottleneck doesn’t improve actual throughput due to the global bottleneck and can often slow things down even more due to potentially overwhelming downstream areas unable to deal with increasing throughput.