DEV Community

Cover image for Moving Developer Relations Forward
Jeremy Meiss
Jeremy Meiss

Posted on • Updated on • Originally published at

Moving Developer Relations Forward

Author's Note: What follows is Part 1 of a (currently) 6 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

One of the most common topics of conversation, or argument, over the last 5 years or so (maybe longer, but anything prior to the COVID-19 lockdowns is a bit of a blur) in the tech community is over a statement: “DevRel is (or is not) X”. The algebraic formula solving for X usually leads to any of the following:

  • Sales
  • Marketing
  • Cool travel
  • Lollipops and rainbows
  • Easy
  • Corporate shills
  • ${any other combination of words}

And it has gotten really, (to put it plainly) fucking old. Conferences around DevRel and Community tend to have talks which are 101-level, espousing what DevRel is/isn’t in some weird formula, while providing very little in the way of actionable steps or framework to be applied. And do you know why? Because it’s really (here it is again in plain terms) fucking hard to put together a framework or flowchart for a discipline that varies wildly depending on factors like:

  1. Is your company in early-stage or late-stage funding rounds?
  2. Does your company have a Product, and is there Market fit?
  3. Who is your customer? Startups, SMB, Consumers, Enterprise, etc.?

As well as more that I’m not even capturing here.

So with all of the variables at play here, how is DevRel supposed to prove its value to the Business? How is a DevRel team supposed to avoid the two dreaded questions:

  1. “What is it you do here?”
  2. “What is the ROI of that?”

What is it you do here?

Before I lead you too far down the rabbit hole, let’s start with some basics , like “What is DevRel?” in the next post in the series, which you can find in the below widget.

Cover image via

Top comments (7)

andypiper profile image
Andy Piper


You have my attention.

jerdog profile image
Jeremy Meiss

Hey @andypiper - did you get a chance to review the full series? I have another 1 or 2 coming, but would love your input so far!

kimmcmahon profile image
Kim McMahon

Great post and I'm looking forward to the next and next and next!

DevRel and Community are hard because (IMHO) people want the simple answer to building community. And there is no simple answer or one approach. You have to look where you are, what your organization expects, and what you and your team (if you have one) can get done that will have an impact your organization finds valuable.

It's the impact your organization finds valuable is what keeps you ... ... employed.

jerdog profile image
Jeremy Meiss

Absolutely. Some upcoming topics are:

  • Different activities (and KPIs) for the stages you're in
  • Case study that shaped all of this for me
  • Probably something, something, something else
michaeltharrington profile image
Michael Tharrington

This is a seriously dope series! Good share(s) Jeremy!

raystepcode profile image

When I saw the title, I thought you'd have some thoughts on moving an existing DevRel program forward rather than starting with the basics. My experience is probably different as I worked in this field at only large companies (Microsoft, Cisco) - and the challenge is how to grow the audience, do something new and engaging, etc. But, hey all information is good - so I'll follow along and see what else you might have in store for us!

jerdog profile image
Jeremy Meiss

Just now seeing this comment. Apologize for the late reply.
I'm guessing you didn't look at the rest of the posts? There are 5 (currently) posts, with more on the way.
If you did, would love to hear your thoughts on the challenges you experience? Let's start the broader conversation!