The book The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win has become one of the must-read books in the IT/software arena. It’s been on my reading list for over a year, so a few of my colleagues (Houston Miller and Jameson McGhee) and I formed an impromptu book club to read and discuss the book.
We’re covering five chapters a week, and then meeting up for lunch and discussion. Among the three of us, we’ve worked for a variety of companies (sizes, business spaces, lengths of time, departments) so it’s been interesting to compare notes and see trends. I’m turning the notes I jot down during our meetings into blog posts.
Here are my notes for chapters 1-5…
This business fable is very much like The Goal by Eliyahu Goldratt. (I believe The Phoenix Project was inspired by it.) Despite being in narrative form, it’s closer to truth than we’d maybe like to believe.
An aspect that was glossed over is how the protagonist (Bill) got his promotion to VP. He didn’t see it coming and initially didn’t want the job. He worked on a smaller project and got his work done. This isn’t an example of the Peter Principle — i.e., Bill is good at his current job so let’s promote him into a fundamentally different job.
There’s a comment about CIOs coming in, shaking things up by introducing changes, and then leaving. This reminded me of seagull management: “Seagull managers fly in, make a lot of noise, dump on everyone, then fly out.”
It was an interesting aside about how people leave the company… If that person tells you, they quit. If you find out from others, they were fired.
Given I work for a company where several in the leadership ranks were career military, I perked up when several of the execs in the book are also former military. There’s a certain amount of politicking, loyalty, earned rank, giving and disseminating orders, and decisiveness. Those have pros and cons, some of which don’t translate to private industry well.
Characteristics people want in you — dependable, pragmatic, sharing what you think — sound good on paper but often aren’t real because in a crisis, those go out the window. We came up with the notion “I want you to tell me what you’re thinking… as long as it’s what I’m already thinking.”
After Bill’s promotion, he’s learning about entirely different parts of the company and different projects that are also in IT. Jameson has experienced this; sometimes there are teams working on very similar areas that know nothing about each other’s work.
Fundamentally these are not tech problems: They are about communication, people, siloed information, and how humans behave when they’re afraid. Fear is a key driver in all of this… Will this system break? Will the union file a lawsuit? Will I not meet my quarterly goals and get that big bonus? Will I not get a promotion?
It makes for a good narrative in the book, but there are real-world examples of multiple large crises happening concurrently. Certainly it can’t get any worse than thi… Wait, another one?!
Once Bill is given a focus (e.g., find out why hourly workers show zero hours logged last week and payroll runs 4 hours from now), he has to get the same information from multiple teams fighting the issue. People aren’t getting the information when they need it; lots of wasted time sharing/absorbing.
We see several examples of pendulum swings — cowboy culture vs. process for everything. Most of my career has been in regulated environments, so I’ve seen varying degrees of this as well. Neither extreme is effective.
Each of us was looking for characters in the book that represent us, and we were trying to figure out who the real versions of some of the other players were from our work experiences.
There are plenty of examples of items in the Steven Covey urgency/importance matrix that come into play. They meant to get around to patching that server or setting up a test environment, but other things got priority… and now that server has priority because it won’t boot. Although I haven’t read it, this sounds like The Tyranny of the Urgent, where “there is a regular tension between things that are urgent and things that are important—and far too often, the urgent wins.”
Security is often at odds with the other project stakeholders. If security’s mindset is that every vulnerability is a showstopper, nothing will get done.
I enjoyed how Bill’s mindset is to fix problems instead of finding who to blame.
One of the lead developers (Brent) is 100% utilized. This is covered in The Goal as well (formally called “theory of constraints”) where it’s impractical to run the bottleneck of your system at 100%. There must be slack.
There are some comments from other characters about there being process but nobody uses it or that there are tools that no one uses. This is the inverse of the Agile Principle of “people over process.”
Houston commented that the laundry list of Sarbanes Oxley audit findings at least provided some expectations of what needed fixing. This is a tick in the “plus column” for compliance systems such as SoX, HIPAA, PCI and the like.
You can’t hire a crew of firefighters (devs, testers, etc.) and expect them to stay at your company for long. They’ll burn out.
We all nodded in agreement about the concept of having worked at places where there was no formal list of things that need attention — it’s all tribal (in people’s heads) or in separate systems that don’t talk to one another.
Sure, hire smart people; but if you don’t give them guidance of a set of expectations, they’ll be rudderless.