February 14, 2020

The Unicorn Project – Part 4

This week our book club talked about chapters 10-12.

Chapter 10

  • The analogy to having multiple Hollywood screenwriters trying to smash all of their scripts together at the last minute with very little coordination seemed implausible to Geoff. However, Jameson and Dennis have worked in environments where people are doing their own things with very little coordination until it all blows up at the end.
  • If it hurts, do it more. You need to realize what’s causing the problem. The environment at Parts Unlimited consists mostly of juniors that has little experience coming together to build something.
  • The shift to a blameless culture is important.
  • People need to be empowered to do their jobs instead of being distrusted.
  • The developers are not trusted to push code; however, you do need gates because human error is a thing. Automated CI/CD pipelines will help. You need to also trust that the tools that surround that pipeline. Having only one sign-off is fast, but it’s also riskier.
  • The person deploying the code needs to understand the work. We talked about the issue of having a dedicated ops person on the team, where much of their time may be idle waiting for the button to be pressed. The typical response is to spread that person’s workload over multiple teams, which leads them stretched. It’s especially problematic in the book because nothing is standardized.
  • Many of us work in environments where so long as the approvers (e.g., not the dev that wrote it, one tester) agree, the deployment advances to the next stage.

Chapter 11

  • There’s a tangle of policies in place to prevent bad things from happening. More rules will slow things down.
  • Development tech (still in 2020!) is fractured, where there are too many things to keep up with. Abstraction gets you to go faster (where you don’t have to understand how the electrical system works, just plug in your appliance), however when things break, you don’t have the fundamentals to help you troubleshoot. Working from first principles is great, but it could take years to truly understand things, and by then things have moved on.
  • Although not specifically called out, the requirements were described as “long on the what and how, but not the why”. This is where user stories come in.
  • It takes two months to create a pricing bundle in Phoenix — this is the lead time from “Making Work Visible.”
  • Security is a bottleneck, a common trope in technology/IT.
  • We all agreed that having an Architecture Review Board (or whatever you want to call it) is important as systems become more complex. It needs to be managed well so you don’t get mired in bureaucracy. Jameson suggested to time-box decisions and to task the ARB with explaining why you shouldn’t proceed with a given solution.
  • Geoff called out the statement in the book that the ARB is “frozen in time, still acting like it’s the 1990s.” These people should stay technically sharp and be given adequate time from management to keep their fingers on the pulse of technology.
  • Dennis called out that developers were in charge of making product SKUs. Why isn’t a product or marketing team doing this?
  • We talked about how the Rebellion is taking DataHub out of the normal cycle, allowing them to bypass the bottlenecks, mainly security. This is concerning. Yes, you can move faster, but security and compliance are still important.
  • What if DataHub succeeds by proving it can work without the clunky machinery? Management may say, “Thanks, but you broke the rules — you’re fired.” The operation may fail in which case the company is done for anyway. We also talked about how clueless management is that any of this is going on. What are they doing? Likely busy in meetings covering for themselves or pointing the finger at others.
  • The group had some disagreement about how each of us would have responded to the “let’s move office furniture without asking for help.” Yes, it’s not worth asking when it’s faster to do it yourself, especially as they paid for the new furniture themselves. However, if they get injured doing that, the company is liable. Rules exist for a reason.

Chapter 12

  • Deployment is the constraint.
  • API designs and documentation lack discipline. Nobody wants to do it, but everybody complains when it’s not done.
  • The concept of meeting with the customer to get a clear idea of the needs is pivotal.
  • Geoff disagreed with the concept that engineers should be focused on writing code. He’s mentioned his liberal arts background and track record of spanning multiple groups to work on interdisciplinary work. Jameson shared a counter-story about how he saw two interacting groups about to interfere with one another, so he called a meeting. Afterward he was chided for stepping outside his role. Company culture matters here.
  • There was a statement in the book about some other technical team that knows Docker and thinks it should be used at Parts Unlimited. Yet another person that works outside of work to invest in their own career. You shouldn’t have to do this, and there are those of us that don’t want to.
  • The way Parts Unlimited has implemented their review board (TEP-LARB) is too slow; they meet twice a year and have a lengthy application to complete before they even talk to you.
  • We discover that Product Management is a blocker because the features are unclear. You need product people working directly with the teams, in this case, physically. Aim for low friction and fast feedback.