DevRel is marketing. Stop pretending otherwise.

I have spent my entire career running developer marketing and developer relations teams. In that time, it has never been a question to me that developer relations is marketing. Sometimes developer relations professionals draw a hard line between marketing, which they see as fluffy ads, and developer relations, which they see as writing code. But today, as we have learned in some of my previous posts, the distinction between marketers who write code and marketers who don't write code has largely evaporated. The only marketers left are those who write code.

So what then becomes of developer relations? Developer relations needs to learn marketing, if it hasn't already.

The debate that never ends

Personally, I think it's a silly debate. It's a silly debate because everyone at the company works in marketing. If you wear the company t-shirt and you go to a movie, and someone comes up to you and asks about your product or is enthusiastic about your product, you're not going to turn your back on them and walk away. In that instant, you're representing the company and you're marketing. It doesn't matter if your day job is in the finance function, the engineering function, the human resources function. In that instant, in that moment, you're doing marketing.

Likewise, when developer relations professionals get on stage and talk about the product, or they get online and do a live stream about the product, they're doing marketing. They are representing the positioning and the messaging of the product. They are explaining:

• who the product is for
• what the product does
• what the product does not do
• how easy it is to get started with the product

What is that, if not marketing?

Marketing is not ads. Marketing is communication. Pure and simple.

What pretending costs you

The problem with holding that line is that if someone in the organization asks what you do and you say that you build community, building community is not a business function. It doesn't survive a budget review. In this day and age, we know that if you are not accretive to the bottom line, you're on the chopping block.

Every function in developer relations needs to be measurable. Every function in developer relations needs to be customer-facing and exemplary in communication, and every function in developer relations needs to be hand in glove with marketing. You are on message all the time.

And the fastest way for a developer relations team to become irrelevant is for a developer relations team to pretend that their metrics don't matter. The very first chapter of my book is all about measuring developer relations and developer marketing. It's that way for a reason. I have been through layoffs. I have been through cyclical changes in the broader tech industry. I've seen it all. Through it all, the thing that I have always come back to is that I need to position myself so that it is inherently obvious that the value I add is beneficial to the company's bottom line.

The two things to focus on

There are two things that you need to focus on. The first thing is measuring what matters.

Measure the feedback loop: the bug reports your team filed that engineering accepted, and the feature requests that actually reached the roadmap. Measure content and events with tracking codes on every inbound link you control, so you can see which activity brought people to the product and which channel deserves more of your time. Be careful with community, because the moment you bolt a sales number onto community time, you start optimizing for the number instead of for the people. Then put all of it on a dashboard everyone can read. One of my core management principles is to eliminate every form of information asymmetry in an organization, and a metrics dashboard that only you can see is information asymmetry.

The second thing is becoming an invaluable resource to the product team. I can't tell you how many times I see developer relations engineers who are downstream of the product line. What that means is they take what the product team ships, and then they see it as their job to be the mouthpiece for the product.

That is selling yourself short.

The thing about developer relations is that you see the product left to right. What I mean is that you see every aspect of it and how every customer uses it in multiple ways. Most engineers only see their portion, but you, as a developer relations manager, see all of it. You see the onboarding, you see the warts that customers need to work around, you see the magic, and then you see the parts that just sit in maintenance mode and make people happy all day.

Because of this unique perspective in the organization (the only people who also have this kind of perspective are support engineers and customer success managers) you are able to provide feedback to the product team that no one else can. You're able to provide feedback that is rooted in actual customer scenarios. That puts you in the driver's seat of the product.

Instead of thinking downstream of product, think upstream. Get yourself involved in how the product is built and who the product is for, because ideally, if you're doing your job, you know it better than anyone else in the organization.

What being upstream of product naturally means

When you're upstream of the product being built, you are adopting a more strategic role. That role requires understanding the market, the total addressable market, the go-to-market motion, and all of the other aspects of sales and marketing.

If you were to advocate for a trifling feature, one that doesn't add much value to the product, you would be betraying that you have not thought strategically enough about the business. The business needs you to understand the sales levers so that the features you recommend are technical wonders that also unlock pipeline. And now you are thinking like a marketer with a developer relations mindset tacked onto it. That sets you up for career success.