The VMSO Framework brings clarity, alignment, and purpose to teams

02 Dec 2024

VMSO stands for vision, mission, strategy, and objectives. It’s a framework for a project, organization, or team. In this article, I’ll explain team-level VMSO.

Once your organization crosses a certain number of employees and teams, dysfunctions appear. These include misalignment between team members or teams, miscommunication around priorities, duplicated efforts, or activities that “fell through the cracks.”

Many of these dysfunctions result from teams lacking clarity on their scope and goals, and others not understanding the boundaries of responsibilities, dependencies, and the objectives and priorities across teams.

I experimented with several ways to prevent and deal with these dysfunctions. One of the best frameworks for addressing a broad range of team and cross-team dysfunctions is the VMSO framework. It’s lightweight and gives teams a sense of autonomy and ownership. It helps executives validate and adjust team ownership and interfaces between teams.

VMSOs complement PRFAQs and OKRs. PRFAQs focus on strategy and vision for projects and initiatives (e.g., a new product). OKRs set and track near-term goals for a mission. VMSOs ensure teams understand the “contract” they’re “entering” within the organization.

In this article, I’ll use examples of tech teams with software engineers, an SDM, a product manager, and potentially data scientists, UX, and other roles that make up a stable work unit. These can be people reporting to the same manager, or a squad/virtual team working together. It’s irrelevant if your organization uses a matrix, functional, divisional, or other structure.

The VMSO Framework

The final VMSO artifact is a document published on an internal page (Wiki, Confluence, Notion, etc.) for each team. It has the team name and four sections: Vision, Mission, Strategy, and Objectives. You might include the team members’ names and roles.

Here’s what’s included in each section.

Vision

Vision represents the aspirational future state of the world once this team’s work is complete or operating at maximum impact. A bold vision imagines a world where the core problem doesn’t exist anymore because this team solved it.

Teams often make the mistake of crafting clever or marketing-ish statements because that’s what they’ve seen from vision statements. It doesn’t have to be clever, just clear and accurate. Here are a few examples:

Our platform has 100% uptime.
Allowing customers to pay any way they want.
We allow customers to access their Electronic Medical Records from any vendor.
The most comprehensive and delightful mobile video editor experience.
We pay our employees with 100% accuracy and on time.

Vision rarely changes unless there’s a shift in the team’s scope or the organization’s direction. If you’re writing a vision statement likely to change in six or twelve months, reconsider the broader context that glues this team.

Mission

Your understanding of Mission Statements will diverge from a team VMSO mission. Since this is at the team level, it doesn’t make sense—in most cases—to have missions that are two, three, or five years long. Maybe if you’re an AI research team or trying to make a breakthrough in new hardware or materials, yes, you can have long-term mission statements. Otherwise, you want your mission statement to reflect this year’s team goals.

As a refresh, vision refers to an aspirational future state, and mission refers to the team’s scope of work and actions for the next period—typically a year.

Here’s another perspective: A vision never expires, but a mission does. The team might have missed its mission for the year and needs to try again.

We’ll move our Kubernetes to AWS EKS and deploy geographic redundancy for all services.
In 2025, we’ll integrate with ACH (direct deposit), Buy Now, Pay Later (BNPL), and support Crypto Payments (BTC and ETH).
By year-end, we’ll have integrated with eight of the top ten US EMR vendors.
We’ll rebuild our employee attendance data pipeline and replace our payroll vendor.

If your mission is starting to sound like an annual OKR, don’t be surprised; it kind of is. Many people will say that’s bananas and a mission statement shouldn’t be an “Objective.” I disagree. Your mission statement is the one objective for the entire team for the year. It doesn’t account for 100% of the work, but it should represent 80-99%. If you think the mission isn’t covering that much, step back, and see what’s the bigger mission that encapsulates this and other things.

I think the mission is the most important element to communicate to other teams and executives why this team exists. The vision is too abstract. The strategy is too detailed. The mission is the summary that gets people agreeing this is an important work that will move the organization forward.

