The Phoenix Project by Gene Kim, Kevin Behr and George Spafford

Chris Woodall | 2022-10-10

The Phoenix Project has been recommended to me by a lot of people over the years. As a book about DevOps in an IT industry a little detached from my current work in motor controls, and software, for electric aviation, I was a little concerned that I might not find a lot that was useful for me; however, the journey The Phoenix Project takes you on was far too familiar, and while the specific solutions might not apply the core of The Three Ways, looking at engineering as plant management, and some of the realizations about how to align and work in a larger organization will certainly aid me in my career.

The core of the book follows a story where Bill becomes promoted to a position as the VP of IT in his organization, and finds that the whole IT organization is in disarray. After a few hard outages, failed projects, and losing the company tons of money; Bill, with the assistance of Erik Reid (who provides sage advice), can right the ship, gain a new view of what work is, and improve his organization. Overall, the main thread of the story involves finding your bottlenecks and relieving them, controlling the flow of work, aligning that flow of work with the business goals, and continuous improvement of business processes. This then also leads to the concept of DevOps, where the development and operations side of an organization work together to increase release cycles, test cycles, and requirements discovery cycles. This then allows for the development team to release faster and converge on more useful solutions faster, and the operations team to support the end product better, improve reliability and find optimizations that can improve efficiency across an entire organization.

The Three Ways

  1. Make the work visible, control the flow of work, align yourself with the business goals and the customer goals, and prevent defects from moving downstream. The first way is all about left-to-right flow (business to customer), improving the speed at which ideas can make their way to the customer. The result of this is CI/CD systems and systems that can be changed.
  2. The second way increases feedback in every stage of the process, allowing for increased communication, and making issues visible as soon as possible
  3. The third way is about continuous improvement of the entire organization. This is about improving processes, automation, increasing efficiency, and launching projects that can reduce bottlenecks and increase throughput. This allows for a more generative, creative, and risk-taking culture, supported by other means.

The Types of Work

Another takeaway for me was the types of work:

  1. Direct Value Work/Business Work
  2. Internal Projects
  3. Changes and Support
  4. Unplanned Work

Of all of these, the only one that is of dubious value, or is unnecessarily expensive is unplanned work. Unplanned work adds chaos to the system, since unplanned work is by definition not visible, it creates delays and issues throughout an entire organization. The other issue is that your bottlenecks often will be implicitly involved in unplanned work, further increasing delays. It is clear to me that unplanned work is the beginning of the doom spiral for an organization or an individual.

A Few Personal Takeaways

Overall I found one of the things that I found most enlightening is my empathy with pretty much every character. Over my career, I have felt a little bit of each of the characters’ roles, and I realize that in my current role I have become a little bit of a Brent, meaning that I am a bottleneck. Brent is a well-meaning, smart, and caring engineer, but who tends towards heroics, preferring to “just get it done” over understanding the root causes and making work more systematic. While the “factory plant” model of engineering does not thrill me, I see the benefits and I also see the personal benefits. If the most time-critical work is systematic, repeatable, automated, and out of the way then in a lot of ways the problems, new projects, and exciting work can come to the forefront. To this end, one takeaway was: to minimize WIP. And even more than that: don’t hoard work.

A related concept was the idea that a work center is made of: machines, man, methods, and measures. And that you must not mistake them. The abstraction carries far further than you originally thought. However, one of the things that I always forget is the importance of “measures”! I tend to set impossible, output measured, goals. For example, running an ultra-marathon, which can be demotivating. However, intermediate goals, and “leading/predictive” key performance indicators, or measures are far more useful. Such as, running 5 miles a week (and then keep increasing that load), since they tell you more about if you are on track, and will then lead to success. By only rewarding, and measuring the results, there will be little clarity on how to get there. Lagging measures are important since they are often the outcome we want, but leading measures get us there.