A lifetime or so ago I studied management and spent much time reading and thinking about the book, “The Goal” written by Eli Goldratt. In the book, Goldratt sought to impart his theories about the management of a manufacturing organization through a fictional story about the protagonist’s journey of discovery to manufacturing excellence. Having read the book, I was interested to hear that a group of authors had borrowed Goldratt’s method to write a book specifically looking at IT operations.
The Phoenix Project bills itself as a novel about IT, DevOps and helping businesses win. Essentially it tells the story of “Parts Unlimited” and automotive parts company in the midst of disruption and IT-enabled reinvention. The hero of the story is Bill Palmer, a Director of Midrange Technologies, who is suddenly promoted to VP of IT Operations. The company is in the midst of a large IT project that potentially holds the financial future of the company – as such it has pressure from specific business units to deliver, barriers from security and audtiing and individual executives throughout the organization who expect their pet project to be a key priority.
In the midst of this mayhem, Palmer meets Erik Reid, a mysterious kind of an IT operations Jedi Knight who shows him the path to enlightenment through the application of the “Three Ways:
The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that’s what’s between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery
Reid takes Palmer on a journey of agile enlightenment – showing him how positive team dynamics, a culture of enablement, realistic approaches towards compliance and audit and dev and ops teams who are motivated by each others drivers, can lead to an IT department that delivers on that fabled objective of being a strategic enabler for the business.
This form of educational book – delivered as an entertaining novel, is a tried and true method. By writing in this style the authors, DevOps thinkers and practitioners themselves, ensure that the audience will be gripped by what is potentially a dry topic, and taken on a journey that will hopefully lead to their own realization of what it takes to make IT effective again.
I came away from reading the book with some mixed emotions. Initially I was a little frustrated, with something of a “of course this is the way to solve these problems, everyone knows that” impression. After taking a moment to think about it however, I cast my mind to the IT organizations I’ve had dealing with that, almost invariably are dogged by the problems that Parts Unlimited faces. A culture of denial, extended timelines, and adversarial attitude between IT and the business and no real understanding of agile, not as a development methodology but as a business one.
I came to the realization that what is blindingly obvious for me, is comparatively new for most IT practitioners and that the book fills an extremely important niche in the development of something that I’m particularly passionate about, a business-centric focus within the IT department.
Of course the novel makes it look like IT reinvention is an easy thing to do – alas the reality is quite different and I can imagine a host of IT leaders who will read the novel and then be frustrated that they’re unable – because of organizational culture – to apply its learning’s to their own situation. But as a general motivational guide to trying things out and being prepared to fail quick and fail fast, the novel is extremely important.
In my view this isn’t so much an IT management book as it is a book about management generally. I spend time waxing poetic about the massive changes facing businesses and how fundamentally different the business of the future will look to what exists today. If this is indeed the case, then the business as a whole needs to take the lessons from The Phoenix Project and apply it to its own situation. It needs to learn to work collaboratively, to deliver solutions in an agile manner and to not use compliance and regulation as a crutch to justify an orthodoxy that is passé at best, and downright toxic at worst.
Solving the issues that face IT in particular, and organizations in general, is more about people than it is process. Underlying the central thesis of The Phoenix Project are some theories about the way humans act, react and interact – it’s the sort of book that would prove useful to anyone involved in managing projects and people – a must read for the bookshelf.