tl;dr:“Models are imperfect representations of reality, but this one gives us a clear sense of what matters the most: if we want to increase our velocity, we have to reduce the rate that we discover errors in production. That might be reducing the error rate as implied in this model, or it might be ideas that exist outside of this model. For example, the model doesn’t represent this well, but perhaps we’d be better off iterating more on fewer things to avoid this scenario. If we make multiple changes to one area, it still just represents one implemented feature, not many implement features, and the overall error rate wouldn’t increase.”
tl;dr:“If I could only popularize one idea about technical strategy, it would be that prematurely applying pressure to a strategy’s rollout prevents evaluating whether the strategy is effective. Pressure changes behavior in profound ways, and many of those changes are intended to make you believe your strategy is working while minimizing change to the status quo (if you’re an executive) or get your strategy repealed (if you’re not an executive). Neither is particular helpful.”
tl;dr:“Even as popular sentiment has generally turned away from microservices, many engineering organizations have a bit of both, often the reminents of one or more earlier but incomplete migration efforts. This strategy looks at a theoretical organization stuck with a bit of both approaches, let’s call it Theoretical Compliance Company, which is looking to determine its path forward.”
tl;dr:Will covers: (1) When to write strategy, in particular the pain points (like cross-team friction) and opportunities (like senior hires) that are good moments to start writing. (2) How much strategy your org can tolerate, avoiding the traps of writing so much that it’s ignored or so little that there’s not much impact. (3) Using strategy altitude – how permissive a given strategy is and where it’s implemented – to manage the overhead that strategies creates. (4) Mechanisms to debug whether you’re doing too much or too little strategy work.
tl;dr:“Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach.
tl;dr:“Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach.
tl;dr:“Some particularly useful mechanism for senior leaders to develop domain expertise are:” (1) Reviewing product analytics on a recurring basis. (2) Shadow customer support. (3) Assign named executive sponsors for key customers. (4) Directly use or integrate with the product. (5) Make an executive offsite ritual around using the product. (6) Use executive initiatives as an opportunity to dig deep into particular areas of the business. (7) Use a textbook or course driven approach.
tl;dr:In 2019, parts of Stripe’s engineering org were going through a civil war, driven by one group’s belief that Java should replace Ruby to deliver a quality platform. The other group believed Stripe’s problems were driven by a product domain with high essential complexity. Switching languages wouldn’t address any of those issues. Will discusses his approach to solving this conflict: “what I have found useful is studying what each faction knows that the other doesn’t, and trying to understand those gaps deeply enough to find a solution. Sometimes I summarize this as solving for both physics and perception.”
tl;dr:“This observation is the underpinning of my beliefs about creating software quality. Expanding from that observation, I’ll try to convince you of two things”: (1) Creating quality is context specific. There are different techniques for solving essential domain complexity, scaling complexity, and accidental complexity. (2) Quality is created both within the development loop and across iterations of the development loop.
tl;dr:“Anytime you apply a rule too universally, it turns into an anti-pattern.” The key to effective engineering leadership, Larson argues, lies in figuring out which scenarios are worth deliberately defying conventional logic, and when to simply follow the rules. “ Will discusses his tonics for the following anti-patterns: (1) Shying away from micromanagement. (2) Pushing back on flawed metrics. (3) Serving as the umbrella for your team.