| title | description |
|---|---|
Developer relations anywhere template |
A template to help you start or restart a developer relations function. |
We make our product meaningful for developers. We show you what's possible. We teach you how to do it yourself. We celebrate your wins, help you through your struggles, and we're there when you're ready to do it all over again.
With a clear north star, the most effective developer relations teams will "divide and conquer" responsibilities even when the team is just starting out with 1-4 individuals and these roles are combined. As teams grow larger, these four disciplines must increasingly collaborate together to deliver meaningful developer experiences. Of course, we might not have permission to own all these areas, but to operate effectively we must build influence and trust to accomplish our common goals.
A product-oriented developer relations team might arrange itself to serve four primary functions:
- Education - teach the how, what, and why of the product
- Produce engaging, well-organized, and accurate technical documentation and tutorials around the core services we provide.
- Develop processes, procedures, and occasionally software to maintain a growing corpus of content and learning experiences.
- Innovate on creative ways to teach and effectively bring developers to and beyond their first a-ha moment.
- Engineering - provide the tools, libraries, and infrastructure devs need to succeed
- Produce, enhance, and amplify the tools, SDKs, and other software developers need to be successful on the platform.
- Make the developer journey as measurable as possible.
- Provide a consistent, predictable end-to-end developer experience.
- Manage our open source strategy and presence.
- Partner engineering - make strategic business deals work for everyone
- Pitch the art of the possible to partners, independent software developers, and other stakeholders.
- Build example integrations by collaborating deeply with our most important partners, on their terms.
- Represent partner needs, wants, and delights internally to product & engineering.
- Advocacy - customers will love us if we love them
- Produce timely material that reaches our target personas in the mediums that serve them best, including but not limited to tutorials, blog posts, video, webinars, and workshops.
- Author deeper pieces on emerging and fringe topics important to our growing developer community.
- Be the face of developer relations to the community, on-line and beyond.
- Scale customer-facing programs appropriately with growth targets.
- Keep the long tail of developers warm and well-taken care of.
The entire developer relations organization shares responsibility and builds partnerships in:
- Go to market support
- We want our customers and partners to succeed and sometimes that means teaming up to go above and beyond.
- Developer support and advocacy
- Everyone benefits from experiencing the platform, tools, and documentation from the perspective of those we serve.
- Developer support happens on Slack, Discord, in GitHub issues & pull requests, in customer and partner calls, and wherever else developers bring their needs.
- Everyone uses their "in the field" experience to improve the product and developer experience by becoming a trusted voice of the developer.
- Producing tutorial and workshop content
- Utilizing the expertise required from each discipline results in more effective, inter-connected learning materials that scale with complexity
- Developer relations operations
- Everything it takes to serve developers day to day, week to week, month to month, quarter to quarter, or even campaign to campaign.
- Teaching and upleveling everyone else on the team with unique pockets of knowledge and experience.
This team organization assumes that a developer marketing function and a business development function operate outside of developer relations. Some adjustments are necessary as funding shifts for these functions.
Our developer relations organization uses metrics to inform our decision making. To impact company-wide KPIs, we'll identify, hypothesize, and experiment with metrics local to our work and influence. We can adapt how we measure and set goals whether the organization prefers loose planning, OKRs, or V2MOMs. We're here to take care of developers no matter what the company is up to.
Without knowing our business too deeply, we start with baseline assumptions that:
- Friction in the developer experience is the primary drop off point for the developer activation funnel.
- It's best to "meet" developers where they are or where they're going to be. We can't expect them to join our community and use only our tools, exactly as we want them to. But we can encourage them to.
- Experiencing the joy of our developer product is the best way to inspire developers. The sooner a developer experiences the product and the better the experience is, the sooner they can build something meaningful.
- Developers need help reaching the end of their funnel. It's not enough to attract them, we need to help them succeed.
We'll increase the number of integrations going to market by increasing the number of monthly active developers and their rate of success with tactics like:
| Theme | Example KPIs | Sample projects |
|---|---|---|
| ✅ Reduce friction |
|
|
| 🤝 Meet developers where they are |
|
|
| 🦉 Increase product exposure |
|
|
| 🦾 Help developers succeed |
|
|
We want all developers to feel welcome and empowered. We can and will provide them an amazing experience.
- Instrument our developer funnel
- Identify primary drop off points
- Continously reduce friction and measure impact
With so many developer personas working with us, we must identify common goals and the most important outliers to best serve and enable those most likely (or most desired) to succeed.
Research and continous learning is as important for this developer relations team as it is for our developers.
We also must remain open to doing activities that will not scale to reach outcomes.
With an instrumented developer funnel, we should identify the primary points of drop off and propose solutions to alleviate those, especially those that happen earliest in the process or are the biggest indicators of future success.
If there are shortcuts to success for these personas, we should build them and put them in reach!
Once we have high confidence a persona will be successful, we should consider campaign-based approaches to grow their introduction to the funnel, including targeted advertising, and direct outreach.
The last thing we want is a life-long developer trying the product, hitting a major point of friction, and then leaving with no intent to return.
Campaigns to grow developers don't just start and stop in developer relations, we need the help of marketing, product, engineering, design, and even our developers.
Of all things measurable from the outside: improving documentation, tutorials, and enablement materials often are the highest priority.
No matter how many developers flow through the door, if they can't find what they need to succeed, they'll go away frustrated. Insufficient documentation is more than just a friction point, it's a crisis that only very few will weather.
A more cohesive education experience is paramount to onboarding and activating developers from all journeys. What are some deterministic, successful experiences developers can have to introduce themselves to everything our platform can do?
Of course, our predicted projects match our identified themes...
| Theme | Projects | Outcomes |
|---|---|---|
| ✅ Reduce friction |
|
|
| 🤝 Meet developers where they are |
|
|
| 🦉 Increase product exposure |
|
|
| 🦾 Help developers succeed |
|
|
We believe that building tools and SDKs for developers is an investment leading to more productive developers and a shorter time to coding business logic.
Building SDKs enables us to better engage developers where they are and with their preferences in mind. It provides us additional avenues to encourage and reward a thriving ecosystem.
Our tools and SDKs also provide us valuable data and opportunties to guide developers to the most successful outcomes.
Our events strategy is conservative, opportunistic, and patient.
Every developer relations program has an events strategy. Sponsoring, attending, and hosting events can be an expensive distraction with intangible rewards.
Being where your developers are is important. Our developers are on the internet. All of them. Most developers who will ever use our product will never attend a meetup, conference, or join our Discord.
Every segment has its influencers and reaching them might happen at an event or through the press that echoes after.
But the single most important event in the confluence of our product and a developer's life is to be present, in mind, and useful in a time of need. Our event strategy focuses on making us top of mind at the right time and place, not on building a lead pipeline giving away free stuff, or building a library of single-serving content.
| Audience | Event | Cost | Goals |
|---|---|---|---|
| Python developers | PyCon | $5,000 |
|
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
