How to use the "developer relations anywhere" template
This is a adaptable template to build draft developer relations plans when starting or restarting developer relations programs.
One way to use this template is to organize your understanding of an organization's needs during the interview process. You can remove what's not relevant to their goals, add your hunches and analysis as they develop.
This template can then translate well in developing your plans over the next several months and years as your developer ecosystem matures.
I've been extraordinarily lucky to work in the early days of technical evangelism, developer relations, and platform management at a number of companies and this template represents my approach to tackling developer relations anywhere.
How to use this
This draft developer plan is a template meant to be cloned for your own organization.
The draft references abstract platform product and treats developers as a very broad category.
In reality, your product is more specific and you likely have a subset of the entire developer market in mind. Bring your own platform facts, foibles, and fun.
This template is most effective for growth-minded developer relations teams operating directly with product and engineering. Suggested local metrics are mostly placeholders, meant to be replaced with the kinds of metrics you care about.
Customize the template as you learn about your company, its platform, and its developers. Find the approach that will serve them best by removing irrelevant subteams or adding new ones.
Suggestions or improvements welcome. This belongs to all of us!
Customization suggestions
Team structure
If your team is just starting out and it's only you, use this section to help guide and divide the work your team of one has to accomplish. Maybe you don't have partners yet and don't need to help them hands-on. Maybe your company is already setup to serve developers well with their own documentation or tools team.
All these categories are your responsibility in developer relations whether another team owns the work product around them or not. As you identify your weak spots and how you could better serve your unique developer audience, begin hiring those who can make a major impact in one or more of these specializations.
As your team grows and each specialization team becomes their own thing, you need to find ways to mix and remix the cross-functional work together. Usually one or more people on the team will emerge as "operators" who cross the boundaries of 2 or 3 different teams, contributing to sample apps, documentation, product development, and advocacy all at the same time. Take a penny, leave a quarter kind of work.
Metrics
Developer relations is largely a faith-based operation. You believe that your work is going to make a developer more likely to succeed and that a developer's success is good for your platform.
That belief, along with empathy, motivates most decisions developer relations teams will make day-to-day. Just as you don't want your team to watch the clock like their work is a form of torture, you also don't want to focus overmuch on trailing metrics you don't have much direct control on.
Local metrics are within direct influence of the developer relations team. You can increase time on page. You can encourage readers through a specific funnel. You can reduce error rates in the CLI. Identifying friction is quantifying friction. Reduced friction is a local metric in developer relations' control and will, with faith, influence developer activation and enablement. Developer relations can drive feature adoption and breadth. Your platform is best when your developer relations team loves it; XX% of developer relations team agrees X is good is a measure worth tracking.
Find what is locally relevant for your team.
Activation
You want as many developers or visitors to reach an ah-ha moment that convinces them your solution is the right one, provided it is.
From that point forward, every piece of friction in their experience can stop them from successfully accomplishing their goal.
Reducing friction reduces time to business logic. The joy in programming is there, in the business logic.
Build a friction log however you see fit, as a collection of observations (& occasional suggestions) on friction encountered through a developer experience.
Think of it like a journal kept while walking through your platform's metaphorical park. Useful in early stages of joining a developer relations team to introduce an outside perspective. In later stages of team membership, to continue the metaphor, it's important to pick up the easy trash as you go. No use hoarding maps of all the litter in the park.
Thanks to
Thank you to the one who helped with my first Perl ah-ha moment, it's guided the way since. Thank you for the tips, tricks, traps, trouble, and trust Brandon, Jim, Adam, Ryan, Amir, and Bear. Teams are where the dream becomes reality and the teams I work with teach me what's possible and probably at every turn. Thanks to LinkedIn, (the original) Twitter, Clever, and Slack for letting me stumble through devrel origin stories. And thank you to the partners in crime I depend on and learn from all the time.
Changelog
- November 2023 - continue developing the README.md framing, move to
https://devrel.realitytechnicians.com/ - October 2023 - moved from Google Docs to Github to better enable community collaboration and adaptation. Re-organizing content and content about content.
- June 2023 - first draft authored by Taylor Singletary (@episod)
TODOs
- Add variant templates for different types of developer products (Web APIs, developer tools, databases, etc)
- Add campaign examples for growth efforts
License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
