Developer Relations Thoughts

15 December 2022

For two decades, I've been involved in doing those things we now call "developer relations": those people within the company that connect to ("relate to") the developer community. I figured it was time to gather up some of the thoughts and ideas and suggestions into a single place.

Definitions

Developer Relations:

"That part of the company that engages with developers, both internal and external to the company, for the purpose of using that relationship for net gain to both sides. This can take the form of many things, but ultimately, (a) it's aimed at developers, (b) it's intended to facilitate greater positivity to one or both sides, and (c) it centers around developer activities of one form or another (that is, it could be technical, "human skill", or process, but it kinda-sorta has to be around the world of software development)." (Me)
"A process for nurturing mutually beneficial relationships between organisations and software developers. In other words, it’s a collection of strategies and tactics that help companies to work better together with software engineers. Exactly what developer relations teams do and why they do it depends on what their organisation needs." DeveloperRelations.com
"An umbrella term covering the strategies and tactics for building and nurturing a community of mutually beneficial relationships between organizations and developers (e.g., software developers) as the primary users, and often influencers on purchases, of a product. Developer Relations is a form of Platform Evangelism and the activities involved are sometimes referred to as a Developer Program or DevRel Program." Wikipedia

Rationales

Is yours a company that needs a DevRel team? Yes. It's really just that simple.

Are you not sure where the DevRel team fits in your organization?

Here's my answer. Short answer, it belongs as a top-level organization reporting in to the C-suite, right alongside Engineering, Sales, and Marketing.
Kim Maida has her own ideas on this, but in the end she seems to agree with the basic premise of my belief as well: "Developer Relations, as a key discipline, has earned its place at the leadership table."

Activities

The DevRel Activity Pattern Language provides a pattern language for all the activities a DevRel team can/might/will do during its existence. It grew out of several of the links below.

One of the first things you should read is James Ward's "Seven Artifacts of Developer Advocacy Projects"; in a nutshell, he writes:

"Each developer advocacy project ideally produces seven artifacts:
* Code Samples
* A Blog Post
* A Presentation and/or Video
* A Hands-On Workshop
* Broad Social Media Reach
* Product Feedback
* Enriched Community, Partner, or Customer Relationships

Personally, I think that's a good start on an ontology of DevRel activities, but I think it's not complete; I flesh out my own ontology here.

Kim Maida talks about "How to Drive Developer Growth and Engagement", as well as "How to Connect with your Developer Audience", which is a little more touchy-feely: "Act with integrity and empathy", "Build trust and respect", and "Inspire Loyalty and Confidence".

Metrics

Kim Maida weighs in on "How to Measure the Value of Developer Relations"

Mary Thengvall talks about "The Hidden Value Developer Relations Teams Provide", wherein she describes the value the DevRel team can bring, albeit without anything quantifiable that one can take away directly.

Tags: devrel