The DevRel reporting line debate is the wrong debate

I recently argued that DevRel is marketing. Several readers replied with a reasonable follow-up. If that's true, should DevRel always report to the CMO? The honest answer is more complicated than the original post made it sound.

The argument over whether DevRel should report to Engineering, Marketing, or the CEO is a proxy fight for a different and more important question. What is DevRel actually for at your company? The reporting line follows from the answer. Companies that pick a structure without answering the purpose question first will get the wrong outcome regardless of where they land on the org chart.

The 2024 DevRel Bridge survey found DevRel reporting lines split roughly four ways: 33% to Marketing, 21% to Product, 20% to Engineering, and 22% to the CEO or CTO. After more than two decades of this function existing, no consensus has formed. There's a reason for that.

The reporting line is downstream of the purpose

Twilio put DevRel inside Marketing and hit its developer acquisition goals. PostHog reports DevRel to the CEO and it works too. Both are correct because both companies defined the purpose before picking the structure.

DevRel can be a growth function: developer evangelism, content, top-of-funnel reach into developer audiences. That version belongs in Marketing, with Marketing's budget and Marketing's attribution model. DevRel can be a credibility function: technical depth, conference talks by people who actually built the product, real engineering presence in community spaces. That version may belong in Product or Engineering. DevRel can be a feedback function: a structured listening post that turns what developers say into product priorities. That version needs a real line to product decisions, wherever it sits.

Those are three different jobs. They share a job title. They hire from the same talent pool. They sometimes run on the same team. But the work is different, the metrics are different, and the manager who can support each one is different. The reporting question only has a real answer once the purpose question has one.

I covered the functional split in DevRel vs. developer marketing. The post you're reading is the org chart version of the same argument. You can't place a function correctly until you've defined what it does.

Why the debate goes in circles

The reason is that DevRel serves different purposes at different kinds of companies. At a developer-first company like Twilio, DevRel is a growth function and belongs in Marketing. At a developer-plus enterprise SaaS, DevRel is a credibility and feedback function and may belong in Product. It is the same job title doing two genuinely different jobs.

Twilio in its peak years ran DevRel inside Marketing as the top-of-funnel motion. It worked because Twilio's mandate for the team was developer acquisition, and Marketing's budget and attribution model matched that mandate. Nothing about that arrangement was inevitable. It was the right structure for the specific job DevRel was hired to do.

At a developer-plus company (an enterprise SaaS with a developer API where developers aren't the primary buyer), DevRel is more often a credibility and feedback function. The job is to make sure the API works for real practitioners, the documentation reflects production use cases, and the product team hears what developers are running into. That version may belong in Product.

The 2024 State of Developer Relations Report (stateofdeveloperrelations.com) found developer-first companies are roughly twice as likely to report DevRel directly to the CEO as developer-plus companies. The structure follows the go-to-market.

The "DevRel under Marketing equals MQL hell" argument that circulates on LinkedIn is correct but incomplete. Marketing as a parent is fine. Marketing measured only on lead generation is the actual failure mode. DevRel under a Marketing org that measures developer adoption, influence, and satisfaction works fine. DevRel under a Marketing org measured on MQLs breaks, because the team gets optimized toward gated content and email captures and loses every developer who matters. The reporting line is identical in both cases. What gets measured is what decides the outcome.

The two preconditions that matter more than the line

The measurement mandate and the feedback path to product do more to determine DevRel's success than any box on the org chart. A DevRel team with a clear measurement mandate tied to business outcomes and a real path to influence product decisions will succeed in any reporting structure. A team without both will struggle in all of them.

The first is the measurement mandate. DevRel needs a measurement framework that connects to outcomes the company values, without collapsing into vanity metrics or pure lead generation. The DevRel Bridge survey found 66% of programs identify awareness and adoption as primary objectives, and only 15.3% still track vanity traffic metrics. Those numbers show a field that has grown up.

It's also incomplete. Most teams have moved past page views without converging on what to measure instead. I covered the framework in how do you measure developer advocacy. The short version is that DevRel measurement should connect to long-cycle business outcomes through leading indicators the team controls, not through attribution models the team can't influence.

The second precondition is a feedback path to product. DevRel hears things product managers don't. A team that can convert what they hear into product roadmap influence is a strategic asset. A team that hears the same thing from a thousand developers and has no path to the product team ends up absorbing frustration it can never act on.

The path matters more than the reporting line. DevRel under Marketing with a strong cross-functional product feedback process beats DevRel under Engineering with no feedback loop. The org chart is the visible structure. The feedback path is the hidden structure that determines whether the function actually works.

When does DevRel reporting to the CEO actually work?

The honest answer is at small developer-first companies, where the CEO is genuinely engaged in the community and the team is small enough to manage personally. PostHog runs this model effectively. At that scale, a CEO line gives DevRel cross-functional license no single business unit can match. At larger companies, the same structure tends to isolate the function and get it cut first.

At larger companies, the political isolation plays out predictably. The team has no budget of its own inside a business unit, few allies when planning cycles come around, and nobody with a real incentive to defend it once headcount tightens. The CEO is rarely the right manager for a specialized function at scale, even an important one. The exception is a company where developer adoption is the strategic crown jewel and the CEO has decided to manage it personally. That's a real model, just not a default one.

The middle path more companies are quietly running is something like what GitLab does. A VP of Developer Relations and Community reports to the CMO, with an explicit cross-functional charter into Product. Permit.io recently promoted a leader to "VP Marketing, DevRel Growth," collapsing the two functions in a job title at a stage where the company has decided they are the same job. Both arrangements work because the structure was chosen after the purpose was clear, not before. For the team-building side of this, how to build a DevRel team and what kind of developer advocate do you need cover the hiring decisions that follow once the function is scoped.

What should you ask if you're interviewing for DevRel roles?

One question I get a lot from folks in my network who are on the job hunt is whether a particular role is right for them if DevRel is reporting into marketing instead of product or engineering. The real answer is to go back to the first principles we've discussed in this post.

• What is DevRel for at this company, specifically? Growth, credibility, feedback, or some explicit mix?
• Which business unit can give DevRel a measurement mandate that matches that purpose?
• What does the feedback path to product look like, and is it real or aspirational?

You could report to Support or Customer Success, but if the answers to those questions satisfy you, you will probably be fine.

What to do with this

If you're deciding where to put DevRel, run the same three questions from the interviewing section above, in order, this time from the hiring side of the table. The reporting line that satisfies all three is the right one. Skip any question and you're picking structure before purpose.

Start with purpose, and get it on paper. If three executives have three different answers about what DevRel is for, the reporting decision is premature.

Then find the business unit that can give DevRel a measurement mandate to match that purpose. The unit that can hold DevRel accountable to the right outcomes is the one that can also defend it. A Marketing org measured on developer adoption can be home to a growth-oriented DevRel. A Product org with a strong technical credibility mandate can be home to a depth-oriented DevRel. The mandate is what makes the line work, not the line itself.

Last, pressure-test the feedback path to product. If the answer is "DevRel will share insights in a quarterly review," the feedback path is aspirational and the function will frustrate everyone. The path needs to be a named process, owned by a named person, with cadence and a decision-making forum.

It'll look different at different companies, and that's the point. The companies arguing about org charts on LinkedIn are arguing about the visible artifact. The companies that get DevRel right are working on the questions underneath.