The Phoenix Project
The Phoenix Project is a must-read book for anyone who works in technology. If you have ever worked in a larger company you will immediately identify with the situation described at the beginning of the book. You have an overworked IT department that seems disorganized and is always behind on everything because they are constantly busy fighting fires. Most notably one "super-engineer" seems to be involved in every project since he's the only one who knows how it all works. The IT department is also constantly at odds with the rest of the company: developers, security, finance, and marketing. The book is really about how to tame all that chaos.
DevOps
This book is at the heart of the DevOps movement. I started hearing about DevOps, long before I actually understood what it was. Like Agile and many other topics in software development, it is often misunderstood. Just like Agile, it tends to get confused with the tooling. Some people think that just because they use Jira they are Agile. Some people think DevOps means using Kubernetes and Docker. At its heart, DevOps is not about tools at all, it's really about breaking down the silos between developers and operations and getting everyone working together on the same team. The heart of the book is really how all these different managers and groups work together and reorganize the way they work in order to save this company.
Theory of Constraints
The book also hits on a lot of topics around Lean and the Theory of Constraints. There is a character, Eric, who is kind of the Yoda of the book. He keeps going on about the Theory of Constraints and the flow of work through the system. Without spoiling the book too much, one particular engineer, Brent, is always involved in everything and so he becomes the limiting factor. A large part of the book is: how do you identify the limiting factor? Then once you have that information, what do you do with that? According to Eric, part of the trick is to take a systems-level view and look at the flow of work through the system and maximize that. The goal is to have a steady predictable flow.
Fire Fighting
Another idea that comes up in the book is the vicious circle of firefighting. Most of us have experienced it. You have an important project you are working on, but you get pulled off for an emergency. Because you get pulled away, the important project suffers and you deliver something that is less than your best. This introduces bugs, which become future emergencies that then interrupt the next major important project and the cycle continues. A large focus of our Mastermind group and a large focus of the book is getting people out of that loop by taking time to think more strategically.
More on DevOps
If you want to learn more about DevOps, I thought this podcast episode was pretty good. It does a really good job of explaining what exactly DevOps is and why it is important. It really captures the mindset behind it. The guest Jeffery D Smith also wrote a book on DevOPs. I have copy, but just haven't gotten around to reading it yet.
SE-Radio
