Engineering leadership · Book notes
Your org has a strategy. Crafting Engineering Strategy says write it
Will Larson argues most engineering organizations don't lack strategy, they lack written strategy.
Every large engineering organization already has a strategy implicit in the projects they fund and exceptions they approve. It’s just usually held by a few senior people and leaves with them. So I’m not saying orgs don’t have strategy, I’m saying they don’t have a written strategy. In 2026, the absence of that document is where a lot of AI and cloud spend goes unmanaged.
Will Larson’s book Crafting Engineering Strategy (O’Reilly, October 2025) defines strategy as “the art of reproducibly making good decisions.” If you don’t take anything else away from this book, you should at least start documenting the decisions you’re already making in terms of diagnosis, policy, and enforcing operations. I’m looking at this from the perspective of working with large financial institutions and Fortune 500 companies over the last ten years, now as a principal cloud architect.
Larson breaks this down into five steps: explore the problem and options, diagnose the real situation honestly, refine the approach using tools like systems models and Wardley maps, set policy, and execute operations that implement that policy. He notes that strategies fail more often from skipping a step than from flawed thinking.
I think big enterprises typically skip the last two steps (policy and operations). If you have a strategy that doesn’t change any decision and doesn’t have a mechanism (review, exception process) associated with it, it becomes a slide in a deck that isn’t consulted when the next real decision needs to be made. As Larson wrote in a previous essay, good strategy is boring. It is built bottom-up from existing design decisions, not dreamed up in an offsite. But for diagnosis to happen, you need the raw material, and the maps from The Staff Engineer’s Path provide that (see If you keep one thing from The Staff Engineers Path keep the maps).
This applies to 2026 AI investment. A study from MIT last year, reported by Virtualization Review, found that about 95% of organizations saw no measurable return from generative AI investments (although the methodology is questioned). Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027.
I read this as AI spending without written policy, so a portfolio of pilots with no rule about which to stop. I keep asking what a stop rule would look like in most programs. The book has a useful answer: the LLM-adoption case study narrows the policy to a single concrete use case rather than a broad mandate. That’s the first move I’d copy.
Platform consolidation and cloud cost are in the same category. They’re policy questions, not migration programs. Policy sets the default path, operations decides who grants exceptions and who reviews them. In a regulated enterprise, strategy has to be legible to finance and risk, not just engineers, or it won’t survive the first time someone asks questions about the budget.
The strongest objection is that strategy documents get written to be written, teams ignore them, and new leaders use them to build empires. I think this describes a strategy that lacks both diagnosis and operations. The cure for both is a boring written strategy that’s rooted in decisions people recognize so you can point to a line and say “yeah, I disagree with that.”
As an engineering leader, pick one live decision (like a list of permitted AI tools, or a platform default), write down on one page the diagnosis and the policy, and then name the mechanism that enforces it (a design review, or a standing exception process with an owner).