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?”

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 public-domain.zorger.com