How strongly do I recommend The Phoenix Project?
10 / 10
I love the Phoenix Project. This book offers three special things:
I can easily imagine discussing this book with my engineers, especially those stepping into leadership roles.
Top Ideas in This Book
When business execs feel like tech teams lack a sense of urgency, they often demand long hours implicitly or explicitly, cascading into developer resentment and burn out. This is often coupled with delayed product deliveries that don’t even meet the underlying business needs.
Sometimes you need a senior engineer but if only a senior engineer can be productive in your system, it’s a sign that your team cannot grow effectively. Not only would your team fail to meet the expectations of a growing business, but could be the limiting factor preventing the business from growing.
Struggling teams often get process-y and more struggles snowball into more process. But process only matters when people adopt it, a tough pill to swallow for the process creator.
CEOs and other execs frequently wield their power through backchannel requests directly to individual contributors like engineers and designers. In the short term these heroics get celebrated, but in the long term lead to unpredictable availability and a cascade of delays on other projects.
A younger version of myself would argue that iterative knowledge work is nothing like manufacturing. But today I’m not so sure.
As a manager, I apply lean manufacturing concepts to my team’s work and environment, seeing consistently positive impact.
In my experience, work in progress is easy to create and hard to kill.
Engineering managers and tech leads need eternal vigilance in identifying WIP and supporting their team in killing it.
It’s easy to improve things we’re already good at because we enjoy that work.
But real progress depends on breaking through our limiting factors.
Unplanned work and WIP go hand-in-hand. Something unexpected gets added to our plate, increasing WIP. Planned work takes a back seat and never recovers because the unplanned work is by definition not accounted for in the project schedule.
Software teams often know what their issues are, even if occasionally hung up on minutiae, but they often lack the political power to address the problem.
Outside mentors can provide some political coverage to support change, but ultimately the team enacting change needs to deliver on that promise.