The Phoenix Project - Thoughts and Review

Published: 2015-05-25

Tagged: readings

Words like "deadline", "failure", "QA", "project", "scrum" are familiar to most people who choose to work in the IT sector whether they're network administrators keeping packets flowing, software developers trying to translate real world decisions into "business logic modules", business intelligence folks trying to make sense of whacky numbers, or system administrators making sure services are up for everyone to use. This sharing of pains burdens has produced a subculture that feeds on humor, making fun of users/hr/marketing, and sometimes even building amazing things.

It seems it's only natural that this subculture created a book that describes a project that's doomed to fail, backstabbing marketers, clueless business people, looming deadlines, and makes it a fun read. What kind of sicko spends 8 hours a day in front of a screen, pushing business logic through an interpreter, only to go home and read about a fictional character trying to push a late project into production despite all odds? Probably the same person who stayed up until 2am to finishing reading Neal Stephenson's Cryptonomicon and someone who gets excited about things like data structures or continuous integration. If you can't get enough of those things and you want to broaden your knowledge of the real world realm of IT, you're likely to enjoy The Phoenix Project.

The book is really a critique of antiquated management practices that produce horrible software products. At the same time it gives suggestions and themm describes via fictional events and characters, trying to show that there really is a better way. Anyone familiar with Agile, Lean, the Toyota Way will quickly pick up on these ideas and get bored quickly. For the rest of us, it will be a gentle introduction to these ideas. This is great for initiates to the field. Why?

We read time and time again Don't Go Dark. Don't be that programmer in a cave. I think all of us would love to close ourselves in a dimly lit room and do our job without outside interference. Keeping the network running smoothly. Refactoring tons of code. Dropping fat and useless tables. This is what we imagined we'd be doing since childhood, right? We are the hackers, the heroes fighting bad code, inefficient queries, and network intruders. Amongst our own, we can talk hours of our glorious battles that no one outside our circles can even comprehend. Alas, that's the surest way of stabbing yourself in the back. This book and what little experience I've collected have shown me that programming because you love it and programming for money are two different worlds.

If you wish to program for money because hey, it's still doing something you love and you'll be getting money, you have to shift your perspective. What if you don't? You'll quickly become "that IT guy" that gets some things done but more often than not you'll be the weird person who missed deadlines and speaks mumbo jumbo. This can easily lead to an unfulfilling career. Why's that bad? No more interesting tasks. No fun jobs. Can't get on good teams. Work on low value projects. Being on the verge of burnout and finally burning out. Might as well quit now and take up carpentry and retain your love for pushing bits by doing it as a hobby - just like when you were 12 when you first discovered BASIC/HTML/DOS/etc.

The Phoenix Project will quickly acquaint the reader with modern management practices and why they're valuable. This will translate into choosing better jobs and making your current job a bit better. It'll outline the importance of communication. From there on it's only a few steps to reading the excellent Getting Things Done When You're Only a Grunt by Joel Spolsky and then onto The Pragmatic Programmer and many other excellent books. Oh, and you'll get to keep your passion of figuring out what makes things tick - and makin' 'em tick better.

Most of all, it will give the reader a broader and more general view of the immediate environment around them. Suddenly, project managers aren't bullies - they're trying to manage expectations and marketers aren't stupid - they're trying to get people to use your work so you can enjoy paychecks. It's liberating to know that IT isn't some sick worldwide psychological experiment to make you suffer.

"But wait, what about the book?!" you may ask, gentlereader. Indeed, what about it? It's definitely not the best prose. The characters are pretty simple and the plot easy to guess. This is no George Orwell or Thomas Mann. Yet, I still had a ton of fun reading about how the protagonist escapes IT cataclysm after IT cataclysm and how slowly, with the help of a few people, he's able to turn the project around.

It doesn't leave the soul-ache of finishing a particularly deep passage about the human condition, instead it offers a constant evaluation of ones own work and organization. Am I that programmer in the cave? Is my team communicating anything? Are we producing any value to the business? Are there bottlenecks we could optimize? If our current project is so bad, can we improve it? How about the next one? What if we tried this whole "kanban" thing?

If you've still cutting your path in IT, whether as a network engineer or web developer or anything in between, you'll definitely enjoy this book and probably rethink the relationship between your love of solving problems and doing that for money.