tl;dr:Will discusses: (1) An example of an engineering strategy. (2) Richard Rumelt’s definition of strategy: diagnosis, guiding policies, and coherent actions. (3) How and when to write your engineering strategy. (4) Dealing with undocumented strategies in other functions. (5) Structuring your guiding policies around resource allocation, fundamental rules, how decision are made. (6) Maintaining the right altitude in your strategy by ensuring guiding principles are applicable, enforced, and create leverage. (7) The most common kinds of coherent actions in engineering strategies. (8) Whether strategy should be executive-lead.
tl;dr:Will discusses the following questions and the values he's found most effective: "What kinds of problems do values solve? Should engineering orgs have values at all? When does it make sense to establish values out? What makes values useful? How are engineering values distinct from a technology strategy? How should you roll out values?"
tl;dr:"I’d like to recommend 6 core meetings that I recommend every organization start with, and that I’ve found can go a surprisingly long way. These six are split across three operational meetings, two developmental meetings and finally a monthly engineering Q&A to learn what the organization is really thinking about." Will discusses each in depth.
tl;dr:"There is no one solution to engineering measurement, rather there are many modes of engineering measurement, each of which is appropriate for a given scenario. Becoming an effective engineering executive is adding more approaches to your toolkit and remaining flexible about which to deploy for any given request." Will provides a template to work off of.
tl;dr:Will discusses his experiences managing and energizing teams. "Rigid adherence to any prioritization model, even one that’s conceptually correct like mine that prioritized the company and team first, will often lead to the right list of priorities but a team that’s got too little energy to make forward progress. It’s not only reasonable to violate correct priorities to energize yourself and your team, modestly violating priorities to energize your team enroute to a broader goal is an open leadership secret."
tl;dr:Will discusses the concept of a type of work called "reminiscing": when under pressure, most people retreat to their area of highest perceived historical impact, even if it isn’t relevant to today’s problems. "When you see your capable CEO start to micromanage words in a launch email, or your talented CTO start to give style feedback in code reviews, take it for what it’s worth: they’re reminiscing. If you dig deeper, they’re almost certainly panicking about something entirely unrelated."
tl;dr:"A few long-tenured engineers, who happen to have the explicit access credentials to all key systems and implicit permission to use them, help respond to almost all incidents. These folks become increasingly load bearing, as few others acquire the knowledge, and access credentials, to respond when they’re not available. Fast forward to the future, and one of these key responders leaves the companies, which creates more load on the remaining responders." Will discusses how to solve this.
tl;dr:"Often when an organization is going through some turmoil, executives think to themselves, “Ah, I should have some one-on-ones with the team so they can hear how we’re handling this.” Will advises those asked to have a 1-1 with execs: (1) If you’re not sure what’s happening, let the exec take the lead. (2) Try to figure out why the meeting is happening before you’re in the meeting. (3) Know that the executive will very likely have an agenda, but sometimes have no agenda at all, in which case it’s very helpful to have prepared ahead of time. And more.
tl;dr:The quick exercise is designed to better understand your engineering organization from various perspectives. Will explains how to draw a locator map (where are you?), a topographical map (how hard is it to go nearby places?), and a treasure map (where are the places that are really worth going?)," designed to show opportunities to improve your processes. Will also shares what he leant from the exercise.
tl;dr:Will discusses pros and cons of each. His "default advice" on the topic of increasing quality of organizational hiring is: (1) Introduce structured approval when you introduce your second hiring manager in a function. (2) Wait until organization trust grows sufficiently weak that there’s significant skepticism about hiring quality across teams, then introduce a hiring committee. (3) Avoid introducing bar raising unless you have a clear thesis on why the other approaches won’t work out.