Book Review: The Phoenix Project
I read The Phoenix Project only a month ago, and already it has made me rethink my agency’s approach to getting things done. We are not a DevOps organization, for whom this book was written. But we do cobble together a wide variety of skillsets and activities to create value in our quest to help managed service providers (MSPs) grow healthy, sustainable sources of sales leads.
Despite the differences between digital marketing and software development, the similarities between the problems we experience are compelling. I used to wonder why it seemed so hard to run a profitable digital agency. Now, seeing the complexity of our work (for the first time) and identifying with the faulty thinking employed in pursuit of efficiency, I ask myself how we’ve survived for seventeen years.
The concepts described in The Phoenix Project are not new, the most significant of which are traceable directly to a business classic from the eighties, The Goal, authored by Eliyahu Goldratt. Both books are allegories, The Phoenix Project borrowing in form from The Goal to recount a journey from chaos to order inside UniCo, an automotive parts manufacturing company. But whereas The Goal’s conflict arises from problems encountered on the manufacturing floor, The Phoenix Project examines the challenges faced by UniCo’s IT department in its effort to build, deploy and support a sophisticated customer-facing software application in the firm’s bid to gain competitive advantage.
The Phoenix Project reveals issues at the root of a massive cost overrun and multi-year delay in launching the new software. It highlights how those problems grow not just in spite of, but as a result of what seem to be logical measures taken to overcome them. Thanks to a wise and eccentric new board member, a brand new VP of Information Systems, the story’s hero, is introduced to a new way of thinking. Or three new ways, in fact. The Three Ways, the collection of principles and philosophies espoused in The Phoenix Project, might be described concisely in these decidedly not-so-techy terms:
Ship something. Sooner rather than later. Better to ship a product in one week than to ship a product with three times as many features in three weeks. Work continuously to shorten the time to ship.
At every stage of value creation, from idea through realization to delivery, ensure that feedback happens, and that it makes its way all the way back to the beginning, through each of the stages.
Test and experiment continuously. Take risks. Learn from failure.
Nearly all of us are responsible for delivering some form of commercial value. Many of us perform tasks as part of a larger team and collection of activities, and some of us may even be responsible for those teams and what they produce. Could these principles of DevOps, the Three Ways, hold a secret to improvement of outcomes in other industries or contexts? Based on what I’m seeing in my own organization, I’m willing to say “yes” without reservation.
