The Phoenix Project is a story about IT and the man who is thrown into managing it. It shows the day-by-day interactions between the executives, employees, and everyone in-between. We learn about project management, product management, software development, operations, and even some politics.
The Phoenix Project is the newest innovation in the company that will make them more competitive and profitable. I understand it as the great big project that will put everyone and the business on the map. There’s a lot of work to be done for Phoenix. We quickly learn it’s overly ambitious and no one’s expectations are managed properly.
I love referring to the Project Management Triangle. It’s a graphic that basically states:
Cost, quality, time — choose two.
Toward the beginning of the story when we’re learning more about Phoenix, there’s a lot of discussion about how the current technical team is being stressed too thin with bigger feature requests, less time, and less money. Eventually, this leads to more and more features getting delayed. The Quality Assurance team ends up catching more broken features for each one that gets fixed. The past time crunches and rushing seem to have harmed the company even if they brought instant gratification when they were initially implemented.
It’s a real eye-opener when you don’t realize there is true damage being done by building another feature and adding more complexity to your project. Deployment intervals were being lengthened just for the opportunity to build more features which ultimately causes more bugs than anything else.
The company the story revolves around is less important than the day-to-day operations that occur inside it. It is fun to create an entire world around the main story, though.
Think of Lord of the Rings and Game of Thrones - half the fun of these worlds is learning about the different languages, colonies, worlds, reading and marking up the maps, and whatnot.
Although Gene Kim, Kevin Behr, and George Spafford don’t create an entire universe as complex as Harry Potter, they do use common and popular methodologies, techniques, and management principles that really help the reader relate.
Mixing the unfamiliar and messy aspects of the poorly managed Parts Unlimited with the well-known and proven workflow techniques like Kanban and Agile does a great job of engaging anyone who works in a similar environment.
Personally, this story touched me at exactly the right time in my career. I was working at a fresh startup with a small technical team with big ambitions (and big, complex, features).
We were always debating about spending the next month taking care of technical debt, building new and shiny features, or even building a counterpart web-app. One of the most inspiring parts of The Phoenix Project was when they decide to halt all feature development.
It’s shocking because we think of new features as exactly what you might need to acquire new users and more revenue. However, the true value of a software company lies in its reliability — you only get that with quality and properly built technical stack.
Nowadays, the book may seem superfluous since much of what is discussed is standard practice. It took many companies like the one in the book doing what they were doing for everyone to buckle down and realize there are correct ways to manage projects and people. This doesn’t take away from the fact that the novel is extremely well-written and quite fun to read if you enjoy learning about different systems and methodologies while feeling the pressure and suspense from the higher-ups in the company.
Ultimately, Parts Unlimited is an interesting company to read about with interesting people in charge. The story is exciting enough to read for fun but has the huge added benefit of learning how to manage along with it.