Engineering Leadership · Chapter 6 of 9
Technical strategy that is not a wish list
Most engineering strategy documents are a list of things the author likes. This is what makes one useful.
A strategy is a choice about where to be strong and where to be deliberately weak. A document with no explicit weakness is a wish list, and it will not survive its first budget conversation.
The shape that works
- The diagnosis — what is actually true about our situation, with evidence. Most strategy documents skip this and start at solutions, which is why they are unarguable and therefore unusable.
- The choice — given that, what we will do and, explicitly, what we will not. Naming what you are giving up is what makes it a strategy.
- The coherent actions — a small number of things that reinforce each other rather than a list of every good idea.
- What would falsify it — what we would expect to see in six months if this were working, and what would tell us it is not.
Migrations, where most technical strategy actually lives
The recurring pattern: a migration is funded, it is 70% done, and the remaining 30% never finishes because the value was front-loaded and the cost was not. Then you carry two systems forever, which is worse than either. The controls are unglamorous — fund the finish, do the long tail yourself rather than delegating it, publish a decommission date and hold it, and be willing to reverse if the diagnosis turns out to have been wrong.
The most valuable strategy decision is usually a stop
Killing a funded programme is harder and more valuable than starting one, because the sunk cost is emotional as well as financial. A leader with a story about something they stopped — and what it cost them politically — is immediately more credible than one with a list of launches.
What makes a strategy rather than a list
Most documents titled ‘technical strategy’ are a list of things the author would like to be true. A strategy has three parts, and the middle one is what is almost always missing.
- A diagnosis. What is actually going on, stated in a way that could be wrong. ‘Our deploys are slow’ is a symptom; ‘we cannot deploy independently because four services share one database schema, so every release is a synchronisation event’ is a diagnosis.
- A guiding policy — the approach chosen in preference to other approaches. This is the missing part. A policy that excludes nothing is not a policy, and the test is whether a reasonable person could have chosen differently.
- Coherent actions that follow from the policy and reinforce each other, rather than a list of good ideas that happen to be adjacent.
The test that separates a strategy from a wish list: what are you choosing NOT to do?
A strategy that improves reliability, velocity, cost, security and developer experience simultaneously is a list of virtues. Resources are finite, so a real strategy names what gets worse or waits.
The second test: could a competent person disagree? ‘We will invest in quality’ has no opposition and therefore no content. ‘We will accept slower feature delivery for two quarters to separate the shared schema, because every other improvement is downstream of it’ has a real alternative and can be argued against.
The third test, and the one that predicts whether it survives: does it say what would make you abandon it? A strategy with no falsifying condition gets defended past its usefulness, because there is no agreed way to notice it is not working.
On horizon: a technical strategy that reaches beyond about eighteen months in this industry is usually fiction, and one that reaches less than two quarters is a plan. The useful shape is a diagnosis that is stable for years, a policy stable for a year or so, and actions revisited each quarter.
And on getting it adopted: a strategy nobody can repeat does not exist. If the engineers cannot state the guiding policy in one sentence without looking it up, the document is a record of your thinking rather than a mechanism for anyone else's. Write for repetition.
Check yourself