Lesson 7 gave you the kernel: diagnosis, guiding policy, coherent actions. This lesson is Larson’s version of the same three parts, built for engineering specifically, plus the move for the case where the company strategy engineering is supposed to derive from does not exist either.
Diagnosis is unchanged from lesson 7: name what is actually breaking, not what you want to build. Larson’s contribution is in the next step. Rather than leaving guiding policies open-ended, he has you answer three questions, each with a why attached.
What is engineering’s resource allocation against its priorities, and why? Competing internally for budget and headcount rewards empire building over effectiveness, and quietly starves priorities nobody is advocating for, security and developer productivity being the usual victims. Stating the ratio and the reasoning removes the competition.
What are the fundamental rules every team must follow, and why do they matter? A rule like “all backend services use Go” only works enforced across the whole organization, because that is the only place the tooling, security and compliance trade-offs can be made once for everyone. State the reason or the rule reads as arbitrary.
How are decisions made within engineering, and why do we work this way? Teams need to know what they can decide themselves, what they should optimize for, and how to escalate what they can’t. The why matters here too: every way of making decisions trades something off, and that trade-off is invisible to whoever is currently frustrated by the process.
If your diagnosis doesn’t support clear answers to these three, the problem is usually the diagnosis, not the questions. It’s missing the altitude an executive is uniquely positioned to bring.
A guiding policy can be pitched too high to do any work, or scoped so narrow it micromanages a single team’s roadmap. Larson’s test for whether a policy is sitting at the right altitude:
| Criterion | What it means |
|---|---|
| Applicable | It can be used on a real, complex trade-off. If you can’t apply it, scrap it. |
| Enforced | Teams are actually held accountable for following it, exceptions included. |
| Creates leverage | It produces compounding or multiplicative impact, not just consistency for its own sake. |
Google’s historical four-language limit (Python, C++, Go, Java), enforced rigorously, is Larson’s example of a policy passing all three: applicable to every new project, enforced without much exception, and leverage-creating because each project inside the limit compounds the value of shared tooling. Uber’s “let builders build” from the scenario passes applicable and arguably enforced, by absence of a counter-policy, but the leverage argument runs the other way: individual gains, not organization-wide compounding.
A policy failing one criterion but still necessary to address the diagnosis is fine. Several failing at once is the signal to rework the diagnosis or the policy itself.
Engineering’s diagnosis needs to know the business and product strategy it’s responding to, and most companies never wrote those down either. The overachieving move here, running a company-wide strategy documentation effort first, can cost months or years you don’t have.
The faster path: talk to the executives responsible for the one or two most relevant strategies, usually business and product, until you can write a short private draft of each. Confirm accuracy with that executive, then keep the draft private. It is input to your diagnosis, not a document to publish, and sharing it more widely tends to read as undermining a peer rather than helping them.
Every organization already has a strategy, in the sense of however it currently handles its problems. It’s usually unwritten, and often not a good one, but “we have no strategy” is rarely true. Larson’s test for whether it’s time to write yours down is three questions: are you confident in the diagnosis, or do you trust the wider organization to help you get there? Are you willing and able to enforce what you write? Are you confident it will create leverage worth the cost of asking an entire organization to change how it behaves? A yes to all three means write it now, not next quarter.
The payoff for writing it down doesn’t depend on anything changing. A documented diagnosis can be evaluated and revisited when circumstances change. A late joiner can read it and understand how the organization got here instead of reconstructing their own guess. And once it exists, disagreements have something to point at, rather than each side citing its own private version of the strategy, the exact failure the previous lesson’s four-pillar scenario ran into.
The next lesson takes the same kernel into a narrower question: what people actually mean when they ask a CTO for a technology strategy, and why the honest answer is rarely a list of technologies.
Source: Will Larson, The Engineering Executive's Primer, Ch. 3 'Writing Your Engineering Strategy'
Answer to reveal the explanation. Nothing is scored.
1Larson says guiding policies should answer three questions. Which of these is NOT one of them?
The three are resource allocation, fundamental rules, and decision rights, each with a why attached. A revenue forecast belongs in the diagnosis as an input, not as a guiding policy: it is a fact about the world, not a choice about how engineering will respond to it.
2What is the altitude test for a guiding policy?
A policy pitched too high passes none of the three: nobody can apply it to a real trade-off, nobody enforces it, and it multiplies nothing. Larson's fix is to scrap a policy that fails all three rather than keep it for the appearance of having a strategy.
3The company has no documented business or product strategy. What does Larson recommend?
Trying to fix the company's strategy culture first can add months or years. The faster path is modeling good strategy inside engineering: draft the business and product strategies privately from conversations with those executives, confirm accuracy with them, and use the draft only to inform your own diagnosis.
4Why does Larson push executives to write the strategy down even if nothing about the organization's approach is changing?
Every organization already has a strategy, in the sense of however it currently handles its problems. It is usually just undocumented, and often not a particularly good one. Writing it down is what makes it something you can evaluate, defend, or update, rather than something everyone quietly reconstructs their own version of.