Dev Rel = Developer Relations

First, I've got a few observations that I've made in the last 6 months since joining DataStax (which I joined ~10 months ago) about a number of things. In this post I've detailed some of the thoughts, observations, and ideas I have about many of the aspects, roles, divisions, organizational structure, and related elements of DevRel.

Refining the Definition of Developer Relations

Over the last few months a lot of moments and conversations have come up in regards to DevRel being under the marketing department within an organizational structure. Which has made me revisit the question of, "what is DevRel and what do we do again?" Just asking that question in a free form and open ended way brings up a number of answers and thoughts around what various DevRel teams and even groups within a DevRel team may have as a mission. Let's break some of this out and just think through the definition. Some of the other groups that DevRel either includes or works very closely with I'll include too.

Developer Advocates

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 simple definition that Developer Relation's Advocates work from a technical point of view to bring product and practice to developers in the community. Then take the experience gained from those interactions and learning what the community of developers is working on back to engineering and product to help in development of product 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 and practice to developers in the community. Then take the experience gained from those interactions and learning what the community of developers is working on back to engineering and product to help in development of product and in turn, messaging."

I feel, even with that wordy definition there are a few key words. For one, when I write community in this definition I have a specific and inclusive context in which I use the word. It includes customers, but also very specifically includes non-customers, users of similar competing products, prospective customers, and overall anybody that has some interest in the product or related topics of the product. In addition to this, product needs clearly scoped in this definition. Product means, for example in the case of the Spring Framework. Product wouldn't stop at the finite focus on just Spring and it's code base and built framework product, it would also include how that framework interacts with or does not interact with other products. It would include a need for at least a passing familiarity, and ability to dive in deeper if questions come up, into peripheral technology around the full ecosystem of the Spring Framework.

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!

Curriculum

Curriculum Mission: How to Effectively Learn and Share Product Knowledge

Often a developer relations team either includes, might be part of, or otherwise organized closely with curriculum development. Curriculum development, the creative and regimented process of determine how to present material to learn and teach about the product and product 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. Advocates or dedicated teachers may be tasked with providing this material, sometimes it's organized a slightly different way, but whatever the case it's extremely important to understand what is happening with curriculum.

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, sometimes engineers, and others. They do a solid job, and I'm extremely thankful for their support. It gives the teachers, which in many cases it's us advocates, a path to go without the overhead of determining that path.

However...

It is still extremely important, just like with the advocates' roles of bringing community feedback to engineering in an effective way, we need to bring student feedback and ideas to increase the curriculum effectiveness back to the curriculum team itself. As we teach, and learn at the same time, 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. Ensuring that this communication is effective as well as curriculum material is one of the many core skills for developer advocates.

In the next post on this topic of refining, defining, and learning about the best way for DevRel to operate here's some topic thoughts:

• Twitch Streaming - How's it work and what's it give me? What's it give the prospective customer, community, and related thoughts.
• Github - What's the most effective way to use Github from a DevRel perspective? Obviously code goes here, but how else - should we use wikis heavily, build pages with Github Pages to provide additional information, should it be individual domain names for repos, what other things to ask? So many questions, again, a space that doesn't seem to be explored from a DevRel perspective to often.
• Twitter - This seems like the central place for many minds to come together, collide, and cause disruption in positive and negative ways. What are some ways to get the most out of Twitter in DevRel, and as Twitter becomes a standard, basic, household utility of sorts - what value does it still bring or does it?
• LinkedIn - It's a swamp of overzealous and rude recruiters as much as it is a great place to find a job, connect with others, and discuss topics with others. How does one get value or add value to it?
• StackOverflow, Hacker News, and Other Mediums - What others sources are good for messaging, discussions, learning, and related efforts for people in the community that DevRel wants to reach out to?
• Value for DevRel - DevRel provides a lot of value to the community and to prospective customers of a product. But what provides value for us? That's a question that rarely gets approached let alone answered.

I hope to get to these posts, or maybe others will write a thing or three about these? Either way, if you write a post let me know, if you'd like me to write about a specific topic also let me know. I'll tackle it ASAP or we can discuss whatever comes up in this realm.

Summary

This is by no means the end of this topic, just a few observations and all. I'll have more, but for now this is what I got done and 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 industry. Give me a follow, and I'll have more of these DevRel lessons learned, observations, and ideas that I'd love to share with you all and also get your feedback on.

Cheers!

I'm on Twitter @Adron and Twitch @adronhall listening to metal all the time and coding, writing about coding, learning, and teaching all sorts of topics from database tech to coding chops. Thanks for reading!