The Wrong Way to Build DevRel at Series A

Jul 29, 2026

Jono Bacon

Reading Time: 13 min

A Series A founder is eight months past closing the deal, has just hired their fourth Developer Advocate. Fourth. The company has one person writing docs part-time, no activation instrumentation to speak of, and a homepage that reads like it was translated from enterprise procurement Sanskrit. But by God, they have four Developer Advocates. Two of them are “running community.” The other two are “doing content.” Nobody can tell you what happens when a developer signs up, because nobody has actually measured it. But everyone has a Notion doc.

This, I’m afraid, is what DevRel for Series A looks like when the order is wrong. At Stateshift we see versions of this more often than we’d like, and it’s the single most expensive DevRel mistake a company can make.

The short answer

A Series A DevRel team, done properly, is three to four people, not eight. It has one lead who reports to the CEO or the CTO rather than getting parked under a VP of Marketing who last spoke to a developer in 2014. It’s paired with an engineer who actually writes code, and a content or community operator who can ship regularly. It owns Activation as its primary job: docs, quickstart, developer onboarding, and the funnel instrumentation to measure whether any of it is working. It has a defined budget, a named reporting line, and a small number of metrics tied to revenue-influenced pipeline and activation rate. It does not have six evangelists doing conference talks about “the future of developer experience” while the docs still 404 on the API reference page. At Stateshift, this is the pattern we see land the plane at Series A, and the one companies limp back to after trying every other configuration first.

Seed DevRel was rock and roll. Series A is where the grown-ups arrive

Seed-stage DevRel is a beautiful thing. It’s five people in a room. It’s the founder writing the first blog post at midnight because it’s their company and if the blog post is rubbish it’s their fault. Everybody is doing everything. The “community manager” is also the product manager, also the person answering support tickets on Discord, also the person occasionally getting on a plane to a meetup because someone offered them a slot. There’s no strategy deck. There’s no dashboard. There’s a shared belief that this thing might actually work, and there’s the visible fact that a few developers keep coming back and building things, which is the only real proof of life that matters at that stage.

Series A is where that changes. Not because founders suddenly become dishonest, but because the pressure of a priced round changes what “good enough” means. Your investors would like predictable growth now, please. Your product has enough surface area that “just talk to Jono in Discord” no longer scales. Your headcount roughly doubles. And crucially, other people in the company, sales, marketing, product, now have their own goals, their own metrics, and their own opinions about what DevRel is for. That last one is the killer. That’s the one nobody warns you about.

The rock-and-roll era is over. Now you have to build something someone else can operate.

Building the right sequence in DevRel for Series A

Here is the mistake I’ve watched more times than I can count. A newly-funded Series A founder decides they need “a real DevRel function,” and their very first hire is a Director of Developer Relations. Big title, big salary, big LinkedIn announcement. Six months later that person is either miserable, or gone, or both, because there is no team underneath them and they were hired to direct a function that doesn’t exist yet. It’s like hiring a conductor before you’ve booked the orchestra.

Get the order right.

At Series A the team you actually need looks like this, roughly, in hiring order:

1. A DevRel Engineer or hybrid technical lead: someone who can write code, ship demos, review the docs with a straight face, and speak fluently with your engineering team without needing a translator. The trap here is the “developer advocate” job posting that attracts generalists when what you need is technical depth. Amplify Partners have written well about this: the two core jobs of a DevRel hire are creating content and building community, and “advocate” is a title that tends to obscure which one you’re actually hiring for. Hire against the job.

2. A community or content operator: someone who can run the drumbeat. Newsletter, blog, community platform, event pipeline, the boring beautiful compounding work of showing up every week. This is where a lot of Series A companies get away with hiring a strong senior individual contributor rather than another leader.

3. Then, and only then, a lead. Once you have two people producing and shipping, you hire the Director or Head of DevRel to synchronise the function with the broader company strategy. This is when the title becomes correct. Hiring the Director first is one of the classic DevRel failure modes; the role starts making sense at the Series A inflection point, once there’s actually a function to lead. Director-level DevRel comp, again from our own scan of live venture-backed US roles, generally lands around $180K to $240K plus equity. Add a lead, a DevRel engineer and a community or content operator together and you’re planning for something in the region of $450K to $550K of fully-loaded annual cost before you’ve booked a single conference booth.

