April 23, 2020

An Elegant Puzzle – Part 7

This week we discussed sections 4.1 through 4.3.

4.1 — Work the policy, not the exceptions

  • You reconcile consistency and change by working the policy, not the exceptions.
  • Consistency is important, but if people don’t ask for change, then how do know how to try knew things?
  • Make a better policy instead of making exceptions. For example, make it explicit about who goes to professional conferences and who pays for them.
  • The author recommended writing norms in addition to policies which serve as lighter-weight guidelines. It would have been useful to see an example.
  • Introverted people may not speak up and ask for things.
  • Is there a time where exceptions are okay? There will always be exceptions; use those events as a trigger to revisit policies.
  • Geoff liked the author’s statement that applying policy consistently is locally suboptimal. The goal is broader and may not benefit some teams. An example could be having a mobile device management policy where employees have a work device (instead of BYOD) that’s not ideal for each employee; however, it simplifies some security stances for the company.
  • The policies should be applied consistently. Don’t make one person follow it and ask another to break it.
  • This section is more about “Why does so-and-so get to do X?”
  • Conway’s Law essentially says that the systems you build emulate the org’s communication structure or culture. If you have someone who doesn’t follow the rules (e.g., someone who doesn’t have to follow code check-in rules), they probably won’t follow other rules either.
  • “At a sufficiently high rate of change, policy is indistinguishable from exception.” You need to explain when policies will be revisited.
  • Houston asked how one would document the exceptions to the policy. Geoff talked about how his previous company (DPRA) did this via CMMI process. Every process or policy has an owner. That owner is tasked to revisit the item annually, making changes as needed.

4.2 — Saying no

  • Dennis found the introduction of this section interesting (where the author had to insist that the CTO not fire someone who didn’t respond to an incident). This is why you need blameless post-mortems. Why fire the person who’s in the best position to fix the issue? Blame the system, not the person. This is probably also a symptom of not having a culture that tolerates failure.
  • Houston asked whether anyone had worked in a culture that tolerated failure? Dennis shared a story where he made a mistake, and the response was, “How can we prevent this from happening again?” Jameson added that it’s essential to trust everyone in the room; no repercussions or scolding. The product owner is supposed to “assuage the rage” when a developer makes a mistake.
  • The author mentions two concepts: velocity (why is this thing taking longer) and prioritization (why can’t you work on this other thing). Geoff loved the idea of having teams “provide a compelling explanation of how your team finishes work”, as opposed to how they do work.
  • Jamie shared an analogy to Eminem’s rap battle in “8 Mile” where he talks negatively about himself so others had no reason to diss him. You need to not care about blame personally.
  • We had a lengthy discussion about whether individual names should be discussed in post-mortems. “Bob pushed the big red button.” Jamie argued that we shouldn’t leave Bob out (e.g., “The big red button was pushed”); you need to know exactly what happened. Maybe there was a training gap. Maybe the process is broken. Maybe Bob is under stress from other issues outside work. You can’t get to the root by hiding information.
  • Is it blameless if you’re afraid to mention names? The root problem is culture if the blamed person gets reprimanded unnecessarily.
  • If you don’t bring up problems, how will you get them fixed?
  • How do you manage dependencies? Do you always prioritize work that other teams depend on or your own stuff? The teams need to communicate. Escalate to product management if nothing else works.

4.3 — Your philosophy of management

  • Jamie said this philosophy resonated with him: “Lead from the front, and never ask anyone to do something you wouldn’t.” For example, the boss better work on the weekend if the employee is asked to work on the weekend.
  • Geoff and Jameson mentioned the Platinum Rule instead of the Golden Rule: Treat others how they want to be treated.
  • If you change the group of people, you may need to change the process, too.
  • Geoff liked the ethical approach where you as a manager “leave a broad wake, and that your actions have a profound impact on those around you.”
  • It’s rare for people to be introspective and wonder whether they are the problem.
  • Geoff was all-in on the people over process concept. “If your process is failing somehow, it’s worth really digging into how it’s failing before you start looking for another process to replace it.”
  • Do the hard thing now; double-down on the difficult things. Jamie has applied this to his career where he tackles the hard things so they eventually become easier.
  • Cutting your losses can be difficult; the sunk cost fallacy is a thing.
  • We all agreed that “your company, your team, yourself” isn’t the right order. Maybe if it’s beneficial to all three, then do it. If it helps you, but harms the team or company, that’s not great either. You need to put yourself first sometimes. The company may not have your individual best interest at heart. Jamie’s motto is to do right by your team first; he’s stated that he’s willing to take the bullet for his team.
  • Geoff commented about “Think for Yourself” that the manager’s toolbox is filled with many things, some of which will be useful, others may not work for your style.
  • It’s difficult to be loyal to the company. If you doubled the revenue on your project, they won’t double your salary. We live in a society where the employer and employee need one another until they don’t. It used to be that you’d work for a company for life.