Engineering Leadership · Chapter 6 of 8
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.