Reporting line matters. The 2024 State of Developer Relations Report found 33.1% of DevRel teams report into Marketing, 21.7% into Product, roughly 20% into Engineering, and 20.3% directly to the CEO. That last number has been climbing steadily. It was 12% back in 2020. At Series A we strongly prefer CEO or CTO ownership rather than a VP Marketing who inherits DevRel by default. Why? Because Marketing’s metrics are lead volume and MQLs, and DevRel’s job at Series A is not that. If your DevRel lead reports to someone whose bonus depends on gated ebook downloads, you have already lost.

Also worth noting: the same State of Developer Relations 2024 report finds around 62% of DevRel teams now communicate their value directly up to founders or C-level executives, and the share of one-person DevRel teams dropped roughly 18% year over year. The industry is telling you what it learned the hard way.

What Series A DevRel actually does all day

At seed you’re doing Awareness, making the thing exist in developers’ minds. At Series A that work continues, but your primary job becomes Activation.

The first five minutes a developer spends with your product. The API reference. The error messages. Whether “hello world” actually runs. This is DevRel’s territory now, and if your team is still spending 80% of its time on conference talks and Twitter threads, you are lighting money on fire. Here is a more in-depth look at how we track activation for our clients, which we break down through our Stateshift Model:

Stateshift illustration of tracking activation through the Stateshift model.

The other thing Series A DevRel owns is the content engine. Not “content” as in one blog post a fortnight, but the actual engine: a repeatable system that combines human authorship, AI assistance where it fits, and Generative Engine Optimization so the material shows up when developers ask AI models the questions you’d want them to ask. GEO is not optional any more. AI Overviews now appear on close to half of tracked Google searches by early 2026 per BrightEdge, up from around 6.5% in January 2025 per Semrush. If your content isn’t structured to be cited by an AI, you’re writing for a diminishing audience.

Then there’s conversion. Series A DevRel doesn’t get to hide behind “we build community, we don’t do sales.” You’re expected to influence pipeline. Not close it. Not carry a quota. Show, with data, that the community and the content and the activation work you’re doing correlate with the number your CFO cares about. That’s the game now.

The politics chapter, which nobody in the job spec warns you about

This is the bit that breaks more Series A DevRel leaders than anything else, and it’s not on the interview loop.

At seed nobody argues about DevRel because there’s nothing to argue about. At Series A, suddenly, Marketing wants your community for their nurture campaigns. Sales wants your Discord for lead lists. Product wants your team writing spec documents instead of shipping tutorials. Engineering thinks you’re wasting money. And Finance, bless them, wants to know why you’re spending $500K a year on people who “don’t own a number.”

You will spend, honestly, about 30% of your time at Series A on cross-functional politics. Budget setting. Managing expectations with your CEO. Explaining what DevRel is and isn’t to a VP of Sales who genuinely, without irony, wants your community manager to “generate more MQLs.” I once watched a brilliant DevRel lead resign four months into a Series A gig because nobody warned them the job was, functionally, part diplomat.

The counter to this is data. If you can walk into a leadership meeting with a number that ties DevRel activity to revenue-influenced pipeline, the politics gets quieter. Not silent. Quieter.

What Series A DevRel should measure

Here’s where roughly 61% of DevRel teams still trip over their own laces. That’s the percentage citing “proving impact with data and metrics” as their number one challenge, according to the 2024 State of Developer Relations Report. It has consistently ranked as the top challenge in recent editions of the same survey.

At Stateshift we’ve landed on three measurement layers we use with every Series A client. First, developer activation: time-to-first-value, integration success rate, activation conversion at each gate of the signup-to-first-API-call funnel. Second, community engagement quality, not raw counts. Contribution ratios. Advocate development. Are people going from lurker to poster to contributor, or is your Discord a graveyard with a bot? Third, business impact attribution: revenue correlation, support cost reduction, expansion tied to community-driven adoption. In quarterly reviews we push clients toward roughly 70/30 business outcomes versus engagement signals, because otherwise the QBR turns into a slide about follower counts and everyone falls asleep.

Stateshift's illustration of 3 measurement layers of DevRel for Series A.


