Developer Relations is a relatively new industry, at least the term anyways.
For me, the most frustrating part of our “youth” is speaking to contributors who are new to DevRel themselves and are thrown into a role where they’re a team of one, not fully understanding what they got themselves into. Being a DevRel team of one can be an incredibly stressful role, especially if they're not set up for success.
At any given time a DevRel team—whether a single person or who group of pros—can be working to accomplish the following list of tasks.
If we look through this list, we can see activties that align to numerous roles across an organization—and DevRel is often expected to do them all with their developer audience.
Depending on company structure, you may be able to find allies across the org to help support these areas, however, these allies may not know your audience as you do. In my career, I’ve found allies across all of these contribution areas, but I’ve had to work hard to instill what developers need versus other audiences.
Whether you’re a team of one or a team of many, you’re still tasked with the same objectives.
A team of one requires more of a generalist to find success, whereas a collaborative team means you can hire people more specialized in their experience—likely driving a greater impact in that niche. It’s how you scale your developer program efforts.
Let’s take this list of objectives and sort them into the four functional areas of developer relations.
These lists can easily be interchanged, there are no two DevRel teams that are exactly the same, but these separations resonate with my experience and what I’ve learned. Developer Advocates play a role in all four of these functional areas, while a community manager usually focuses on the community function and passively supports the others as needs arise.
If you’ve read the book “Developer Marketing Does Not Exist” you’ve learned that developer marketing, well, doesn't exist, but it doesn’t exist because it’s in the form of education over promotion. Therefore, it’s not really marketing.
That doesn’t stop your stakeholders from assigning marketing-like goals to your programs and team. Therefore, you need to do this through educational driven contributions and focus on what your audience needs to find you trustworthy.
Your DevRel program can be one-person or a fully-staffed team with leaders across various functions. If you’re a lean program and only have a developer advocate on staff, it’s likely those folks are burning out, quickly. Consider finding allies across the org to supplement their contributions as well as bringing in someone to specifically lead the community and maybe even experience.
As you scale you should consider bringing in additional developer advocates, DX engineers, technical writers, multimedia producers, and more. I’ve shared some job titles below that I’ve seen across various Developer Relations teams.
Every organization has different needs and different goals and DevRel teams need to adapt and understand how to best serve their developer audience across many different specialties and skillsets.
This article was originally posted on Devocate, which joined the Common Room family in August 2022. For more developer relations insights and resources, check out the Common Room blog. Learn more about Common Room’s solution for DevRel teams if you're looking for an intelligent community growth platform to educate, empower, and enable your community.