The Book About IT That Changed How I Think About Everything
I almost didn't read it.
My brother-in-law Mike has spent his career doing something that used to seem unusual but is starting to look like a pattern: he came up through IT leadership and has steadily moved into broader operational executive roles. In 2019, when he was deep in the world of technology and product development, he suggested I pick up The Phoenix Project. My first internal reaction was something close to: who wants to read a book about IT?
But here's the thing about Mike. He doesn't recommend things often. And in my experience, when he does, it's worth paying attention. So I took the plunge.
What I found wasn't a book about IT. Not really. It was a book about how systems fail, why people aren't usually the problem, and what it actually takes to build organizations that can adapt, learn, and survive complexity. I've been chewing on it ever since.
The Problem Isn't the People
The story follows Bill Palmer, an IT manager at a fictional manufacturing company called Parts Unlimited. He gets thrust into a leadership role and tasked with saving a failing project called Phoenix, or the whole department gets outsourced. What follows is a slow, sometimes painful realization: the chaos surrounding Bill isn't caused by incompetent people. It's caused by an invisible, broken system that nobody can fully see.
That framing hit me harder than I expected.
Donella Meadows, in her landmark work Thinking in Systems, argues that most organizational failure is really feedback loop failure. Either the feedback is too slow, too noisy, or, most dangerously, people are measuring and optimizing the wrong variable entirely. The Phoenix Project dramatizes this so clearly you almost want to take notes in the margins.
The most memorable example is a character named Brent. Brent is brilliant. Brent knows everything. And because Brent knows everything, every problem eventually gets routed through Brent. He becomes the human bottleneck of the entire organization, not because he's doing anything wrong, but because the system has no mechanism to surface that problem before it becomes a crisis. There's no feedback loop. By the time anyone realizes Brent is a single point of failure for the whole operation, it's already a five-alarm fire.
This is what Meadows would call optimizing a component while degrading the whole. Everyone was doing locally rational things. Together, those rational things were globally destructive. The authors put it bluntly: "Any improvements made anywhere besides the bottleneck are an illusion."
Small and Steady Beats Big and Bold
One of the ideas from the book I keep coming back to, especially when I'm working with organizations of any kind, is the case it makes for small, iterative change over large, dramatic transformation.
There's a temptation, especially in leadership, to believe that real progress requires a bold, sweeping initiative. A reorganization. A rebrand. A comprehensive new strategy rolled out all at once. And maybe there was an era, maybe in manufacturing, when the goal was to produce a single product as efficiently as possible, where that approach made sense.
But in modern organizations, especially distributed ones doing complex or creative work, the big-push model tends to fail in a predictable way. It takes so long to implement that the environment has shifted by the time you're done. Mistakes compound undetected. And by the time feedback arrives, you've traveled so far down the wrong road that correcting course feels catastrophic.
Small iterations solve this. Not because they're timid, but because they're honest about the nature of complex systems. The book makes this point in a line that stopped me cold the first time I read it: "Improving daily work is even more important than doing daily work." When you change one thing at a time, the feedback is legible. You can actually tell what worked and what didn't. You build the capacity to respond and adapt as you go, rather than hoping your original map was accurate enough to get you all the way to the destination.
This isn't just a DevOps insight. It's what Meadows is pointing at when she talks about resilience. Systems that survive aren't always the most efficient ones, they are the ones with enough slack, enough feedback, and enough adaptability to absorb what they didn't anticipate.
The Leaders Who Can Read the System
Near the end of The Phoenix Project, the authors make a prediction that felt bold in 2013 and feels almost obvious now: the corporate executives of the future will increasingly come from IT backgrounds. Not as a fluke, but as a logical consequence of how deeply technology has been woven into every function a modern business performs. Finance, HR, operations, marketing, customer experience, there isn't a department left that isn't running on technology infrastructure. Which means the people who understand how that infrastructure actually works, where it breaks, and how to design it better are no longer support staff. They're strategists.
I think about Mike when I read that prediction. He came up through IT, and over time has moved into senior operations leadership, exactly the kind of trajectory the authors were describing. It wasn't a detour. It was a direct line, because the skills turned out to be the same skills.
Think about what IT professionals are trained, often by necessity and crisis, to do. They have to trace feedback loops under pressure. They have to find the hidden bottleneck before it takes down the whole system. They have to make decisions about tradeoffs between speed and stability, between efficiency and resilience. They have to see the whole architecture, not just their corner of it.
That's not a technical skill set. That's a leadership skill set.
What The Phoenix Project does, almost accidentally, is make that kind of seeing feel learnable. You follow Bill as he slowly, sometimes painfully, begins to understand the system he's operating inside. You watch the feedback loops become visible. You see what happens when unplanned work stops eating the organization alive.
And somewhere in the middle of a novel ostensibly about IT, you realize the authors aren't just describing a better way to run a technology department. They're describing a better way to lead, and arguing that the people most prepared to do it may have been hiding in the server room all along.
Book: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
Authors: Gene Kim, Kevin Behr, and George Spafford
Genre: Business Fiction / Organizational Leadership / Systems Thinking
Recommended By: Mike (the brother-in-law who's always right)
What's a book you almost skipped that ended up sticking with you longer than you expected?
About Enthusiastic Generalist: This blog explores ideas across disciplines, science, leadership, faith, parenting, book reviews, personal essays, and the occasional deep dive into why the most important insights tend to show up in the most unexpected places. It's an eclectic mix of whatever I find interesting about the world. If you enjoyed this post, subscribe for more on the unexpected connections that make life worth paying attention to.
