What is a DevRel
Technical content, community, and feedback - the role known as Developer Relations, Developer Advocate, Tech Evangelist, etc...
The full list of activities and audiences this role addresses is confusingly diverse, but here’s the gist of it:
DevRels are software engineers that connect developer-facing products with developers through technical content, communities, and feedback.
It’s not always clear when or why you need a DevRel in your org. Measuring their success is even more nebulous. To help with that - this post is a taxonomy of activities and artifacts DevRels produce. A service menu.
The Service Menu - What do they, like, do?
The following are concrete examples of projects you’re likely to see DevRels do. When reading the menu please note that, at a certain scale, the job refocuses to creating self-sustaining pipelines for these. E.g. creating content vs creating a content pipeline vs creating a community content spotlight.
Technical Content
Code samples — small, easy to run, working examples of the product in action.
Documentation — reference content, and descriptive guides.
Blog posts — to teach, or to broaden reach of the product. Blog posts are a more approachable version of documentation.
Videos, presentations, talks — for many, the best way to learn is through visual and audio content.
Community
Meetups and conferences — creating social and professional gatherings in which the product can be discovered, discussed and explained. These are growth engines for the community, and a place to identify and amplify positive members of the community.
Forums, Slack channels, subreddits, StackOverflow — engaging with and growing online community discussion and support channels.
Feedback
Talking to the development team that builds the product — to better understand design decisions, and provide insights from the product users.
Talking to the product users — developers that use the product are more likely to mention the product’s rough edges to a human than to a survey. Product users are often delighted to feel heard, and have a contact on the development team.
As the zeroth customer — DevRels are the first to test new features, to identify developer experience issues and bugs. Preemptively advocating for the end-users.
But why do they need to be software engineers?
A community manager, technical writer, and customer support representative could satisfy the above definition if I didn’t include the software engineer clause — but they probably aren’t users of the dev-facing product. A DevRel needs to do community, writing, and support work, but with a deeper understanding of the customer. If this is a software engineer facing product, then the DevRel needs software engineering experience to authentically empathize with the target audience. This empathy helps shape the product, and grow its audience.
Fluff and conclusion
I’ve also seen definitions which mention “educate, inspire and assist developers to build with X”. I like this. But while these goals are grander, they’re also a bit harder to concretize. Another few definitions I like are “a software engineer that can tell a story” or “a developer that answers the marketing team’s emails”.
That’s all. Hopefully this helps folks that are wondering what’s a DevRel and whether or not they need one. For a startup that’s building a product for developers - ideally one of the founders fulfills this role. In the future I’ll post an infographic to map the Venn diagram of responsibilities between devrels, tech writers, sales engineers and community managers. Subscribe if you might find that useful. Cheers.
References
My older blog post that quoted a more complicated definition for what’s a devrel
Loosely related image
