Writing strategies and visions.

As an organization grows beyond fifty people or so, you'll feel a building pressure to add a third layer of management, and eventually you will. This ought to be a benign event, what's the difference between supporting some managers and supporting their managers? It shouldn't be too different, but for me it was when my previous mechanisms of alignment stopped working very well.

Where I was once partnering with teams on their project roadmaps, now I found myself increasingly surprised by the projects they were working on. Where I was once debating different approaches with the teams, now that conversation was happening in rooms I didn't have time to join.

My first instinct was to dive in and understand each instance, but that, unsurprisingly, wasn't a very scalable solution. My second instinct was to design a series of "operating reviews" where we periodically reviewed metrics and major projects, and while those were useful in their own right, they proved more effective for learning and fine-tuning than for broad alignment: being out of alignment for a quarter is just so much uncaptured potential.

What I needed was a way to coordinate my approach across teams, both in terms of very specific challenges and in terms of our long-term direction. After experimenting with a handful of different approaches, agreeing on strategy and vision has been the most effective approach I've found to alignment at scale.

Strategies and visions

Strategies are grounded documents which explain the tradeoffs and actions that will be taken to address a specific challenge. Visions are aspirational documents that enable folks who don't work closely together to make decisions that fit together cleanly.

Strategy

Vision

Purpose

Approach to a specific challenge

A gentle, aligning pressure

Character

Practical

Aspirational

Timeframe

Variable

Long-term

Specificity

Accurate, detailed

Illustrative, directional

Quantity

As many as useful

As few as possible

Picking the right format for your needs is important, but probably the most important thing is to give both a try and get a feel for them! These are peculiar genres of literature that take some practice to get effective at. It's taken me years to get comfortable writing visions, and it was only when I started to support teams with seemingly incompatible ideologies that their value became clear. Same for writing strategies; it took a long time and skeptical study of several strategy books before what I wrote started to come together into a useful artifact.

With that said, it's time to dig into how to write strategies first, and then visions.

The diagnosis is a theory describing the challenge at hand. It calls out the factors and constraints that define the challenge, and at its core is a very thorough problem statement. An example of a simple diagnosis might be, "I am too busy to think about long-term goals. I attend 35 hours of meetings each week. I am under pressure to immediately increase team performance. If I stop doing my current meetings, I believe short-term team performance will decrease. If my short-term team performance decreases, I am concerned I may lose face as an effective leader, which will undermine my career opportunities. If I don't think about long-term goals, I believe our performance will never improve, which will also undermine my career opportunities." Before you've even finished reading a great diagnosis, you'll often have identified several good candidates approaches, which is the power of a well defined problem statement, and why it's an important foundational element to your strategy.

The second step is to identify policies that will be applied to address the challenge. These describe the general approach you'll take, and are often tradeoffs between two competing goals. Continuing the above example, you might choose to allow short-term performance to dip in order to invest into long-term performance, combined with a policy of proactive expectation setting with your stakeholders. Conversely, you might choose to take a hill-climbing approach to long-term performance, with iterative short-term improvement leading to improved long-term performance. Both are valid guiding policies, and embrace the reality that you have limited resources to invest. When you read bad guiding policies, you think, "So what?" because it's found a way to justify entrenching the status quo. When you read good guiding policies, you think, "Ah, that's really going to annoy Anna, Bill and Claire." because it takes a clear stance on competing goals.

When you apply your guiding policies to your diagnosis, you get your actions. Folks are often comfortable with hard decisions in the abstract, but struggle to translate them into the specific steps to implement them. This is typically the easiest part to write, but publishing it and following through with it can be a significant test of your commitment. In the example, your specific actions might be to stop attending weekly team meetings to free up time and move to a monthly metrics review, combined with blocked out focus hours that you unapologetically shelter. When you read good coherent actions, you think, "This is going to be uncomfortable, but I think it can work." When you read bad ones, you think, "Ah, we got afraid of the consequences and aren't really changing anything."

Because they are specific to a given problem, it's ok and even encouraged to write quite a few strategies. Over the past year, I've worked with folks on strategies for how we partner with other teams, how we manage end-to-end API latency, how we manage infrastructure costs, and I've peered over others' shoulders as they worked on quite a few more. The act of writing a strategy leads folks through a systematic analysis, so even if we don't share them, writing these documents has helped us work through quite a few challenges, both overwhelming and mundane.

