DevRel is about what's good for them

This post is part of a series on building developer relations, adapted from a book chapter I wrote. You can find all the posts once published in the series here.

I've worked in Developer Relations for over 25 years. There, I said it: I'm old.

I tell you what else is old: The question what DevRel actually is. Sales? Marketing? Something else entirely?

A good friend of mine once put it better than I ever could:

"Developer Sales and Developer Marketing is concerned with what's good for us. Developer Relations leads with what is good for them."

I've carried that sentence around for years, because it does something most definitions of developer relations fail to do: it draws a line you can actually stand on.

When I started out at Microsoft's version of DevRel, roughly 25 years ago, the thing that made our little team work wasn't our slide decks or our demo skills. It was two assets, and only two: we knew the ecosystem, and the ecosystem trusted us. We didn't show up with a sales agenda. We brought gifts and knowledge, and we were known to participate. That's it. That was the whole magic trick.

Trust is the currency developer relations deals in. And trust is expensive to earn and cheap to lose. You build it by showing up, by demonstrating real interest, and by supporting people when they actually need support - not when it's convenient for your quarter.

Here's where it gets uncomfortable for a lot of organizations: this is fundamentally long-term work, and it sits awkwardly next to the typical business demand for short-term ROI. If you ask "what did developer relations sell this quarter?", you've already misunderstood the job. The value shows up down the road, in self-initiated activity, in a community that contributes without being asked, in feedback that saves your product team from an expensive mistake.

So what does DevRel uniquely do, the stuff that no other team in the company will do for you? In my experience it comes down to three things:

• Supporting communities of learning and practice
• Participating in the developer ecosystem as a genuine member, not a vendor
• "Growing the cake" - supporting the larger ecosystem, sometimes even in ways that benefit competitors

That last one tends to raise eyebrows. Why would you build a tool that helps the whole ecosystem, competitors included? Because developers expect a degree of flexibility and connectivity, and because a healthy ecosystem grows as a whole. Instead of just optimizing your slice you're making the whole thing bigger.

This is also why developer relations keeps getting confused with marketing, and why the confusion is so damaging. Good marketing is about close relationships with customers, and yes, developers can be framed as customers. But marketing is ultimately about products and about positioning them toward a customer base. Developer relations is about co-creating with a community of volunteers - and the moment you're co-creating, the scope becomes much broader than any product. Many of the things we make don't sell anything at all. Sometimes it isn't even about a product but about an entire technology strand.

If you take one idea away from this whole series, let it be this one. Every structural decision, every metric, every hire gets easier once you accept that developer relations exists to be good for developers - and that the return on that comes back to you later, indirectly, and larger than you expected.

The rest is just working out how to do that at scale.