Refining the Definition of Developer Relations
What is DevRel, and what is it we actually do again?
Join the DZone community and get the full member experience.Join For Free
Over the last few months, a lot of conversations have come up in regards to DevRel being under the marketing department within an organizational structure. Which has (of course) made me revisit the question: “What is DevRel, and what do we actually do again?”
At the core of DevRel, somewhere, is the notion of advocacy to the developer. This advocacy comes with an implied notion that the advocates will bring solid technical details. These details then are brought to engineering and, in many cases, even contribute in some technical way to production advancement and development.
Does this always happen among advocates? The sad, honest answer is 'no,' but that’s for another blog entry.
At this point, let’s work with the understanding that developer relations advocates work from a technical point of view to bring product to developers in the community. They then take the experience gained from these interactions back to the engineering team to help with product development and, in turn, messaging. To be clear, I’ve broken this out again just for emphasis:
“Advocates work from a technical point of view to bring product knowledge to developers in a community. They then take the experience gained from these interactions back to the engineering team to help with product development and, in turn, messaging.”
I feel, even with that wordy definition, there are a few key words. For one, when I write 'community,' I'm of course referring to customers, but also non-customers, users of similar competing products, prospective customers, and overall anybody that has some interest in the product or related topics.
And when I write 'product', I also mean a much more inclusive definition than simply knowledge of one's own offering. In the case of the Spring framework, you would need more than just familiarity with Spring and its code base; you'd also need to know how that framework interacts with or does not interact with other products. To put this another way, you'd need the ability to dive deeper into peripheral technology around the full ecosystem of the Spring Framework in case questions were to come up (which they assuredly would).
If there’s any other part of that definition that doesn’t make sense, I’d be curious what you think. Is it a good definition? Does adding specific details around the words used help? If you’ve got thoughts on the matter, I’d love your thoughts, observations, ideas, and especially any opinions and hot takes!
Often a developer relations team works closely with curriculum development. Curriculum development, the creative and regimented process of teaching product knowledge and its related ecosystem is extremely important. Unless you’re selling an easy button, almost every practical product or service on the planet needs at least some educational material rolled into it. We all start with no knowledge on a topic at some point, and this team’s goal is to bring a new learner from zero knowledge to well versed in the best way possible.
Let’s take the curriculum team at DataStax, for example. They build material to provide a pathway for our workshops, all-day teaching sessions, the DataStax Academy material, and more. Sometimes the advocates jump in and help organize material, and sometimes engineers (and others) do as well. All of this gives the teachers, which are often us advocates, a road map to share from.
It is still extremely important that we also bring student feedback and ideas back to the curriculum team itself. As we teach, we find new ways to present information and new ways to help students try out and experiment with concepts and ideas. Thus, again, advocates are perfectly aligned with the task of communicating between two groups.
This is by no means the end of this topic, just a few observations. I’ll have more, but for now this is what I got done. I hope to contribute more in the coming days, weeks, months, and years to this topic. DevRel – good, effective, entertaining, and useful DevRel – is one of my keen interests in the industry. Give me a follow (blog address is in my profile), and I’ll have more of these DevRel lessons learned, observations, and ideas that I’d love to share with you all. And, as always, I'd love to get your feedback.
Published at DZone with permission of Adron Hall, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.