Books that Ignite the Imagination

What I Learned from ‘The Phoenix Project’

I love to read. And, although it sounds pretty geeky, I love reading books written by proven business leaders. Every book I read expands my thinking and improves how I approach my work here at Galileo.

I’ve invited Galileo employees to read with me, and we’ve created a culture of reading, where we make books available to all employees and schedule work time to discuss what we’ve learned. The results have been astounding. So, I appreciated it when one of our engineers recommended I read “The Phoenix Project.” I procrastinated, however, because a novel about DevOps sounds totally ridiculous, even though it’s written by IT luminaries Gene Kim, Kevin Behr and George Spafford. My colleague, however, persisted. To get him off my back, I read the book.

And, I know you see this coming: That novel, which cleverly draws parallels between manufacturing and IT environments, highlighted a pain point that was depressingly familiar, but, importantly, offered a new perspective on resolving that problem. The adjustments we made as a result brought almost immediate change at Galileo—just like they did for the book’s fictional company. Within six months, we reduced work flow tickets by 99 percent. Now, when we get a ticket, the average time to resolution is less than 30 days.

Do I mind admitting we were challenged to meet our own expectations to keep up with demand? Absolutely not, because what we’re addressing isn’t just a Galileo problem. It isn’t even a problem restricted to tech companies. It’s a universal problem for any business with work flow that’s handed from one group to another. And, I’m proud that by making a relatively simple change, we improved the environment for Galileo and, importantly, for our clients. The most direct benefit is more engaged employees and happier clients.

So, what’s this book about? It’s about the baptism by fire of a fictional protagonist, “Bill Palmer,” who—kicking and screaming—becomes CIO of Parts Unlimited, a once successful but now failing, auto parts manufacturer and retailer. As CIO, Bill finds himself responsible for a critical, but critically flawed, initiative called the Phoenix Project. Guided by “Erik,” a Parts Unlimited board candidate who is also, fortuitously, an IT operations savant, Bill discovers the answers to his most nightmarish internal IT problems through solutions implemented by MRP-8, a Parts Unlimited manufacturing company. As it turns out, both Parts Unlimited and MRP-8 have the same underlying work flow issues, but—in a manufacturing environment—the problems and solutions are easier to identify because they’re visible. Bill was able to apply lessons from the physical world to his own bits and bytes environment.

For me, the most significant lesson Bills learns involves the bottleneck created as work flows from one department to another. At MRP-8, the bottleneck involves a machine. At Parts Unlimited the bottleneck is Brent. That’s right, Brent, as in a person named Brent, the company’s most talented and hardest working developer, and the guy everyone goes to with “unsolvable” problems. With the best intentions, Brent is a human bottleneck and singularly responsible for stupendous, potentially business ending delays throughout Parts Unlimited. And, interestingly, and a huge population of Parts Unlimited employees are also culpable—either causing or enabling Brent to continue as the bottleneck.

I recognized Brent immediately; although at Galileo, he goes by another name. But, just as Bill does in “The Phoenix Project,” I came to understand the value of extracting our Brent from his position as everyone’s go-to person. It was hard, maybe even painful, to make the decision stick. It was also hard to tell other staff members they had to find a solution without consulting “Brent.” It took several months before we found our new groove but, then, work began to flow smoothly without our Brent in the center of it all, and our Brent began focusing—for the first time in a long time—on his “planned work”—without the distraction of “unplanned work.” (When you read the book, you’ll understand why those words are in quotations). The return generated by sticking to our guns—that is, dislodging our Brent from the epicenter of our IT operation—is real (as described above).

Would we eventually have identified our Brent as the bottleneck and resolved the situation? I’d like to think that we would have. But, reading “The Phoenix Project,” featuring a trouble spot that matched ours in an uncanny way, no doubt provided a shortcut to the solution. At a minimum, we put ourselves on the right path many months earlier than we would have without the inspiration the book provided.

Of course, you can’t read this book and not have your mind buzzing about DevOps, and we have embraced and shifted our culture to include DevOps methodology.

Not every book I read generates the direct return of “The Phoenix Project.” But, there is always return: some more strategic than tactical and some whose benefit takes longer to realize. Even if I disagree with a book, reading it provides insight and context I didn’t have before, and those also are valuable outcomes.

I hope the “The Phoenix Project” might help you if you’re running a demanding organization.

I’m always looking for good book references, so please shoot me a note and let me know what you’ve found valuable: www.linkedin.com/in/tcwilkes.

Scroll to Top