Books for software engineers and managers

The Phoenix Project

A Novel About IT, DevOps, and Helping Your Business  Win

by Gene Kim, Kevin Behr, George Spafford

Categories:
Favorite,
CTO,
Engineering Manager,
Tech Lead,
Star Engineer

Technology teams often fail to understand the business context they exist within, causing business execs to complain about lack of  urgency

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.

If you feel like only senior engineers can be productive in your environment then hiring only addresses the symptom not the  problems

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.

A process can only be great if people adopt  it

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.

Individual heroics are often initiated through backchannel communications and corrode the overall  system

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.

Software development is iterative knowledge work, but improves with lean manufacturing  processes

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.

WIP is the silent killer of software projects and the most important thing to  visualize

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.

Any improvements made to non-bottleneck steps are an  illusion

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 is the most destructive  kind

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.

Outside mentors can sometimes plainly see the deeper issues your team struggles with and provide political coverage for addressing  them

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.

The Phoenix Project

How strongly do I recommend The Phoenix Project?
10 / 10

I love the Phoenix Project. This book offers three special things:

  1. A look into failure. Most books about software development explore success. The Phoenix Project is about failure and the multitude of causes.
  2. Realistic conversations and relatable characters bring a human lens to the complex problems that technology teams face. You can study the concepts of Accelerate and The DevOps Handbook all day, but you still need the human context and application to be successful. The Phoenix Project provides a real world frame to these ideas.
  3. The Phoenix Project is a novel and reads very quickly.

I can easily imagine discussing this book with my engineers, especially those stepping into leadership roles.