Folks sometimes describe strategy as artful or sophisticated, but I've found that the hardest part of writing a good strategy is pretty mundane. You must be honest about the constraints that are making the challenge difficult, which almost always include people and organizational aspects that are uncomfortable to acknowledge. No extent of artistry can solve a problem you're unwilling to admit.

Vision

If strategies describe the harsh tradeoffs necessary to overcome a particular challenge, then visions describe a future where those tradeoffs are no longer mutually exclusive. An effective vision helps folks think beyond the constraints of their local maxima, and lightly aligns progress without requiring tight centralized coordination.

You should be writing from a place far enough out that the error bars of uncertainty are undisputable broad, where you can focus on the concepts and not the particulars. Visions should be detailed, but the details are used to illustrate the dream vividly, not to prescriptively constraint its possibilities.

A good vision is composed of:

Vision statement - a one or two sentence aspirational statement to summarize the rest of the document. This is your core speaking point that you will repeat at each meeting, planning period and strategy review. It shouldn't try to capture every detail of your vision, but it does need to memorably evoke your vision effectively.

Value proposition - how will you be valuable to your users and to your company? What kinds of success will you enable them to fulfill? There is a sequencing question of whether you should start with capabilities (the next bullet) and reason into value proposition or do the opposite, but I've found that starting from your users leads to visions which are both more ambitious and more grounded.

Capabilities - what capabilities will the product, platform or team need to deliver on your value proposition? Will it need to support multiple independent business lines? Will it need to deliver against disparate needs of several distinct customer cohorts?

Solved constraints - what are the constraints that you're limited by today, that in the future you'll no longer be constrained by? For example, if you're currently "spending into" developer velocity, perhaps in the future you'll be able to achieve significant developer velocity while also maintaining low costs.

Future constraints - what are the constraints you expect to be constrained by in this wonderful future? Hopefully these new constraints will be something easy to adjust, like funding or hiring.

Reference materials - link all the existing plans, metrics, updates, references and documents into an appendix for folks who walk to understand more of the thinking that went into the vision. This allows you to shed complexity from your vision document without sacrificing context.

Narrative - once you've written the previous sections, the last step of writing a compelling vision is to synthesize all those details in a short, maybe one page, narrative that merges all those details into an easy to digest summary. In your final document, this is probably the second section, following the Statement.

Put all these pieces together, and you've crafted a document that is a guiding hand to align decisions while also creating room for teams to make their own choices and tradeoffs along the way. You'll know a vision is succeeding when folks reference the document to make their own decisions, and you'll know it's struggling when decisions keep happening that don't fit into its direction.

As compared to strategies, there is more room to play with the vision format. You'll be reading far fewer visions than strategies, so consistency is less important, so play with the content a bit to find what works best for you.

A few additional tips that I've found especially useful:

Test the document! This is a core leadership tool, and your first version will almost certainly be bad. Write a draft, sit down with a few different folks to get their perspectives, then iterate. Keep doing this until you've synthesized feedback. If there is feedback you disagree with, explicitly disagree with it in the vision, embrace the vision as an opportunity to address conflict.

Refresh periodically. Take some time every year to refresh the vision, and prefer usefulness over consistency. If your old vision doesn't resonate, it's ok to start over: it's a sign that you've learned a lot over the past year.

Use present tense. This makes the writing impact, concise and conveys a sense of confidence about the future.

Write simply. Often visions are saturated with buzzwords, which turns folks off.

You'll likely want one vision for every complete distinct area, but no more. If areas overlap, you get the alignment value from having one unified vision; having two clearly articulated visions in one place is worse than zero.

Like other leadership tools, a vision or strategy document is a solution to a specific set of problems, and they're not always useful. If your team is aligned and doing good work, time spent writing these probably won't be too valuable. However, if your team is struggling to align with stakeholders, or if you're struggling to lead a cohesive organization, I've found these document exceptionally useful, fairly quick to write as you gain practice, and low risk (at worst, they get ignored).

If you give them a try, or are already an active proponent, I'd love to hear your thoughts and what has or hasn't been effective for you!

Hi folks. I'm Will, known as @lethain on Twitter.
I write about software and management topics,
and love email at lethain[at]gmail.
Get email from me by subscribing to
my weekly newsletter.