If you pick a book or article about writing a vision and a mission statement, they will emphasize the importance of being inspiring, unique, and differentiated (from competitors). However, when writing a vision and a mission for a team within an organization, those characteristics aren’t important. It’s more important to be precise and clear than unique and differentiated. The idea of Unique Selling Proposition, Unfair Advantage, Competitive Edge, Disruption, Differentiation Strategy or any other MBA jargon is not applicable.

Check for and avoid words like “revolutionary,” “disruptive,” “unique,” “first (of a kind),” or others that make it sound like the team is trying too hard or that it feels like an MBA-trained GPT.

Strategy

Writing a brief strategy for the VMSO isn’t easy, but it doesn’t have to be complicated or comprehensive. You don’t want a full strategic document. You want something that outlines “how” the team plans to achieve the mission.

A good strategy narrative outlines the choices, trade-offs, and priorities for the year. Are you building in-house or using vendors? Are you re-architecting and re-implementing the component or refactoring? Do you need UX Research for a new experience or augmenting the existing one? Is it mobile-first or web-first?

Write two to four paragraphs describing these aspects, briefly explaining the choices. A good strategy doesn’t have a step-by-step plan. Leave that for your quarterly planning or other project planning and prioritization throughout the year.

You want to highlight an order of importance. It might be that to extend the service, you need to migrate to a different framework or platform. That’s relevant information for setting a timeline expectation within the team, with executives, and other teams.

Choice is key to a strategy. If there wasn’t a choice between A and B options, it’s not a strategy. Every strategy is a set of choices and trade-offs. Saying “sell more,” “acquire more users,” or “improve uptime” are not strategies.

Objectives

In the VMSO context, objectives are equivalent to the three to five annual objectives in the OKR or SMART goals. You’re breaking into three to five bold and achievable goals aligned and validated with peer teams and executive leadership to ensure organization coherence.

To validate your yearly objectives, ask people how they’d feel if each objective was achieved by the end of the year. Are they excited and inspired, or find it mundane? Are they skeptical about achieving it, or think it will be hard work but doable? Do they think it will deliver the right impact based on the resources and effort, or just shuffling things?

VMSO Crafting & Reviews

The ideal VMSO creation process has three steps: 1) Team drafts VMSO, 2) team reviews VMSO with peer teams, and 3) team reviews the VMSO with the management chain (executive leaders). Revisions occur throughout. Once complete, the VMSO gets published and communicated internally.

When to write a VMSO (and when to update one)

Aim to write a VMSO once a year, ideally in December or January. This article won’t cover Zero-Based Budgeting (ZBB), Top-Down Budgeting, or other annual planning methods. After budgeting and goal setting, write your VMSO, but before quarterly OKRs.

This is a dilemma with PRFAQs involved. Teams are often formed to execute on a PRFAQ. In that context, you have an order that looks like:

PRFAQs → Budgeting + Annual Goals → VMSO → OKRs → Execution

If the organization understands its opportunities, the above would be a common pattern. In other words, they have a hypothesis of a solution (for a customer’s problem/need/desire). An alternative is if the team understands there’s a problem, but no proposed solutions (example: “We need to reduce fake accounts on our platform”). That translates into:

Budgeting + Annual Goals → VMSO → PRFAQs → OKRs → Execution

Inputs, Outputs, and Outcomes

When crafting the VMSO, it’s crucial to understand the differences between system input, output, and outcomes. Input is what you put into the system (hours worked, tickets resolved, training data); output is what you get out (widgets, features, number of videos/pages); and outcome is the benefit or impact created by the output (increased revenue, improved customer satisfaction, environmental impact).

We can control inputs, so we tend to over-index in using it in VMSO (and OKRs). Just like writing OKRs, we should favor Outcomes (recommended) or Outputs language. Using Inputs causes two problems: 1) It locks you into a specific way of doing things, which might not be the best way once you get started, and 2) people will focus on doing those things versus the impact they create.

Ironically, organizations with a strong “Bias for Action” tend to have more people doing busy work because they feel doing something is better than doing nothing. You want a Bias for Impact! That’s what you get when you describe the situation in terms of desired outcomes.

Summary

Each team unit should write their VMSO once a year, review it with peers and executives, and share it with the organization. This brings clarity to team members and other teams about the scope and priorities of each team. The consequences are fewer miscommunications, misalignments, and more impact on the business and customer.