I read The Phoenix Project, A Novel About IT DevOps and Helping Your Business Win (by Gene Kim, George Spafford, and Kevin Behr) shortly after its release; almost 10 years ago. Society, technology, and IT’s relationship with the Business have moved on a great deal since 2013 and I wondered if the book was still as powerful as it was when I first picked it up. So, I re-read it. SPOILERS. This book is almost 10 years old, but I am amazed at how many IT professionals have heard of it, but never read it. First, a quick recap. Parts Unlimited is an automotive parts manufacturer in severe trouble. Its market share is down, and it is being beaten on all sides by the competition who are outperforming the company in innovation and capability. The board is putting pressure on the CEO, Steve, to fix … well, everything. We are quickly introduced to Bill who is offered a promotion to the role of VP of IT Operations and tasked with, essentially, saving the company. Our reluctant hero accepts the challenge and is immediately dropped into a blizzard of Sev-1 incidents, understaffed teams with a lack of capacity and capability, and project pressures from the Business. Bill’s work/life balance gets pushed aside as he fights battles on all fronts while priorities shift under his feet like quicksand. When I first read the book, I was a developer and closely identified with the Brent character, and over-worked full stack developer, and the only resource that could do anything. At the time I had been part of a small business and needed to wear many hats, however even after moving to larger organisations and teams the pressure on my time could be overwhelming. I can now see that my desire to help everyone was, well, unhelpful, but I was unprotected from the telephone calls, emails, and walk-up requests that came my way almost hourly. I was suffering from too many work items in-flight with new tasks coming from all directions without any prioritisation. Inevitably the firefighting would start when something got missed and things went wrong. In The Phoenix Project, Bill is introduced to work pipelines, prioritisation of tasks, proper change management, the importance of limiting WIP (Work In Progress), and most importantly, the concept of constraints. A constraint: the cogs in the metaphorical machine that can’t spin fast enough to keep up. As a “developer-cog” I could relate, and later as a manager of “cogs” I used my experience, working hard to emulated Bill and took responsibility for protecting my people. While reading the book recently, now with many more years’ experience behind me, I empathised with Patty (the change manager), Chris (the development manager), Wes (the operations lead), and most recently John (the Cyber guy). I could now relate their issues to those that I’d had during my various roles and had a newfound appreciation for their situation. The processes, techniques, and advice provided by the book’s mentor, Erik, haven’t changed. but the world around us has. The procedures Bill implements within Parts Unlimited aren’t new, and weren’t new 10 years ago, but now they are more widely understood and accepted. There are fewer barriers to adopting all the buzz words, Agile, SCRUM, Lean, WIP, CI/CD, fail-fast, and of course DevOps. However, one issue that I see too often in companies, both large and small, is a lack of understanding of Technology’s role within the organisation, and its importance in achieving business objectives. Throughout the book the IT department is seen as a blocker, and I’d argue that Bill’s biggest achievement wasn’t better code, or faster and more reliable deployments, but his work to get IT seen as an enabler. This was a game-changer. One of the biggest takeaways from The Phoenix Project: without the Business, IT wouldn’t be needed; without IT there’d be no Business. So, my recommendation is to read the book; it’s easy to read and may help you identify issues in your own situation. However! This is not a silver bullet for all your IT problems. There are no quick fixes and even the story gives a sense of the effort required all levels. If unauthorised “fixes” are going into Production – look at your change management systems. If code quality is poor – look a technical training. If security controls aren’t in place – look at policy enforcement processes. Whatever your issues, there is a solution, and it will most likely touch on each part of the Technology/People/Process triad. I have rarely seen an issue that could be resolved with only one of these three elements. Investing in tooling will only get you so far, but you must also change the culture around the issue and create clear processes for staff to follow. My final piece of advice. Start small. Fix one thing. Then fix another. Then another. As confidence grows and your processes mature, you’ll see improvements, but only if you create measures to track your progress and feedback on anything that doesn’t work. Never knowingly push bad practices forward. Kicking a problem down the road will only create technical debt and come back to cause you even more trouble. I found reading The Phoenix Project again incredibly useful, and even with all my experience and war wounds, there was practical advice that I could use.