How do you write a technical strategy that changes what teams do, and get it adopted without authority?
Answer
Short answer
A strategy is a diagnosis, a small set of decisions already made, and the things you are choosing not to do — written so a team can tell whether next quarter's plan complies.
A technical strategy only matters if it creates influence over real decisions. Good technical strategy narrows choices: what to standardise, what to stop doing, what to fund, and what trade-off leaders must accept. Weak technical strategy is a document of aspirations. Strong influence comes from making the technical strategy concrete enough that teams can use it in planning, architecture review, hiring, and sequencing debates.
Influence comes from making the strategy usable at the moment a team is choosing between two plausible paths.
Was this answer helpful?
Likely follow-ups
- A funded project contradicts the strategy. Walk me through that conversation with its sponsor.
- How do you tell after six months whether the strategy worked?
- What goes in the exemption process, and who signs it?
- How does this document change when a new CTO arrives with different priorities?
Related questions
- A headquarters team in another time zone keeps making decisions that land on your team. Tell me how you handled it.mediumAlso on decision-records5 min
- How do you decide whether to build a capability in-house or buy it?mediumAlso on technical-strategy5 min
- How do you make the case for headcount or a platform investment, and what do you do about a stakeholder who keeps going around you?hardAlso on influence5 min
- Feature delivery and paying down architectural debt are competing for the same engineers. How do you decide the split and defend it?hardAlso on influence6 min