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:

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?

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