Reflecting on The Phoenix Project
Great news for users, organisations and product people
I’ve just finished listening to The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr and George Spafford. I was heartily recommended it as the next step following The Lean Startup by Eric Ries and Lean UX by Jeff Gothelf and Josh Seiden.
However, I must confess to being slightly skeptical. I kept putting it off, listening to other books and podcasts before finally taking the plunge…then stopping and taking a short break about ⅓ of the way in…
I thought to myself, why would I, as a ‘product guy’ — albeit an enthusiastic supporter of DevOps — want to invest time reading something about implementing automation and deployment pipelines?
However, I was intrigued and believed the good intent of the recommendations given so I pressed on, and I am glad I did.
These are my reflections as a product person. I realise this book is not for everybody. Many prefer to learn from facts, rather than fiction — and as a work of fiction, it has many competitors!
The characters are oft times slightly thin, and some of the circumstances seem a little contrived. For example, how do they manage to migrate to the cloud in barely a few pages, perhaps even fewer weeks? In my experience a project like that takes months if not years to get right — and that is with an accomplished team. It was only a few chapters back that this team were unable to get simple ‘old fashioned’ deploys out the door in a traditional server stack…what’s changed?
However that aside, I appreciate the book is seeking to make a point, and it is a point I believe it makes very well.
I concede that I may as part of the discussion let some minor spoilers slip — if that is a grave concern for you, stop now. Go get the book and read it first — then come back! However I will do my best not to spoil too many details for you, particularly since the major premise is fairly well known and easy to find out.
First reflection — this is great news for users
It’s clear key users at Parts Unlimited (the fictional business portrayed in the novel) are unhappy with the current systems in place, and have a lot to gain from a successful execution of the legacy replacement project named ‘Phoenix Project’. Yet it’s not going well.
As part of the rollout users at the stores suffer massive inconvenience, customer cards are charged multiple times and finance users are subjected to days, if not weeks of manual workarounds and intensive paper trails. Not to mention the regulatory non-compliance and anguish of various stakeholders through the business.
Suffice to say (without revealing any further spoilers) the users and stakeholders do get a better deal as the book ends. As part of the changes, not only is old software replaced, but new functionality is added allowing marketing and merchandising to give customer a better deal whilst making increasing profits on higher margin stock.
Overall through these changes teams of users and stakeholders throughout the business are enabled to succeed, and in turn cause the business to succeed.
Second reflection — this is great news for organisations
This is good news for organisations because enabling teams who use technology in the business to succeed enables the business to succeed. However, this is also good news for organisations because it enables those producing the technology (or ‘product’) to succeed.
For Hardworking Brents
The book describes how well meaning and hardworking teams and individuals toiled endlessly but to little avail before the changes were made. One of these individuals was a chap called Brent.
I must confess to earnestly pondering the way Brent was treated. He appears to have been managed as a constraint, rather than elevated crucial component.
You see, I was a Brent once — not in exactly the same way, but still a constraint with fingers in many pies — and I was managed around. My fingers were taken out of pies, responsibilities were stripped back and I was left feeling that I wasn’t capable of performing my role at all, rather than simply being a constraint.
It seems like this was rectified eventually, as Brent was elevated and given support, respected for what he was seeking to do, as a ‘sharer’ rather than a ‘hoarder’. Surely this is the way to approach such difficult situations, where individuals are actually seeking to do their best, and really, just need some support and coaching to succeed.
For Executive Steves
Steve was the CEO at Parts Unlimited. His journey is as valid as any of the other characters.
Throughout the book he gradually comes to realisation IT should not be confined into a single department. He says something to the effect of “we don’t have a department for mathematics — we expect our people to embrace it — why should we have a department for IT, should it not permeate every department?”
The message of this book is that IT, product delivery, or whatever should not be a siloed department where projects, problems or desires are thrown over the wall and expected to be dealt with. Instead technology (or product as I will argue shortly) is a partner with the wider business to make the magic happen by considering the system as a whole, reducing wait times and introducing active feedback loops.
This is a book anyone involved with technology or product delivery should read — be that product, engineering, technology operations, traditional operations, marketing, finance or executive.
In fact everyone in executive leadership should read this. Don’t be put off by the negative reviews — many of these seem to come from folk in the thick of it, who want nuts and bolts to chew over, perhaps even a set of standards to follow.
This book rises above those details and presents an accessible, clear, if stereotypical and slightly exaggerated or stretched portrait of the effect such transformation can have.
I don’t believe for a moment such transformation would be easy though. At some point descent into the detail will be required. Culture will need challenging, processes changed and mindset altered — but I firmly believe it needs to start with people.
Just as John (the CISO) required a dramatic transformation, so will many others to affect such change. Where will it start?
Third reflection — this is great news for product people
Finally, call it what you will — the DevOps revolution, agile, lean or something else — is good news for the product community. Fast delivery, quick feedback and high quality are all things we fully support.
In the book I was disappointed product managers are scarcely mentioned (possibly twice at most) yet I realise it’s written from a technical operations point of view, so that stands to reason.
However I would reinforce the idea that considering the system as a whole (‘plant manager’ vs ‘machine supervisor’) includes product management and in product we are very keen (at least we ought to be!) to work with partners around the business to improve the lives of our users and seek the success of the business.
Perhaps this is one of first places such transformation can begin in a business, or whatever size? One of the dangers I perceive with technology led change is that ‘product thinking’ can easily become outsourced to ‘the business’ (i.e. some other non-technology function) and not given the same rigour as other changes taking place in the technology function.
There is a chance the prevalence of Scrum as a leading agile methodology with its minimal treatment of product has contributed to this. With good reason, the Scrum guide says very little about how product ought to be managed other than the product owner’s role regarding the backlog and the development team.
However this is a dangerous pitfall and a great shame.
In response an IT service management (ITSM) approach can ensue, where product owners or managers are excluded from the team and (perhaps unwittingly) treated as customers, not partners. Additionally because a product owner might be selected from a different function, often with little experience of technology or how technical people think, unnecessary friction can arise.
If I’ve understood the final chapter correctly that’s not where Parts Unlimited wanted to go. And neither should we.
Therefore, in conclusion — why not begin transformation around product management? Get the business thinking about products, over projects. About the full lifecycle rather than a single phase. About quality rather than speed. About feedback and learning over delivery and hoping for the best…
I could probably say many other things: like product managers owning technical debt; or learning from the support desk; or actively supporting technical innovation — but I’ll stop there.
Have a think on it — and let me know your views! I’m off to start reading The DevOps Handbook…
Does this resonate with you? What have I missed? What do you appreciate? Let me know your feedback below — I look forward to hearing from you!
