The Phoenix Project
I read tech/management books much in the same way that other people (also me) read gossip magazines or watch CNN: to try and understand the ridiculousness of human behavior.
A book I read a while ago was The Phoenix Project, which is the canonical book on DevOps (the fancy IT name for the process of tricking your developers into doing both software development and server admin work.)
I wrote this review a while ago, but didn’t have a good place to publish it. But the newsletter is the perfect place. So here it is!
According to a blurb on the back cover from Tim O’Reilly, "every person involved in failed IT project should be forced to read [The Phoenix Project]."
Hopefully this review will convince you otherwise.
In a nutshell, The Phoenix Project is written as a case study of DevOps, for an audience of IT managers who are no longer technical. It covers the case of “Parts Unlimited”, a creatively-named struggling auto parts retailer with an IT department that can't get its deal together enough to make payroll.
The book is meant to make the reader appreciate how much agile practices such as kanban, and closely integrating operations and development work, can speed up a company's workflow. Instead, what it really does is help you understand why your boss is always stressed out and why American work culture is awful.
We meet the main character of the book, Bill Palmer, coming out of the doctor's office, where he spent the morning with his sick toddler, "trying to keep the other toddlers from coughing on us, constantly being interrupted by my vibrating phone."
Why is his doctor's waiting room not separated into parts for kids that are sick and kids getting check-ups? Why not wait the half hour until after the appointment is over to take a call? These questions remain unanswered, but even in the first page, I'm already stressed out for Bill and everyone that was at the doctor's office with him.
By way of introduction, he says he works "in the technology backwaters" at Parts Unlimited, and it's not entirely clear whether he means that the company is small, that that the tech stack is bad, or that he considers IT to be a backwater with a wink and nod to the C-suite target audience reading the book. We never actually learn what the company's tech stack is, probably because the authors are trying not to focus the reader on the technology, but rather the business problem, but my deep dark suspicion is that PartsUnlimited.com is probably written in PHP, or maybe even Java applets.
We find out within the first couple pages that Steve Masters, the CEO, has picked Bill to replace the VP of IT Operations, who he fired. Bill is not pleased. He says,
I've figured out that the trick to a long career in IT Operations management is to get enough seniority to get good things done but to keep your head low enough to avoid the political battles that make you inherently vulnerable. I have absolutely no interest in becoming one of the VPs who just give each other PowerPoints all day long.
Bill spends the rest of the book making PowerPoints to make his case for IT modernization.
As his first job in the new role, he comes into an emergency. The emergency is that payroll is not working because of some glitch in The System, and if it's not fixed by 5 PM that day, employees won't get paid. Bill reflects,
Suddenly, I realize that my family's mortgage payment is due in four days, and we could be one of the families affected. A late mortgage payment could screw up our credit rating even more, which we spent years repairing after we put Paige's student loans on my credit card.
Do you have ulcers yet?
Bill gets together with Wes and Patty, two senior managers in the IT Operations organization, to try and fix the situation, but he finds them in the middle of a Sev 1 incident related to SAN data.
After much, much arguing and troubleshooting, they finally get the issue resolved, with the help of Brent, a developer who is so valuable that hes always on several projects at once, and is always working until very, very late, because people like Bill, Wes, and Patty constantly keep coming by to ask him things on their way to PowerPoint meetings.
So far, we have:
a stressed executive who needs the job because he can't pay for his mortgage
a CEO who loves firing people like it’s nobody’s business
two middle managers who don't know what's going on, and
a star developer who is constantly interrupted in his work and has to stay late as a reward for his competence.
We didn't even get to the part yet where we meet Bill's spiritual and career advisor (yes), who takes him to a physical factory and extols the virtues of running a software department like an assembly line.
The book only unravels from there. After Bill manages to solve the payroll crisis, even more pressing projects are slapped on his plate. He is constantly undermined by the marketing department, deals with failed website launches, and spends nights and weekends on never-ending burn-out work related to departmental politics.
Can’t wait to be a senior manager!
Ultimately (huge spoiler), he overcomes all these problems and gets a hefty promotion once he Implements DevOps and has everyone working in a factory line like they’re orphans in a Dickens novel. So everyone wins (but mostly Bill and the CEO.)
The book is meant to be a warning against seat-of-your-pants management, and an argument for closer coupling between operations and development in an IT department. Mostly, though, I ended up feeling sorry for how Bill got into a situation he couldn’t back out of. Sometime midway through the book, he writes, "Even though I can't take the entire day off, I take Paige out for breakfast." As he thinks about how stressed he is, he writes,
First and foremost, my most important responsibility is to be the provider for my family. My pay raise will help us get our debt paid down, and we can start saving money again for our children's college education like we always wanted to....with my promotion, we can pay off our second mortgage sooner.
There is nothing more depressing than this part of the book, and, to me, this was the crux of it. The real reason Bill is dealing with the stress of management is not because he wants to and enjoys tackling tactical problems, but because he's forced to - he has no other financial choice.
And here is the heart of the matter - many times, we can try to improve our work environment. But in an IT market that's booming, for both developers and managers alike, it seems like insanity for Bill to stay where he is, and not seek out a role at a smaller company where he'll be more appreciated and can set up DevOps to his heart's content.
In Antifragile, which is a book, unlike the Phoenix Project, that I truly believe everyone should read, Taleb argues that the only way we can truly survive an “unpredictable capitalistic climate” is to be anti-fragile, or flexible, in the face of negative stresses.
The example he gives in the book is that of a college professor versus a taxi driver. The taxi driver is more anti-fragile because he always has to be on the lookout for his next job, and as a result has to hustle, to understand where the market is going - does he need to try Lyft or Uber? Should he learn different skills and quit being a taxi driver alltogether? Whereas the college professor never has to worry about this, and therefore stagnates, meaning that, if somehow, he manages to lose tenure, he's completely out of luck in the market economy. Obviously this is a very broad generalization (because I know many people from academia who have moved to industry when they were stuck in their careers), but the idea stuck with me.
The same is the case for developers and managers. Each should always be growing, networking, interviewing, and keeping their resume fresh. A rolling stone gathers no moss. But, because Bill has been at Parts Unlimited for so long, or maybe because he lives in a geographical area with few alternative opportunities, or for whatever other reason, he's now stuck in this ulcer-inducing job, paying off a second mortgage he hates.
How many people live and work like this? Probably enough that the authors of Phoenix felt it was important to have a character that reflects reality in this way. But instead of writing a book pushing DevOps, why not talk about how people can become more antifragile and reduce stress at work, regardless of the operating environment there?
Just as importantly, why not talk about the increasing amount of debt Americans are forced to accumulate through systemic problems: flatlining wages, increasing student loan costs (I genuinely believe this problem will be strongly related to the next market bubble), rising healthcare costs, and economic agglomeration and regulation that forces Americans work in high-cost markets like San Francisco and New York, for diminishing returns?
(Good thread on this here, by the way: )
Why not discuss the growing FIRE movement? Or some of the efforts to work around the traditional education system? More importantly, why not discuss whether, in a theoretically DevOps environment, we need middle managers like Bill at all? (The book/essay Bullshit Jobs does just that).
The reason, as usual, is that digging around for root causes that are deeper than the root causes you’re focused on is hard. Humans are very much short-term view, small-picture animals, and looking at the larger picture is hard and inconvenient, particularly if you’re trying to sell a book about DevOps.
But you know what else is hard and inconvenient? Reading Phoenix Project. And being Bill.
Art: Bird Phoenix, Nina Tokhtaman Valetova 2011
What I’m reading lately:
I just finished How to Do Nothing and I didn’t like it …but maybe you will
What don’t people get about going to Russia is that it will most likely kill you.
Erik is on-target, as usual:
I’ve only read a little of this piece so far, but it’s beautiful
DAGster looks pretty cool
About the Author
I’m a data scientist in Philadelphia. Most of my free time is spent kid-wrangling, reading, and writing bad tweets. I also have longer opinions on things. Find out more here or follow me on Twitter. This newsletter, including warm takes about data, tech, and everything around those two. It goes out twice-ish a week. Paid subscribers get more warm takes and the warm feeling of supporting an author they LOVE (right?, right?).
If you like this newsletter, support it and get friends to subscribe!