The Phoenix Project

The Phoenix Project uses a fictional story of a dsyfunctional IT deparmtent to explain how several management/orgniational strategies (e.g., lean development or the three ways) can come together to create a highly productive company. It is a fun read and great use of time, though its fictional nature undercuts the impact of its arguments.

The book is told frm the point of view of Bill who has had success in one area of IT and recently finds himself promoted (nearly against his will) to head of IT. The company has been failing to keep up with competitors and the future of the company all lays in launching the eponymous Phoenix Project. Bill learns there is a ton of disfunction to overcome.

There are many exaggerated characters in the book each of whom highlights different problems encountered at companies. This is a big part of what made the book so fun for me. Watching these hyperbolic characters fail because of their one-dimensional flaws reminds me of people at work who made the same decisions. Watching them get their come uppance is a kind of revenge tick.

Because the characters and story are fictitous, it makes me wonder sometimes if the results of following the suggested strategies are also fictitious. I feel like the book needs some sort of companion with examples of how these things have worked out in real companies, otherwise the suggestions come off a bit too idealistic.

This book is focused closely on IT but I still found it relevant to my work as a software engineer. Some of the issues IT face in the book relate closely to challenges I have encountered, e.g., going from monthly to daily binary releases. Also, there is a development team that plays a part in the book though there are not central to the story.

I don't want to give too much more away, but I would like to highlight a couple quotes that I really enjoyed.

Impression of Developers

Developers are even worse than networking people. Show me a developer who isn't crashing systems and I'll show you one who can't fog a mirror. Or more likely, is on vacation.

I like this funny caricature of how people perceive developers. I think often, software engineers are seen as folks in an ivory tower who push changes without testing them and rely on QA or IT teams to deal with the fallout from bugs that happen. I have encountered this issue often in my career too. I think it is an important reminder of a stereo type we need to combat.

Tight, Immovable Deadlines

My heart lurches as all the implications sink in. I’ve seen this movie before. The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unnaceptable shortcuts to hit the date.

This was the line that convinced me that this author has been around the business for a while; this summarizes perfectly what happens all the time. I have worked on many projects where the data is an immovable object. As described, what ultimately suffers is the testing phase and it is often easy to ship a product with lots of bugs.

This describes well what the symptom is, the author later gets into what solutions look like.

Commitments

“We can't make new commitments other people when we don't even know what our commitments are now!” I say. "At the very least, get me the work estimate to fix the audit findings. Then for each of those resources, tell me what the other commitments are that we're going to be pulling them off of.”

The beginning of the book is spent describing a nightmare hellscape work environment. In it, the IT team is constantly putting out one fire after another. All the while, the important Phoenix Project work is never getting prioritized. It is at this point in the book that Bill learns that his teams have no clear plan of all the work they are currently committed to. This was one of many examples of problems tech teams fall into that I hadn't experienced and it made me grateful.

My product area leans heavier on the planning side. We do quarterly planning and annual planning. It takes a lot of time to put it together (there are a ton of teams to get on the same page) but at the end of all that work, we have a clear list of projects that we are committed to launching (with engineering estimates and owners to boot).

Bottlenecks

Any improvements made anywhere besides the bottleneck are an illusion.

Eventually, a Gandalf-esque character emerges who gives Bill wise albeit vague advice based on things like Toyota's lean principles. One of the most important ones is identifying the bottleneck in the system and being sure to protect and improve that bottleneck.

The idea comes from physical manufacturing. Imagine you are producing widgets and there is one painting machine in the middle of the assembly that is the bottle neck which can paint 10 widgets per day. You can speed up the machine that creates the unpainted widgets all you want but doing so will never get you more than 10 widgets per day.

This book makes the argument that problems that arise in physical production plants are similar to the ones that arise in tech development companies. Therefore, strategies like lean principles that worked for physical production plants also work for tech development. One key strategy is finding bottlenecks and protecting them from unplanned work; if the bottle neck spends its time doing anything than painting widgets, you'll never hit your 10 widget per day max output.

In the book, the bottleneck happens to be (hilariously) one heroic IT developer. In my experience, bottle necks are very real. I am in the process of figuring out where the bottlencks are in a team I manage. It required carefully tracking all of the change requests that came in for that team and then marking the work started and work ended dates for all the steps in that work. This was something introduced to me as “value stream mapping.” It was a lot of work but it let us identify that, in this case, the bottleneck is the time it takes to hammer out the requirements.

Business Requirements

They are like kids in a candy store. They read in an airline magazine that they can manager their whole supply chain in the cloud for $499 per year, and suddenly that's the company initiative. When we tell them it's not actually that easy, and show them what it takes to do it right, they disappear. Where did they go? They're talking to their Cousin Vinnie or some outsourcing sales guy who promisies they can do it in a tenth of the time and cost.

Hot damn, this summarizes pretty well how leadership can sometimes pivot to new projects du jour. The callout for cloud reminds me of that mania. You can just as easily swap it out for social, or tablets, or mobile, or the newest hotness AI.

Trust

In order to have mutual trust you have to be vulnerable

I have always found this to be true of the managers and leaders in my area that I look up to. The ones who are willing to be transparent or give their honest hot takes on subjects, e.g., layoffs these past couple years, are the ones I find myself trusting.

Where Do I Fit In

As part of the First Way, you must gain a true understanding of the business system that IT operates in. W. Edwards Deming calls this ‘appreciation for the system.’

This is one of the last a-ha moments for Bill. He finds out that his department does not understand how it fits in with the larger business. Bill goes off on a fact gathering adventures that gives him the context about what the business is trying to do and it helps him prioritize which projects to work on (among other things).

I wanted to end with this quote, because it ties so nicely with the first one. When we as software developers don't understand what the bigger picture is, it is easy to launch features that lead to bugs.

Wrapping it up

There is a lot more to the book I am not covering because I don't want to give it away. I really enjoyed reading this and strongly recommend it to anyone leading or contributing to a technical team. The novel-based approach the author took made it fun and easy to read.

This book gave a great idea of the many dysfunctions tech teams can run into. More importantly, it tied together dozens of resources for how to solve those dysfunctions. Instead of just lecturing and citing sources, it applies those resources in the context of a fictional company, leading to an accessible read.