DevRel is marketing. Stop pretending otherwise.

I know this will make some people angry. Good. We need to have this conversation.

Developer relations is marketing. It is a specialized, technical, community-oriented form of marketing. But it is marketing. The refusal to accept this has caused more damage to DevRel careers and DevRel programs than any round of layoffs.

When Pedram Navid wrote about his experience running DevRel at Dagster, he said the quiet part out loud: accepting that DevRel is marketing made everything easier. The Hacker News comments split 50/50. Half the community agreed. The other half acted like he had committed treason.

That split is the problem.

What do we actually mean by "marketing"?

When we say marketing, we mean the function that makes a market aware of your product and moves them toward adoption. The resistance to the word comes from a legitimate place. Developers hate bad marketing. They hate spam. They hate gated whitepapers and "request a demo" buttons and email sequences that start three minutes after you sign up for a free tier. When DevRel people hear "you are marketing," they hear "you are that."

But that is not what marketing is. Marketing is the function that makes a market aware of your product and moves them toward adoption. That is it. How you do it matters enormously. Whether you do it with integrity or with spam is a choice, not a definition.

DevRel does marketing by building relationships, creating educational content, speaking at conferences, answering questions in Discord, and providing honest feedback to the product team. That is marketing. Specifically, it is the kind of marketing that works best with developers. It is marketing done with a Help First mindset.

Calling it something else does not change what it is. It just makes it harder to fund, measure, and defend.

What damage does pretending DevRel is not marketing cause?

Pretending DevRel is not marketing causes three things to break: budgets, measurement, and careers.

Budgets. Marketing departments have budgets. Engineering departments have headcount for building product, not for building community. When DevRel sits under engineering and refuses to be called marketing, it competes for budget against features, infrastructure, and hiring. It loses. Every time. DevRel teams need to articulate their contribution in business terms.

Measurement. If you are not marketing, what are you? "Building community" is not a business function. "Earning developer trust" is not a line item. The teams that refuse to connect their work to business outcomes end up reporting vanity metrics: Discord members, GitHub stars, conference talks delivered. Those numbers look nice in a slide deck. They do not survive a budget review. I wrote about this in how to measure developer advocacy.

Careers. DevRel professionals who position themselves as "not marketing" close off the most natural career paths available to them. VP of Marketing, CMO, Head of Growth: these roles require marketing experience. If you spent eight years insisting you were not doing marketing, good luck making the case that you are qualified to lead it.

Should DevRel have revenue KPIs?

DevRel does not need a revenue quota, but every function in a company exists to help the company find customers and make money. There is a popular argument that goes like this: "DevRel should not have a KPI for revenue. Once you start driving revenue, developers become more hesitant to participate."

I understand the sentiment. I have spent decades building trust with developer communities, and I know how fragile that trust can be. But this argument has a problem. It is too precious.

Finance. Engineering. Support. HR. Product. Nobody in those departments says "we should not have to think about revenue." They understand that their work serves the broader goal, even when their day-to-day metrics are not denominated in dollars.

Marketing does not carry a revenue quota. Sales does. But marketing exists to create the conditions for sales to succeed. DevRel exists to create the conditions for marketing to succeed. The chain is real. Pretending it is not makes you feel pure, but it also makes you expendable.

You can build trust with developers and help the company grow. Those are not opposites. The best DevRel programs I have run did both. The advocates earned developer trust by being genuinely helpful. The company earned revenue because trusted products get adopted. Splitting hairs about whether that counts as "driving revenue" is an exercise in self-preservation that does not actually preserve anything.

If you are too precious about revenue, you are not doing everything it takes to make sure the company succeeds. And if the company does not succeed, your DevRel program dies anyway.

Will reporting to marketing corrupt DevRel?

Reporting to marketing will not corrupt DevRel if the DevRel leader has a seat at the table when marketing decisions get made. The fear is that marketing leadership will force advocates to write lead-gen content, gate their tutorials behind email forms, and turn every conference talk into a product pitch. That fear is not unfounded. Bad marketing leaders do that. I have seen it happen.

But the solution is not to refuse the label. The solution is to be inside the room when marketing decisions get made. If DevRel sits outside of marketing, it has no voice in how developers are marketed to. It can only complain after the fact.

Inside marketing, a strong DevRel leader can shape the content strategy, protect the developer experience, and ensure that the company's developer-facing work maintains integrity. Outside marketing, a DevRel leader is a cost center waiting to be cut.

What changes when DevRel accepts it is marketing?

When DevRel accepts it is marketing, several things get easier: budgets, measurement, career paths, and cross-functional collaboration.

You get a budget. Marketing budgets are real. They are planned annually. They have line items for events, content, community, and headcount. DevRel programs under marketing get funded like marketing programs.

You get measured properly. Instead of vanity metrics, you measure things that matter: developer awareness, content engagement, community health, product feedback quality, and influence on pipeline. Not revenue attribution. Influence. There is a difference, and any competent marketing leader understands it. The framework I described in measuring developer marketing ROI applies directly.

You get career paths. A DevRel leader under marketing can grow into a VP of Marketing or a CMO. A DevRel leader under engineering can grow into... a more senior DevRel leader. The ceiling is lower and the path is narrower.

You get allies. Marketing teams include content strategists, demand generation specialists, product marketers, and brand managers. These people have skills that complement DevRel. When you work alongside them, your programs get better. When you sit in a separate org, you reinvent wheels that marketing already has.

What stays the same when DevRel reports to marketing?

The work stays the same: advocates still write tutorials, speak at conferences, answer community questions, and provide product feedback. The content is still educational, not promotional. The voice is still honest, not salesy. The relationship with the developer community is still built on trust.

The only thing that changes is the frame. You are not a mysterious function that cannot be measured or categorized. You are a marketing team that specializes in earning developer trust through technical education and community engagement. That is a clear, defensible, fundable position.

DevRel professionals often worry that accepting the marketing label will dilute what makes them special. The opposite is true. Naming what you do clearly makes it easier to explain, easier to fund, and easier to protect.

Why did DevRel layoffs hit some teams harder than others?

DevRel layoffs hit hardest at companies where the team could not articulate its business contribution. The teams that survived were the ones that could show how their work influenced adoption, retention, and revenue. Not because they were mercenary. Because they were honest about what their work accomplished.

I have built DevRel teams and I have run marketing organizations. The best DevRel work I have seen always happened inside marketing, with a leader who understood the developer audience and protected the team's integrity. The worst DevRel work I have seen happened in orgs where nobody could explain why the function existed.

DevRel is marketing. Say it out loud. It will not kill you. It might save your program.