tl;dr:Will discusses: (1) The various ways that are frequently suggested for evaluating strategies, such as input-only evaluation, output-only evaluation, and so on. (2) A rubric for evaluating strategies, and why a useful rubric has to recognize that strategies have to be evaluated in phases rather than as a unified construct. (3) Why ending a strategy is often a sign of a good strategist, and sometimes the natural reaction to a new phase in a strategy, rather than a judgment on prior phases. And more.
tl;dr:“I refer to the art of making policies work as “operations” or “strategy operations.” The good news is that effectively operating a policy is two-thirds avoiding common practices that simply don’t work. The other one-third takes some practice, but can be practiced in any engineering role: there’s no need to wait until you’re an executive to start building mastery. This chapter will dig into those mechanisms.”
tl;dr:Will notes how LLMs can’t meaningfully replace many essential roles of software professionals. However, he also understands how decision-makers can remain irrational longer than you can remain solvent in the context of rapidly improving technology. He shares his thoughts here.
tl;dr:Will notes how LLMs can’t meaningfully replace many essential roles of software professionals. However, he also understands how decision-makers can remain irrational longer than you can remain solvent in the context of rapidly improving technology. He shares his thoughts here.
tl;dr:Will explores setting policy as a critical step in engineering strategy, following exploration, diagnosis, and refinement. It defines policy as turning diagnosis into actionable decisions, covering coding practices, hiring mandates, and architectural choices. The chapter outlines structured steps for policy creation, types of policies, and criteria for effective policies. It also discusses handling uncertainty, recognizing constraints, and addressing missing strategies.
tl;dr:“If you talk to enough aspiring leaders, you’ll become familiar with the prevalent idea that they need to be promoted before they can work on strategy. It’s a truism, but I’ve also found this idea perfectly wrong: you can work on strategy from anywhere in an organization, it just requires different tactics to do so.”
tl;dr:Will covers: (1) Why diagnosis is the foundation of effective strategy. Conversely, how skipping the diagnosis phase consistently ruins strategies. (2) A step-by-step approach to diagnosing your strategy’s circumstances. (3) How to incorporate data into your diagnosis effectively. (4) Dealing with controversial elements of your diagnosis. (5) Why it’s more effective to view difficulties as part of the problem to be solved, rather than a blocking issue. (6) The near impossibility of an effective diagnosis if you don’t bring humility and self-awareness to the process.
tl;dr:Will covers: (1) The goals of the exploration phase of strategy creation. (2) When to explore and when it makes sense to stop exploring. (3) How to explore a topic, including discussion of the most common mechanisms: mining for internal precedent, reading industry papers and books, and leveraging your external network. (4) Why avoiding judgment is an essential part of exploration.
tl;dr:“This chapter starts by exploring something I believe quite strongly: there’s always an engineering strategy, even if there’s nothing written down. From there, we’ll discuss why strategy, especially written strategy, is such a valuable opportunity for organizations that take it seriously.”
tl;dr:“Like almost all startups, the engineering team was scattered when I joined. Was our most important work creating more scalable infrastructure? Was our greatest risk the failure to adopt leading programming languages? How did we rescue the stuck service decomposition initiative? This strategy is where the engineering team and I aligned after numerous rounds of iteration, debate, and inevitably some disagreement. As a strategy, it’s both basic and also unambiguous about what we valued, and I believe it’s a reasonably good starting point for any low scalability-complexity consumer product.”