tl;dr:“Modeling makes it possible iterate your thinking much faster than running a live process or technology experiment with your team. I sometimes hear concerns that modeling slows things down, but this is just an issue of familiarity. The more you practice, modeling can be faster than asking for advice from industry peers.”
tl;dr:A model examining how different policies affect engineering organization seniority mix. Without intervention, orgs become top-heavy with senior engineers, increasing costs. Three key policies work together: backfilling departures at lower levels, stopping senior-level external hiring, and capping the maximum number of senior positions.
tl;dr:Will reflect on his shift from a 'company, team, self' framework to an eventual ‘quid pro quo' approach during his management tenure at Uber. His ‘quid pro quo' approach is: (1) Generally, prioritize company and team priorities over your own. (2) If you are getting de-energized, artificially prioritize some energizing work. Increase the quantity until equilibrium is restored. (3) If the long-term balance between energy and proper priorities can’t be balanced for more than a year, stop everything else and work on solving this issue e.g. change your role or quit. Will emphasizes the importance of remaining flexible and curious.
tl;dr:Will reflect on his shift from a 'company, team, self' framework to an eventual ‘quid pro quo' approach during his management tenure at Uber. His ‘quid pro quo' approach is: (1) Generally, prioritize company and team priorities over your own. (2) If you are getting de-energized, artificially prioritize some energizing work. Increase the quantity until equilibrium is restored. (3) If the long-term balance between energy and proper priorities can’t be balanced for more than a year, stop everything else and work on solving this issue e.g. change your role or quit. Will emphasizes the importance of remaining flexible and curious.
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.