Say what your team is for, without notes
A team mission is not a paragraph on a wiki. It is a sentence the manager and every engineer can say out loud when a new executive asks. How I write one, how vision and strategy hang off it, and why I rehearse it.
A new VP joined the company and spent her first two weeks meeting every team. She asked each manager the same question: what is your team for? I had a mission statement on our wiki page. I had not read it in a year, and when she asked, I gave her three sentences that did not match it and did not match what my tech lead told her an hour later.
She was polite about it. She was also, correctly, drawing a conclusion about how well I understood my own team.
The test is whether you can say it
A mission only exists if people can say it without looking. Not recite a paragraph. Say, in one breath, what the team does, for whom, and to what standard. If the manager needs notes, the mission is decoration. If the engineers give different answers, the team is being pulled in different directions and nobody has noticed yet.
So the mission on my teams is one sentence, and I check it the way the VP did. I ask engineers, in 1:1s, what the team is for, and I listen for whether the answer matches mine. When it drifts, that is the earliest signal I get that the work has drifted too.
Writing the sentence
The shape I use has three parts: who we serve, what capability we give them, and the quality bar we hold. For a data platform team that might be: we give every product team in the company reliable, secure access to customer data, fast enough that they never build their own copy. For an infrastructure team: we make it possible for any engineer to ship to production safely in under an hour.
The quality bar is the part people skip and it is the part that makes the sentence useful. Reliable, secure, fast enough that they never build their own copy tells the team what to say no to. Without it, the mission is a job description.
I write the first draft, then I hand it to the team and let them tear it up. The version that survives is the one someone can say in a meeting from memory to explain a decision. That is the only test that matters.
Mission, vision, strategy: three different questions
People use these words interchangeably and then wonder why the document feels muddled. They answer different questions.
The mission answers what we are for. It is stable. It should survive a reorganisation and two roadmaps.
The vision answers what the world looks like in two or three years if we do our job well. It is concrete enough that you could tell whether you arrived. For the infrastructure team above: no engineer has been paged for a deploy in a year, and new services go live on their first day. A vision you cannot verify is a slogan.
The strategy answers how we get from here to there, and it is the only one of the three that is supposed to change. It is a short list of bets, each with the cost written next to it. We are standardising on one deploy path, which means three teams with custom pipelines will be slower for a quarter. A strategy with no cost attached is a hope.
When the three are written down and lined up, the roadmap almost writes itself, because every project either serves a bet in the strategy or it does not belong.
The manager's part
There is a version of this where the manager inherits a mission from above and passes it down. That is not the job. The company sets direction. The team's mission is the manager's translation of that direction into what this specific group of people is uniquely positioned to do, and the strategy is the manager's set of bets on how to do it.
That means I have to be able to explain not only what the mission is but why it is that and not something else, what I chose not to include, and which bet in the strategy I am least sure about. When someone senior asks about my team, those are the answers that tell them whether I am running it or just reporting on it.
Rehearse it
This felt silly the first time I did it and I have done it before every leadership change since. I say the mission out loud, then the vision, then the three bets in the strategy and what each one costs. Thirty seconds for the short version. Two minutes for the version with the reasoning. I do it in the car.
The rehearsal is not about performing. It is about finding the places where I do not actually believe what I wrote. Every time I have practised, one line came out awkward, and the awkward line was always the one that was not true anymore. Fixing it in the car is much better than discovering it in front of a new VP.
When the sentence changed
The mission of my team did not change when we moved to an AI first way of working. The team was still for the same thing. What changed was the strategy, because the volume of changes doubled and the shape of the work moved from writing code to directing and reviewing it. The bets shifted toward review tooling and smaller merges, and the cost of those bets was named up front.
Holding the mission steady while the strategy moved is what made the change legible to the team. They could see that the reason the team existed had not moved an inch, and that the new bets were in service of it. A team that can say what it is for can absorb a lot of change underneath that sentence.