About the book
The Phoenix Project is an IT leadership fable, using the story format to demonstrate the growing role of software engineering within businesses today and showing the reader how best to work across disciplines to help their business win. The book follows Bill, an IT manager at Parts Unlimited, who is given the overwhelming task of ensuring the success of the business critical “Project Phoenix”, a project that is massively over budget and very late. With the help of a prospective board member and his mysterious philosophy of “The Three Ways”, Bill slowly unravels the path to success within his organisation.
My thoughts
After finishing the book, I would say that the most pleasant surprise was how enjoyable it was to read, using the fable format effectively to engross the reader in the transformation that takes place at the fictitious company, Parts Unlimited. The prospective board member Erik is a clever addition to the fable, providing a mechanism for the author to deliver more in depth information and insights to the reader. In my eyes, the biggest strength of the fable format is that it enables the book to go beyond simply explaining the key concepts as it showcases how they could be implemented within an organisation and the value you could expect to gain.
Amongst the chaos of server outages and general unawareness of what’s really happening on the ground, Brent quickly emerges as a key character, and is someone I’m sure many IT professionals will quickly recognise – but more on him later. The book goes into depth discussing the importance of the flow of work, likening IT to a manufacturing plant, where work moves from station to station. I liked how Bill’s team quickly got a handle on the tasks, eventually introducing a Kanban board to manage the flow of work. Bill identifies the different types of work (business projects, internal projects, operational changes and unplanned work), and implements strategies to prioritise these appropriately. Coming back to Brent, I really liked the inclusion of his character and found how they were able to share his knowledge across the team and remove him as a bottleneck fascinating. The theory of constraints came into play here – this states that any optimisation made at anywhere other than a constraint is an illusion, and while it may seem obvious, this was really profound for me.
The book discusses the movement within DevOps over the last few years to empower developers to increase deployments, and delves into how this (perhaps counter intuitively) actually improves system reliability by getting rid of risky big bang deployments, and enabling hotfixes to quickly make their way to production. It covers the processes used to enable this, including immutable artefacts, and matching environments – made easier using scripting. Importantly, it also goes into the complementary processes that should be put into place to increase business confidence, ranging from automated functional and non functional testing to critical systems monitoring. It even goes further to discuss advanced techniques such as chaos engineering (used at Netflix), showcasing how Parts Unlimited adopted the “fail fast” culture, introducing random infrastructure errors into their live environment, enabling them to rapidly improve their security and resilience.
Finally, and crucially, the book moves beyond purely IT to discuss how the real key to success is in understanding business goals and figuring out how IT can organise itself to best support these. KPIs (Key Performance Indicators) are covered as an effective technique to set, measure and track progress towards these key business goals. This allows the team to competently assess incoming work and reject or prioritise it accordingly by evaluating it against these KPIs. It also enables the business to assess the success of a team/project and provides transparency to other areas of the organisation. The book explores how IT should look to work across both IT and organisational boundaries, and goes even further to claim that IT is increasingly becoming the core of all large businesses. It states that industries which do not recognise the importance of IT operations and embrace the DevOps culture moving forward will leave themselves vulnerable to being disrupted – a reasonable statement as we see companies like Amazon doing this almost daily.
Closing thoughts
Overall, I would highly recommend this book to anyone working within the realm of IT (operations, development, QA, etc). It’s not only an enjoyable read, but also thoroughly insightful and educational, going beyond the theory with real world examples.