The Phoenix Project
📚 The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
This book landed (digitally) on my desk some years ago. We had a reading club at work where a group of us read it around the same time, and then met up for discussions. Other folks had read it before, and so a growing number of people in the department had read the same book, making it a shared reference that popped up in all kinds of work conversations.
When I first read The Phoenix Project back then, I had mostly worked alone on small web sites. I recently really enjoyed re-reading the novel — now with so much more context from experience working in a large organisation, and with planning work on IT projects.
Don’t be Brent, don’t make Brents
In the story, Brent is a smart engineer with a ton of experience who has become a bottle neck. Every time there is a critical incident, Brent is needed to fix it. Every time a project is important, Brent is wanted. And for each and every one of those times, Brent keeps gaining more skills and a stronger understanding of the company systems — becoming indispensable for work to happen.
How Brent turned into Brent is that we allowed him to build infrastructure only he can understand.”
A consistent priority on distributing knowledge over individual heroics is a super powerful feature to have embedded in your culture. I feel lucky to have seen this in action, how to always work actively on not creating bottle necks where only “Brent” can do certain tasks.
Limit work in progress
They also knew that until code is in production, no value is actually being generated, because it’s merely wip stuck in the system.
Coming from a traditional design background, it’s easy to have a tendency for generating a gazillion ideas and exploring all the alternatives and starting so much work in parallel. Collaborating with people who pushed me to resist queuing up too much wip has helped me prioritize code in production over grand plans that never happen, and to develop a strong knack for iterating.
Improve the flow of work
People and teams need to have slack. If everyone is too busy, wip will get stuck in the system, waiting around for other tasks to be completed or other people to magically get time. This in particular reminds me of issues around developers waiting for sketches to be finished by designers. And also “completed” design sketches lying around for months before developers start implementing and discover that the sketches are all wrong, sending new work backwards into the system.
“Does that include the reverse gear?” Erik asks. “That model doesn’t have a reverse gear,” Wes replies quickly. ⚡️
The Phoenix Project is written by Gene Kim, Kevin Behr, and George Spafford. In this article, Gene Kim describes The Three Ways: The Principles Underpinning DevOps that are used in the novel. 👇
Systems Thinking 🚀
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department
Amplify Feedback Loops 🔁
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.
Culture of Continual Experimentation and Learning 📚
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.