This week our book club talked about chapters 4 through 6.
Chapter 4
- The Phoenix Project is launching anyway despite no one having confidence in any shape or form. There’s a serious lack of communication about how this should work, combined with a false sense of security because every other launch event has been delayed. You should release as often as possible to become accustomed to it. If you can’t build, how can you deploy?
- The team doesn’t even understand what they need (e.g., servers, capacity) to actually run Phoenix. How do you not know? The characters even talk about “handfuls” of servers, and joking about whether those are metric handfuls.
- Bill’s attitude is crucial during this time of crisis: “Wes, what help do you need?” He doesn’t berate people; he seeks to understand why they can’t meet the deadline.
- “Production deployments are some of the most complex activities of any tech org.” You need people (or at least representatives) that are impacted by deployments in the different teams so that no one is surprised.
- The executives (who have a business, not tech background) are too distant from the work. There’s little bottom-up communication. They don’t want to hear bad news, which fuels the fear of failure mindset. The bridge crew needs to set the strategy and ensure people can get their work done. Jameson mentioned a previous company communicating “the critical few”, meaning that everyone knew what the quarter’s focus was. No one should be surprised about what we’re working on and why.
- Geoff asked how such a large project could have zero technical oversight (e.g., needing three operating systems, multiple programming languages). Jameson suspects that the managers that ask senior devs to get work done don’t understand tech, so those devs solve problems the way they know how instead of cross-communicating when deciding tools.
Chapter 5
- Breaking the rules is the only way to get anything done.
- We see that the “Rebellion” group is building a shadow IT department by hoarding servers.
- The members of this group are cross-functional — devs, ops, QA, and later a project manager.
- Everything is stuck in committees and bureaucracy. People are not empowered to fix their own problems, which leads to morale and productivity issues.
- Technical debt is inevitable as what you develop from cycle to cycle can’t get predicted. There are ways to address this as you go, such as spending an entire sprint on tech debt, or allocating a percentage of each sprint/release to it.
- QA is not designed to protect the org from the developers.
- There’s an argument made that you shouldn’t automate testing because then you won’t get as much money to hire more testers. Automation isn’t taking away those QA jobs: The QA engineers are now writing those automated tests.
- How far can this group work around the rules before getting fired? Does it matter considering this project is do-or-die for the company anyway? With this kind of environment at Parts Unlimited, would it be a loss to be fired?
Chapter 6
- The deployment process is full of “hurry up and wait.” 200+ people are needed, most of them only having five minutes of real work to do. Automation would help solve this. There’s also likely a distrust of tech because it’s yet to be proven, but they trust people which is why they hired so many.
- We all were shocked about the 8000 SQL queries that run from a single drop-down selection. It’s likely not designed this poorly on purpose, but designed in a fragmented way where the left hand didn’t know what the right hand was doing.
- Each problem they have is different every time they try to do something.
- As the roll-out progresses, other tech systems in the company start to wobble. There’s no communication channel to get information moving (e.g., Slack channel). The situation is fraught with a lack of communication and when communication does happen, it’s sometimes misunderstood.
- Toward the end of the chapter, we see more emails about people being fired because of how poorly the launch is going. This behavior is typical in a blame-based culture; the author rightly calls it a “witch hunt.”
- Houston mentioned another systemic failure: Savings now does not translate to savings later.