Recently I’ve prepared several strategy documents. One of them, which I’m especially proud of, set the direction for an organization of 10 teams and 50 engineers in total.
Recently a colleague asked me to share my experience preparing technical strategies (and I didn’t make that up!). I don’t want my answer to stay just between the two of us — below are three steps, from the first conversation with stakeholders to the moment the strategy becomes the team’s anchor in everyday decisions.
Step one: assessing stakeholders
Work on any strategy starts with assessing stakeholders. I clearly separate three key groups:
-
Those who will approve the strategy. These are usually leaders or people with a mandate to make final decisions. At this stage it’s important for me to talk with them and find out what tasks they’re setting and what they want to see as the outcome.
-
Those the strategy will affect. These are users, adjacent teams, or the wider organization. Here the main task is to hear their expectations: what they’d like to get out of the strategy being implemented.
-
Those who will implement the strategy. This is the most important category. These are the people who turn ideas into practice. With them I build a dialogue in which I talk through the expectations from the previous two groups, check understanding, argue, and align on approaches. I keep at it until we all reach a shared vision.
Step two: writing the document
Once the initial round of discussions is done, it’s time to shape the strategy into a document. For that you need to settle on a structure. It can be specific to the particular problem or lean on general, proven approaches.
Personally, the model closest to me is the one from Good Strategy Bad Strategy, which I use in a simplified form:
- Diagnosis of the Challenge — a clear description of the problem to be solved.
- Guiding Policy — the approach to solving it.
Here it’s fundamentally important to stress: a strategy should not contain specific decisions. Its job is to articulate a way of thinking, a frame within which those decisions will be made. Decisions change along with context and plans, while approaches stay constant until the very nature of the challenge changes. That said, it’s sometimes worth adding a Coherent Actions section with a short-term action plan.
I don’t use any AI tools for writing strategies. Instead — authentic composition, and revision with Grammarly.
Then comes the check against the stakeholders:
- Those who will implement it. Ideally, when they see the document, there’s nothing new in it for them. We’ve already talked through all the key things, and now they’re simply glad to see their thoughts captured on paper.
- Those who will approve it. Here it’s important to show that the tasks they set have an answer. This is the point where you get the final “go.”
- Those the strategy will affect. The document is presented to them to gather feedback and additional alignment.
Step three: applying it in practice
A finished strategy is not a static document. It becomes the anchor for all subsequent discussions and decisions. In practice this means constant “anchoring”: “We do it this way because that’s what the strategy defines,” “We made this decision because it aligns with the strategy.” This way the strategy becomes a living tool that shapes unity in the team’s actions and thinking.
Vivid formulations or slogans play an important role too. They help keep the essence of the approach in mind and communicate it quickly to others. A good strategy always has an element of simplicity and memorability.
What time horizon is worth considering? In my view, the optimal span is 1–2 years. Shorter intervals don’t need a strategy — a plan is enough there. Overly long horizons, meanwhile, become unrealistic in conditions of constantly changing context.
A strategy’s effectiveness depends directly on how focused it is on approaches rather than details. Approaches remain valid until the challenge changes. That’s exactly why a good strategy has a longer “shelf life” than a specific plan or set of decisions.