Creating a Mission
A DevRel mission gives the work a spine.
It is the sentence that tells the team what business problem it exists to solve, which developers it serves, and what kind of work counts.
Without a mission, DevRel becomes a list of requests. A speaker. A blog post. A demo. A staffed booth. All of those might be useful. None of them answer the harder question.
Why should this team exist?
Start with the business problem
Begin with the business problem, not the calendar.
Bad missions start with activity. Publish more. Attend more. Grow followers. Make noise.
Useful missions start with the change the organization needs. Help developers adopt a platform. Reduce friction in a new product. Build trust with a technical audience. Turn field feedback into better technology. Create a path from curiosity to first success.
The mission gives the work a filter.
Some requests are good work without being DevRel's work. The mission helps the team tell the difference.
Name the developer
"Developers" is too broad to guide choices.
A mission names the kind of developer the team is trying to help. New users need a different motion than experienced builders. Enterprise developers need a different path than hobbyists. A data scientist trying a notebook needs different content than a platform engineer setting up production access.
The clearer the audience, the easier it is to decide what to make.
Ask these questions before writing the mission.
- Who are we trying to help?
- What are they trying to build?
- Where do they get stuck?
- What do we need them to trust?
- What action should become easier because we exist?
Imperfect answers are fine. Specific answers give the team enough shape to make tradeoffs.
Make it operational
A mission needs to work on a Tuesday.
The team can look at a request and decide whether it fits. The mission helps choose between a talk and a sample, between a broad awareness video and a narrow setup guide, between attending another event and fixing the demo that keeps breaking.
A good mission creates constraints. That is what makes it useful.
Try this shape.
We help [specific developers] do [specific valuable work] by [DevRel motion], so [business outcome].
For example, a platform DevRel mission might be to help application developers build their first production ready integration by creating content, samples, and feedback loops that reduce time to first success and improve the developer experience.
That sentence can be tested. It names the audience, the action, the work in scope, and the outcome that should improve.
Mission before structure
Do not start with the org chart.
Start with the mission. Then define the principles that guide the work. Then design the structure that helps the work happen repeatedly.
The order matters. If structure comes first, the team spends its energy defending roles. If mission comes first, roles become a way to serve the work.
DevRel teams change shape as products, markets, and communities change. The mission is what keeps that change coherent.