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.
tl;dr:“Some governmental agencies have started to adopt No Wrong Door policies, which aim to provide help – often health or mental health services – to individuals even if they show up to the wrong agency to request help. The core insight is that the employees at those agencies are far better equipped to navigate their own bureaucracies than an individual who knows nothing about the bureaucracy’s internal function.” Will discusses how engineering orgs can implement similar policies.
tl;dr:“A complete engineering strategy has five components: explore, diagnose, refine, policy, and operation. However, it’s actually quite challenging to read a strategy document written that way. That’s an effective sequence for creating a strategy, but it’s a challenging sequence for those trying to quickly read and apply a strategy without necessarily wanting to understand the complete thinking behind each decision.” Will covers: (1) Why the order for writing strategy is hard to reading strategy. (2) How to organize a strategy document for reading. (3) How to refactor and merge components for improved readability. (4) Additional tips for effective strategy documents.
tl;dr:“That context makes LLM adoption a great topic for a strategy case study. This document is an engineering strategy document determining how a hypothetical company, Theoretical Ride Sharing, could adopt LLMs.”
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:"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:“I’ve been working fairly directly on meaningful applicability of LLMs to existing products for the last year, and wanted to type up some semi-disorganized notes. These notes are in no particular order, with an intended audience of industry folks building products.” Will discusses opportunities re-configuration, combining LLMs with unsophisticated algorithms to retrieve data. And more.