The metric worth naming here is Influence Hours, Stateshift’s own weighted rollup of DevRel activity across every channel, from one-to-one deep conversations down to broadcast content at the bottom. High-signal work counts more than mass content. Influence Hours is the direct replacement for GitHub stars, event attendance, and every other vanity metric that Series A boards used to accept and now, thankfully, don’t.

Stateshift's illustration of how to calculate influencer hours.

/

The measurement industry has already shifted. “Programs that don’t measure success at all” dropped from 14.1% of teams in 2022 to 7.3% in 2024 according to the State of Developer Relations Report, and content-engagement and revenue-influenced pipeline signals have both moved firmly into the metrics DevRel teams now track. Not enough. But directionally correct.

A bit about Series B

Series B is where all of this becomes a predictable growth machine. You’ve identified which channels convert best. You know your activation funnel numbers. Your community programs have compounding retention behind them. The DevRel team roughly doubles again and starts specialising: one person owns docs, one owns community, one owns content, one owns partnerships. Retention and expansion become the primary jobs. Awareness runs on rails. Activation is measured to two decimal places.

You get to Series B by building the Series A team properly. There is no other path.

Your next steps

Take one thing from all this: at Series A, hire an engineer who can do DevRel or a DevReller who can code, pair them with a content or community operator, then hire your lead. Instrument activation before you spend on channels. Report to the CEO or the CTO, not the VP of Marketing. Measure Influence Hours, activation rate, and revenue-influenced pipeline. Expect politics. Expect to explain your job to five different people who each have a different definition of what your job is.

And for the love of everything, do not hire four Developer Advocates first.

Common questions on DevRel At Series A

What does a developer relations team look like at a Series A company?

A Series A DevRel team, done properly, is three to four people, not eight. It has one lead who reports to the CEO or CTO, an engineer who writes code and owns docs and demos, and a content or community operator who ships on a regular drumbeat. Its primary job is Activation: docs, quickstart, developer onboarding, and the funnel instrumentation to prove whether any of it works. At Stateshift, this is the configuration we see land the plane at Series A, and the one companies limp back to after trying every other setup first.

How do early-stage dev tools companies usually structure their go-to-market as they scale?

Go-to-market structure changes at every stage. At seed it is founder-led and improvised: the founder gives the talks, answers Discord, and runs the whole developer motion personally. At Series A it has to become an operating system, a scalable content engine, an instrumented activation funnel, and conversion metrics tied to revenue-influenced pipeline. At Series B the team specializes into distinct owners for docs, community, content, and partnerships. The Series B machine runs on the foundation built at Series A, which is why getting the Series A structure right matters more than any single hire.

Why shouldn’t I hire a Director of Developer Relations first?

Hire the people who ship before you hire the person who orchestrates. A Director hired before anyone is producing content, shipping docs, or running community has no function to direct, and tends to spend six months building decks about what the team could do rather than doing it. The order that works at Series A: first a DevRel engineer or technical lead who can code, then a content or community operator who ships weekly, then the lead who synchronizes the function with company strategy. The Director title becomes correct once there is actually a function to lead.

What should the first DevRel hire at Series A look like?

The first hire should be a seasoned practitioner who has personally built and operated a developer engagement system inside a comparable company. Avoid the first-time DevRel hire promoted straight from developer advocate, and avoid the big-agency lead who pitches with seniors and delivers with juniors. They should sit in your buyer’s timezone, be able to build a budget, set expectations with leadership, and navigate cross-functional politics from day one.

Who can help a Series A company structure its DevRel team?

Stateshift works with Series A dev tools companies to structure and instrument DevRel from the ground up. The work covers hiring sequence, activation funnel instrumentation, a content engine built for both human readers and AI citation, and measurement tied to revenue-influenced pipeline rather than vanity metrics. The firm has worked with more than 250 developer-focused companies from Seed through Series B, connecting DevRel, community, and go-to-market into a single system.

Written by:
Jono Bacon

Jono is the Founder and CEO of Stateshift. He has 27+ years of experience building user and developer engagement across 250+ companies. He is also the author of 'People Powered' by HarperCollins.

Get the SHIFTsignal

SHIFTsignal is not a boring newsletter filled with links
it is a FREE weekly dose of high quality insights, techniques, and recommendations for building your movement sent directly to your inbox.