Developer Relations vs. Developer Marketing: different names for the same thing?

My first brush with Developer Relations came in 2018, when I launched a newsletter called CFP Land. I was speaking at technical conferences regularly, so I built the email list to help speakers like me find calls for proposals.

After meeting some of my 2,500 subscribers, I noticed a good chunk of them worked in Developer Relations or Developer Marketing.

As a software engineer, I knew companies wanted to reach people like me, think web hosting, software testing, and continuous integration tools. What I didn't get was the nuance between their many job titles, at least not until I worked my way into their circle.

After building Draft.dev and working with hundreds of Developer Relations and Marketing professionals, I can explain these roles much better today. In this piece I want to offer some perspective, and maybe muddy the waters a little for those of you newer to the field.

Broadly, two kinds of companies sell to developers: "developer first" and "developer plus" businesses.

James Parton defines the two terms well, but in short, "developer first" companies sell software built for software development, like IDEs, specialized web hosting, or security tools. Some of them have other stakeholders too, but their go-to-market strategy is built around selling to technical people first.

"Developer plus" companies sell mostly to non-technical stakeholders, but parts of their product reach developers. Picture a bank that also offers an API. Most customers manage accounts through the bank's interface, while a few power users wire the bank's services into their own software through that API.

The distinction matters for context, but either way these companies want to reach developers, make them aware of their products, and help them buy.

With over 27 million software developers worldwide and demand still climbing, no wonder companies are racing to build software for them. Developer-facing tools are inherently sticky. They reach into low-level functions of the business and become essential for shipping updates and keeping users' trust.

Both roles are a piece of the puzzle in reaching developers, and done right, they complement each other.

Developers are a notoriously hard market to reach. As a software developer I hated the constant cold emails and LinkedIn messages from recruiters. My friends and I joked about how clueless these recruiters were, and we all knew the firms with the worst reputations.

To avoid landing in the same spam folder as those recruiters, companies selling to developers need a different approach. I've said it before: the key to reaching developers is building trust. One of the best ways to build it is by creating genuinely helpful content and having real conversations with your audience.

This is where Developer Relations usually enters the picture.

Much like a public relations pro works with community members, press, and social media, Developer Relations people listen to developers and act as a go-between for users and the company's product and marketing teams.

That means Developer Relations, often shortened to DevRel, needs a wide range of skills. As Ivan Burazin, CEO and co-founder at Daytona, told me last year:

Many DevRel people have a technical background, which helps them empathize with users and advocate for their needs, but not always. As you'll see, every company defines and uses these titles differently.

With DevRels acting as the interface between customers and the company, you might wonder where Developer Marketing fits.

Marketing teams need close contact with DevRel teams, but they tend to be more proactive than reactive.

DevRels join the community and listen for feedback. Dev Marketers push out product announcements, plan content campaigns, and create material that helps developers see how the product fits their workflow or existing stack.

The difference between the two is often so subtle that the roles overlap. Burazin pointed this out when he described the challenge of DevRel:

That said, Developer Marketers more often come from a non-technical background than DevRels do. Dev Marketers tend to lean on marketing skills like SEO, ads, writing, and gated assets, working alongside technical people like engineers or DevRel teams to run campaigns.

As I've hinted, the lines between Developer Marketing and Developer Relations are fluid and vary company to company. I've met Developer Marketers who used to be engineers and DevRels who have never written a line of code, and both do just fine.

Some companies use entirely different titles too, like Developer Advocate or Developer Evangelist. It gets confusing for people new to the field, or for smaller companies still figuring out which roles they need and when.

The reporting structure varies a lot as well. In some companies DevRel sits under sales, in others under product, in others under marketing, and in some it reports straight to the CEO.

These divisions can look arbitrary, but done poorly they create real conflicts of interest. A DevRel team that reports to sales, for example, often struggles to justify time on work that doesn't immediately produce qualified leads or sales calls.

Because the two roles are so similar and so often overlap, founders regularly ask me to help them figure out which one they need first. The honest answer is "it depends", but here is my logic.

If your main buyer is a software developer, you need dedicated Developer Marketing before you need a full-time Developer Relations person.

The reason is simple. Without enough interested users to engage, a DevRel team struggles to add value and ends up doing marketing tasks anyway. On top of that, founders should be talking directly to customers in the early days, and they make the first de facto DevRel people in the company.

DevRels usually arrive once the business has enough users that founders can't spend much time with them directly, and the team can justify its cost. It won't bring in marketing-qualified leads right away, but it will steer the product and marketing in the right long-term direction.

In companies with a developer offering that sell mainly to another business stakeholder, it makes more sense to start with Developer Relations.

Most developer plus companies already have marketing channels for their products, so they mainly need better support and awareness for the developer side. DevRel is great for that, because it can build on relationships with existing customers to gather feedback and push the product forward.

Developer plus companies usually don't build dedicated Developer Marketing teams until much later, when they open the developer side up as a standalone offering.

Developer Relations and Developer Marketing both matter for companies trying to reach developers, but the line between them is subtle and often blurred. Many DevRels I've met struggle because they're expected to do marketing, and many Developer Marketers struggle because they lack the technical depth or time to do a DevRel's job.

Every organization defines the two titles differently. What matters most is a clear understanding of where each should focus. If you have your own working definitions, or you think I've got it wrong, I'd like to hear from you. Find me on X to keep the conversation going.