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.
tl;dr:“It remains the most common category of reasoning error that I see stressed executives make. If you’re not sure how to make progress, then emotionally it feels a lot better to substitute motion for lack of progress, but in practice you’re worse off.” Will highlights this with examples.
tl;dr:Will discusses the scenarios when taking risks make the most sense as a leader. “Taking direct, personal risk is a prerequisite to taking ownership of interesting problems that matter to your company. A risk-free existence isn’t a leadership role, regardless of whatever your title might be. Indeed, an uncomfortable belief of mine is that leadership is predicated on risk. The upside is that almost all meaningful personal and career growth is hidden behind the risk-taking door. There’s a lot of interesting lessons to learn out there, and while you can learn a lot from others, some of them you have to learn yourself.”
tl;dr:Tradeoff decisions often result in disappointment e.g. you can’t deploy software quickly and test it thoroughly, you have to sacrifice usability due to safety features. Will believes the key is to introduce a new dimension to the decision making process. His approach: (1) Believe and socialize that there is a new dimension to discover. (2) Get specific on stakeholder requirements. (3) Seeing dimensions is the same as seeing layers of context. Expand your contextual awareness or pull in a team with knowledge. (4) Test new dimensions for usefulness quickly. Don’t go too deep. (5) Ask those who’ve solved similar tradeoffs. (6) Only add a dimension if it provides significantly better outcomes.
tl;dr:Will hypothesizes, if we had five free hours each week, how would he spend them? He sees four valid options to build his career, as follows: (1) Write code or engage in detailed work within the engineering org. (2) Build broader context: expand your context outside the engineering org. Understand your peers work, goals and obstacles e.g. talk with customers. (3) Improve current systems: Work on your strategy or planning process. (4) Build relationships: Expand your internal or industry networks.
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 here.
tl;dr:Will had to solve a common problem — how to make technical decision within a large organization of over 400 engineers. He established Navigators, individuals accountable for these decisions in their area of expertise who report directly to the CTO. (1) Each major area of the business has one Navigator, who is an active contributor to the software written. (2) There is exactly one Navigator for a given area; Navigators do not overlap. (3) Each Navigator is accountable for the technical decisions made in their area. This includes interpreting organizational strategy and applying it to their context. Will elaborates on the roll here.
tl;dr:It’s easy to lean too heavily on benchmarks by believing that they answer questions: they don’t really do that. Benchmarks only ask questions, they never answer them. It’s up to whoever is using the benchmarks to extract the questions and do your own work to answer them. If you look at “R&D costs as a percentage of revenue” across companies, you’ll notice that some are four or five times higher than others. Are the high spenders early in making a calculated bet into releasing a new service, or are they just inefficient? Either, or both, could be true, and that’s the sort of interesting question-answer pair to work through when using benchmarks to evaluate.