Clearly stating the purpose and trajectory of a team is an important but oft-undervalued part of creating a new team. While missions and visions may seem like ambiguous artifacts intended only for the peacocking of the management class, well-crafted statements of intention can be very helpful to a team. They tell you and your stakeholders what is in- and out-of-bounds. What to expect from you—and not.
I’ve recently stood up a new Machine Learning Operations team. As part of that, I spent some time reflecting on their purpose and putting it into writing. I found that what I saw as their constraints and driving factors actually applied to almost every operations and platform team. Perfect for a template!
Before we get to that, it’s worth exploring some of the background that went into it.
Developing purpose for service teams.
The most important part of all of this is to clarify what needs to be solved by this team. The necessity of a solution entails the existence of a problem, which will serve as the team’s key focus. Additionally, we want to add some structure to give the team guidance on their approach, so we want to capture some high-level notes on how we’ll solve the problem. This will need to account for what’s realistic for the business to support. Anything can be solved with unlimited time or money, but chances are that this isn’t the length of the leash you’ve been handed.
When you look at this obliquely, you’ll see that we’re exploring different aspects of our constraints.
In my case, and I’d conjecture this follows for most other cases, platform and operations teams must conduct themselves in a way that scales asymmetrically with the rest of the organization. Every decision and project have to have a force-multiplication effect. The changes they are looking for must be high leverage to continue having impact in an organization that is most likely out-pacing their own growth.
With this in mind, the strategic constraint I’m most focused on solving is the difference in growth and scale between our ML Ops team and the rest of the organization. We’ll choose to focus our efforts on what makes product teams most autonomous and least reliant on the immediate efforts of ML Ops engineers. We know it’ll take quite a lot of effort to get into that state, which is another constraint to account for.
Artifacts of purpose.
The constraints analysis described above could be written into an appendix, draft notes, or left entirely in your mind. What we’re meaning to offer the team is the So What? of it, which we’re going to capture as three small documents.
The first, and most important, is the vision. This describes what the world looks like once the team has fully exhausted its purpose. A great vision should rarely change, if ever, and most likely is not actually a goal that can be directly accomplished—it’s there to guide the team’s momentum in a particular direction. It should be short and memorable. Details will go into the other artifacts.
Example: We are ending childhood hunger in the United States.
Next is the mission, which covers how you’re fulfilling the vision at a high level. This is the highest-level way you can find to describe the basics of your approach to solving the problem. It should be brief enough to be impactful, but needs to contain enough detail about how you intend to operate to get a sense of what kinds of actions you’ll take. This statement should be general enough to also resist getting changed.
Example: We work to feed hungry children by organizing donation drives, warehousing donations, and coordinating logistics for distributing goods. We do this through door-to-door solicitation and online advertising to collect digital donations through our websites.
Finally, we have the strategy which provides a coarse overview of the plan as imagined today. A strategy usually isn’t a roadmap. It likely covers the themes or initiatives of the team’s major next steps, though. A good description will list a small handful of items which together provide a sense of motion along the path of the mission toward the outcomes of the vision. These could be concrete goals or classes of effort necessary to make progress.
Example: Our physical operations have been well-established for a decade, but our digital presence is still nascent. To take the next step in our journey, we will first build a partnership with a digital marketing firm. Next, …
The template!
Vision.
Short, memorable statement about the change you want to make in the world.
Team name enables target user group to do some important thing that is hard or missing today.
Mission.
How do you operate to execute on the vision?
We support the some valuable trait of target user group by building and maintaining architecture, patterns, infrastructure, and training materials for target user group members to use. Where a project needs to evolve any of those, we intend to embed into projects to learn and build alongside target user group members. Where a project primarily benefits from existing patterns and technology, we intend to support members of the team directly through education, clarification, and refinements, but otherwise allow the team to execute the project autonomously.
Strategy.
What do the major parts of the long-ish-term plan look like?
We will execute on this through four logical “stage themes”—this is a trajectory more than it is a clean four-chaptered book.
-
Learn through doing: We will follow a project-embedding model to
do the thingalongsidetarget user group members. Our design choices will enable teams to maintain the work themselves as much as possible, but we expect to help with maintenance. - Abstract the architecture: Taking what we have learned through multiple projects, we will refine the common requirements out into an architecture that optimizes for self-service.
- Maintain the architecture: Once things get into a largely self-service state, we will continue to support the architecture as its usage grows and our needs evolve. We will take cues from those using it and the system itself to decide where to further invest.
-
Return to step 1: Where things are now humming along without requiring
team name‘s attention on projects, we are now free to embed on projects to further accelerate them. We should not represent blockers for teams whose projects we aren’t actively contributing to, but we are able to add some limited throughput to some projects.
Your needs might be quite different than what I’ve laid out here. That’s okay! The purpose this template serves is mostly in building new operations or platform capabilities in an org. It’s not every day that you build new teams to do that; you’re more likely to already have a maturing capability and team, but you may instead want to improve how they view their purpose.
Take what’s useful in the template and ditch the rest. If you follow a methodical process for breaking down the team’s purpose and practices, you’ll end up with a set of statements that are quite useful for members of the team. They’ll be able to see where you are heading together, but also understand how aspects of the team’s “how” roll up into their “why”. Armed with this intuition, they will be more able to engage their work and to better apply their creativity to the decisions they make all day, every day. It just works so much better when everyone is operating from the same playbook.