By James Kaplan
Sometime back in the early 1990s, when I was working as the chief technologist for a goofy little start-up outside Boston, I stumbled on The Goal, a novel by Eliyahu Goldratt, and I thought it was a revelation. In an era when it seemed that American business couldn’t do anything right, The Goal seemed to offer a direction for revitalizing American manufacturing and the American economy as a whole.
Many years later, a client suggested I read The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford, which is a beat-for-beat application of Goldratt’s book to enterprise IT infrastructure at a fictional company, Parts Unlimited, with an underperforming IT organization. Think of The Phoenix Project as being to The Goal what Apocalypse Now is to Heart of Darkness or, less darkly, what Clueless is to Emma. It was also a revelation, synthesizing a whole new way to think about infrastructure: faster, more responsive, and less bureaucratic.
Gene Kim’s The Unicorn Project is less a true sequel to The Phoenix Project than a complement to it, focusing on application development at Parts Unlimited rather than infrastructure. Like The Phoenix Project, it is probably not as good a novel as The Goal, mostly because of its schematic characterizations. Everyone at the company either assists or hinders the protagonist in her quest to use technology innovation in the service of customer value. The villain is so villainous that I expected her to grow a mustache so she could twirl it, Snidely Whiplash style. How much more interesting it would have been to dig into why she wanted to slash IT costs.
Literary elegance aside, The Unicorn Project is full of interesting points and insights, especially on how dysfunctional enterprise IT can be. Here are a few points that really stood out:
- Disregard for developer experience and productivity. How much time do most corporations lose as developers wrangle with building environments, getting access rights, and other tasks that have nothing to do with automating business processes or modeling business data? Yes, we might all know this, but The Unicorn Project makes the pain and waste tangible for those who haven’t had a chance to experience it firsthand.
- Creating challenging dependencies in desire for scale. Decisions to drive scale often create dependencies that different teams must negotiate across value streams. For example, when procurement decides to replace three smaller switches with one larger one, three different vendors fight over the same switch, sometimes overwriting each other’s configuration changes. The impact on service reliability is not positive.
- Dysfunctional funding processes. Parts Unlimited prioritizes tactical features (each one of which will return the business to revenue growth!) over the structural improvements that will allow implementation of hundreds of business changes that will enable experimentation and learning.
- Wasted time in implementing new functionality. The “wrench time” in building functionality takes only a fraction of the time that elapses between request and go-live, often because business leaders fail to engage on requirements in a timely or effective way.
- Antiquated and inflexible architecture review. At one point, the company’s architecture board nearly stops our heroine in her tracks by refusing to sanction the technologies required for success. Quite correctly, through the plot, Kim implies companies should think about architecture in terms of standardized and consumable services rather than binders full of standards and enforceable by a review board.
- Infrastructure model built around handoffs. Significantly, Parts Unlimited has an IT-operations, rather than an IT-infrastructure, function. As a result, it has a dynamic in which application development introduces new functionality and then hands off responsibility to operations, which oversees production. Over the course of the book, the company starts to evolve from a functional to a services model, one in which application teams consume highly engineered, lower-level services.
Kim made one point that is perhaps more surprising and unexpected than others. His protagonist passionately advocates for functional programming languages and styles as more effective in reducing complexity and dependencies than object-oriented languages. This bears more examination.
The Unicorn Project really brings to life the challenges, dysfunction, excitement, and possibilities in a critical technology-development project. Yes, there a few over-simplifications. When did you last come across a major enterprise-technology project with not only a manual build process but also no documentation of that process whatsoever? And while I always love a good IT cost-management subplot, the book makes it sound a lot simpler than it actually is.
All that is small beer. As essential as The Unicorn Project is, its literary failings prevent it from being even more valuable. Real executives in real companies (and especially in real enterprise IT functions) can’t be divided into heroes who want to innovate and villains who resist new approaches. They make combinations of good and bad decisions, using emotional and rational decision mechanisms based on both idealistic and self-interested considerations. Digging a bit into this—and how to create the correlation of forces required for change—would have made an invaluable book even better.
James Kaplan is a partner in McKinsey’s New York office.