Having read The Phoenix Project last year, our book club has chosen The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data for our next read. We’ve (Houston Miller, Jameson McGhee, and me) added a member to our club, Dennis Stepp, as he’s also reading this book.
This week we talked about the prologue and the first three chapters.
Prologue
- The book starts with the list of characters and their roles; it also mentions who overlaps from The Phoenix Project.
- This story takes place at the same time as The Phoenix Project, starting with the snafu of people’s payroll getting messed up through a technical glitch. (The non-audio versions of the book also have a timeline near the end to show the overlap.)
Chapter 1
- Chris throws Maxine under the bus for the payroll glitch; she calls him on it and he doesn’t deny it. This represents a lack of leadership to take fault as a team (i.e., extreme ownership). He should still have a 1:1 conversation with Maxine, though. Dennis said he would have quit on the spot if he were accused in this way. At that point, he couldn’t trust anyone.
- For fun, we looked back at The Phoenix Project to see if Maxine was named specifically for the problem. We did find a side comment where someone mentioned “Max” and probably thought it was a man.
- “Punishing failure and shooting the messenger only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.”
- Maxine was to blame, but Chris knew. Jameson wondered whether they tested anything, or whether this was a plot device to get Maxine kicked out.
- The development environment mentioned was “not a vibrant place where people work together to solve problems.” Each of us talked about environments we’ve worked in that seemed sterile.
- It’s amazing that contractor developers had tried to work locally for weeks and still couldn’t check in code. There’s little knowledge of who’s doing what.
- You need constant feedback from the tools to merge work.
- Where are all the experienced developers on this mission-critical project? They got moved to other projects.
- We all laughed at Maxine looking at documentation so limited that no scroll bar was required in the browser.
- Jameson wondered why Maxine was issued a new laptop when she already had one. Maybe this is a symptom of bureaucratic cruft — if new dev, then issue laptop.
Chapter 2
- Knowledge about Phoenix is spread everywhere — incomplete or rotting.
- The author goes through a considerable amount of character buildup (i.e., ethos) for Maxine. Geoff thought this was a bit much… “We get it. Maxine cured cancer and brokered peace in the Middle East. Move on, please!” You don’t have to know all the technical things to be successful. Jameson said, “A great CV does not a great person make.” Dennis wondered if the author was stirring the pot with the reference to functional programming being the best.
- Maxine tried to get things working locally on her machine — licenses, code, tools. Houston said having one centralized location for resources and docs would be useful. Dennis, Jameson, and I mentioned some examples of our experiences where the person that wrote the docs is long gone.
- The long list of things to do is an example of making work visible. Jameson was surprised she didn’t log all that in her time sheet.
- Imagine a 90-minute standup! Jameson said remote folks he’s worked with would do “meeting creep” by hijacking standing meetings because they knew people would be there to answer questions.
- Maxine puts in help tickets that keep changing hands and eventually are closed.
- Contrasting the two books… Maxine has reverence for Steve (CEO), whereas we knew angry asshole Steve from The Phoenix Project.
Chapter 3
- We enter this chapter with a high-profile status meeting for Phoenix. It’s shipping whether the team likes it or not.
- Regarding hiring new devs… “Good luck, chumps.” This gets her noticed by Kurt, who ultimately helps her get unstuck. (Chris told her to keep her head down, which she’s not doing.) This is another example of the Mythical Man Month — throwing more people at a late project does not make it go faster.
- Geoff rolled is eyes at the statement where Maxine says she can’t get the project to build on her machine “…and I’m really, really good at this!” Humility is a virtue. Jameson agreed that the character-building is over the top and doesn’t serve the story.
- Houston thought the reference to Dr. Seuss’s Oh the Places You Will Go was apt.
- This chapter has lots of compare/contrast — a Kickstarter project she funded with good feedback vs. the clunky ticket system at Parts Unlimited.
- Frustrated that her support ticket was closed because she didn’t fill out some section, she sought out the rep that closed it. Jameson said, yes he’s new to the process, but he could have helped her instead of doing the easier thing of closing the ticket and moving on to the next one. At least Maxine took the rep and her manager out for lunch.
- Being constantly around negative people makes you the same way.
- To do big things that scale you need a rigorous process.
- It was preposterous that she asked for a VM to do work and it was going to take 5-7 months. It’s also shocking how many hands have to be involved to get a developer image ready.
- Fast feedback for developers is critical. A healthy system is one you can change at the speed you need.
Other
- Jameson thought it frustrating that this book is written in third person, despite the protagonist being one person. (The Phoenix Project, by the same author, is written in first person.)