A few weeks ago I picked up a copy of The Phoenix Project and started working through it. This is one of those books that I frequently saw popping up in discussions of IT management, and it seemed worth reading because it is such a common reference point. The first thing you’ll notice about this book is that it’s in that fun genre of “fictionalized case study” and reads like a novel. My first encounter with this genre was The Truth about Employee Engagement, which tells the story of long-time corporate manager Brian trying to turn around a struggling Tahoe Italian restaurant and motivate his employees. It had a memorable narrative and was breezy read; it was also effective at imparting a few simple suggestions about what motivates employees.
Anyway, The Phoenix Project is in the same vein only much longer. It has a cast of about a dozen characters, each of whom you will get to know pretty well after 300 pages. This is not a short book, but it remains engaging and ends right when it seems like it’s about to overstay its welcome (there are only so many interesting kinds of production outages). The book brings you behind the scenes of a severely dysfunctional automotive parts company: Parts Unlimited. You feel vicarious horror as the company experiences catastrophe after catastrophe - payroll system error leads to missed payroll, all-night roll out of new system bricks the registers at all retail stores, new code is leaking customer credit card information. It does a good job of demonstrating almost every sort of IT disaster, and I’m sure if it were written today it would also include a ransomware episode.
There are also many strained relationships between company executives and IT and between IT managers in various areas (development, operations, service desk, security, etc.). Eventually the protagonist, the newly-conscripted VP of IT Operations, Bill, meets the enigmatic Erik, a DevOps and business philosophy mouthpiece, and Bill starts to implement some changes that slowly turn the ship around. I know that we are supposed to view Erik as eccentric and unconventional, but he comes across as obnoxious and as a distracting author stand-in for when they can’t find a way to convey their messages through plot. Erik spends a lot of time visiting an on-site manufacturing plant with Bill, name-dropping business management books, and making IT work sound a lot more esoteric than it is. Here’s a fairly representative paragraph that comes from Erik
“Very good,” he says. “You’ve put together tools to help with the visual management of work and pulling work through the system. This is a critical part of the First Way, which is creating fast flow of work through Development and IT Operations. Index cards on a kanban board is one of the best mechanisms to do this, because everyone can see WIP [work in progress]. Now you must continually eradicate your largest sources of unplanned work, per the Second Way” (p. 161).
In the end, the initiatives that Bill discovers through Erik make sense and are helpful. These Buddhism-appropriating “Ways” of DevOps are to break down work into fast, small chunks as it makes its way from dev to production, to provide fast and automated feedback on this work, and finally to develop a culture of taking smart risks and investing in improving IT processes (p. 356-7). This is supposed to be a contrast to systems with multi-year projects with a spec sheet that slowly inches its way towards a one-time production release. Examples of concrete changes that Bill makes include automating the creation of QA and dev environments so they match production and can allow for accurate testing, and outsourcing a cafeteria POS system that creates all sorts of problems and is not central to the company’s core business.
One liability for Parts Unlimited on whom the book spends a lot of time is Brent. Brent is an IT operations employee who seems to be the only one who knows how things work and who seems to know how everything works. Brent is a liability because so many implementations depend on him, and when there are production outages, he’s the only one who knows the fix. Brent is a great plot point, because he illustrates a common IT organizational problem: having only one employee who really understands how a critical system works. In The Phoenix Project, the Brent problem is managed by more closely monitoring and prioritizing Brent’s work so that his efforts go towards the most business-critical projects and tasks. Ultimately, this seems like only a partial solution; it doesn’t mitigate the risks of super-talented Brent taking his talents to another organization or getting hit by a bus. That is a much harder task and involves having enough motivated and communicative staff members to implement cross training in every important area.
One tacit theme throughout the book is the importance of integrating IT into every part of the business. When IT projects start turning around at Parts Unlimited, it isn’t just because they put together some kanban boards and ship a dozen deployments a day. IT managers start working with execs in sales, marketing, and other areas to understand what the business is trying to accomplish (e.g. targeted coupons based on customer purchasing behavior). IT is no longer an area that gets random commands and projects from other parts of the company but is instead more integrated into the core business.
Overall, The Phoenix Project is well worth reading, both to gain a solid understanding of all of the hype around DevOps but also to think through better IT management practices in any organization. Next time, I’ll continue these reflections on the book with a focus specifically on lessons for IT in higher education.