DevRel Is Becoming Developer GTM. No — It Always Was.

There’s a take making the rounds right now: “DevRel is shifting into developer GTM.”

No, it’s not. It always was.

Your CFO didn’t approve that headcount for funsies. Good DevRel has always been marketing and selling through education and inspiration. That’s the whole job. That’s why companies fund it.

What’s actually changing is the timeline leadership is willing to wait on.

The work didn’t change. The patience did.

Stressed companies — the ones worried about revenue, runway, or missing a market window — want this-quarter impact. They want a DevRel hire to move a number you can point to before the next board deck.

Healthier companies have the patience to wait for larger impact next year, or the year after. Pipeline takes time. Trust takes time. A developer audience is a compounding asset, not a campaign.

That’s the whole shift. Leadership is just saying the quiet part out loud.

When the macro tightens, the runway shortens, and the question “how does this ladder to revenue?” goes from a polite annual review topic to a Monday morning email. The activities don’t have to change. The narrative around them does.

Every DevRel activity ladders to the business

If you can’t trace your work to one of these, somebody’s doing it wrong. Probably the person who hired you. Possibly you.

Content (blog posts, talks, videos, podcasts)

• Top-of-funnel SEO and brand → leads
• Inspiration → developers pulling teammates in
• Trust → shorter sales cycles when they finally talk to an AE

Code (libraries, samples, SDKs, integrations, “skills”)

• Developer productivity → faster ramp → higher ACV at the same price point
• SEO surface area (sample repos rank, integrations show up in partner directories) → leads
• A new wedge into LLM-mediated discovery, where the agent is the developer

Community (Slack, Discord, forums, events, user groups)

• Net revenue retention through more committed users
• Stronger brand and word-of-mouth → cheaper CAC
• Free customer support that’s better than your paid customer support

Docs

• Faster ramp → faster time-to-value → revenue expansion
• Feature adoption → NRR
• Lower support cost per customer → better gross margin

That’s the entire scoreboard: faster ramping, expansion revenue, higher retention, lower CAC. Pick one. Probably more than one. If a DevRel activity can’t be traced to any of them, you should be able to explain why anyway — and “developer love” is not the answer your CFO is grading.

“But what about community management? Or technical evangelism?”

The common pushback: community management is really field marketing, advocacy and education are really technical marketing, and the new “build for agents” work is a different beast entirely. Every company is different. Every role mutates with the company stage and the industry.

All true. But the test isn’t what bucket does the role belong in. The test is does it ladder to a business goal a CFO would fund?

Take community travel. The lazy version is “show up, give the talk, post the photos, fly home.” The version that actually pays for itself is lining up two to five customer meetings with the AEs in that city while you’re already there. Influence a buying decision. Unblock an expansion deal. Inspire a champion to escalate internally.

That’s not field marketing. That’s not “community.” That’s level-2 sales engineering — the company brings in the big guns to influence a deal, and the DevRel person is the big guns. The next level up is product/eng execs, the C-suite, or founders.

If you’re doing community travel and not lining up customer meetings, you’re leaving money on the table. If you’re doing customer meetings and not telling your CFO, you’re leaving budget on the table.

The three activities of any company

In our world (B2B-ish software, mostly), every company does exactly three things:

1. Build the product
2. Take that product to market
3. Run the company internally (ops, finance, HR)

Some DevRel work touches product — feedback loops, design partnerships, pre-release shaping. Real, valuable, and rarely the primary reason a company hires a DevRel team.

Almost everything else is GTM. And honestly, you can argue everything is GTM, because the only reason a company builds a product is to take it to a market. Leadership has a fiduciary duty to maximize returns to shareholders. If your work doesn’t show up somewhere on the path between “build” and “money in the bank,” it’s a hobby the company is paying for.

That isn’t cynical. It’s the deal.

What this means if you’re a DevRel IC

• Know which of the four levers (revenue, ramp/NRR, CAC) your current work moves. If you can’t name it, your manager probably can’t either, and you’re both exposed.
• Bring receipts to your reviews. “Influenced X new logos, Y in expansion, Z in pipeline” beats “wrote 12 blog posts and spoke at 4 conferences” every time, even if the blog posts and talks are how you got there.
• Make peace with attribution being messy. It is messy. Do it anyway. Bad attribution is better than no attribution, and the spreadsheet will sharpen over time.
• When the macro tightens, get closer to revenue, not further from it. The instinct to retreat into “pure community work” when budgets get cut is exactly backwards.

What this means if you lead a DevRel team

• Stop pretending the GTM frame is new. It’s not new — your patience is just shorter than it used to be. Be honest with the team about that.
• Defend the long-timeline activities by tying them to long-timeline metrics (NRR, brand share-of-voice, organic pipeline a year out). Don’t try to defend a podcast on a quarterly attribution model.
• Make sure every IC has at least one this-quarter lever and at least one next-year lever. People who only do long-cycle work get cut first.
• Build the muscle of bringing your team into customer conversations. The DevRel folks moving real revenue aren’t doing it by accident — they have a system, and they tell their CFO about it.

So what am I missing?

Genuinely — what am I missing?

I keep hearing “DevRel is shifting.” I keep looking at the work and seeing the same four things ladder to the same four metrics they always did. The pressure changed. The label changed. The job didn’t.

If you think the job actually changed, I want to hear why. Hit me up.

Thanks to Adi Polak for the chat and inspiration to write this post.