What DevRel is and when you actually need it

DevRel is the function that builds and supports a company's relationship with developers outside it, and Jono Bacon, who advises founders on this exact decision, calls hiring it before positioning, activation, and one measured channel are live the single most expensive DevRel mistake a company can make.

Practitioners disagree on whether DevRel is a function inside developer marketing or a distinct discipline, a debate Developer marketing: a practical guide covers directly. What follows sets that debate aside for the operational question underneath it, what the role actually does day to day and when a company is ready to hire it.

What DevRel actually does day to day

Sam Julien, who moved into the role from a full-stack engineering job, breaks DevRel into four areas: awareness, education, feedback, and community. He writes that "developer advocates should be developers, since they need to truly understand where developer users are coming from and what they care about," and calls that background a necessity for the role, while noting there's still room for non-technical people elsewhere in DevRel.

A single day in his account might include preparing a conference talk, meeting with a content team on a technical article, answering product questions across Slack and community forums, reviewing early-access feedback with an SDK team, and joining a livestream with a partner company. On the road, that same day stretches further: last-minute slide tweaks before speaking, hours in a hallway answering questions from attendees afterward, then dinner and more conversation with attendees and other speakers into the evening.

That range is the point. Zan Markan, also writing from inside the role, rejects the idea of a typical day, describing DevRel as "an interdisciplinary field that often spans work across different departments within an organisation, as well as community outside of it." He names the work's actual throughline as enablement, the work of helping developers and colleagues do their own work more effectively.

The real signal for when to hire

Jono Bacon, who works with founders on this exact decision, gives a concrete rule: "Don't hire DevRel until positioning, activation, and one measured channel are live." Positioning comes first, tested by repeating it to people the company trusts and asking whether it resonates, until it can survive being repeated by a peer in a Slack DM, in one sentence, without losing its meaning.

Activation comes second, tracked as three separate gates: interest, a signup or an API key; intent, when someone actually tries setting the product up; and implement, when they reach a real outcome inside it.

Bacon cites a 2026 ChartMogul and ProductLed analysis of 200 B2B software products, which puts median free-to-paid conversion at 8%, with most companies unable to see where in that funnel their own signups actually drop off, because the three gates were never tracked separately. Only once both stages are measured does a channel open, one at a time.

His reasoning is specific to what a DevRel hire can and can't fix. Many people in the role, in his account, don't have the background to set up positioning and activation themselves, so they arrive, put material into channels, and there's still no way to tell whether any of it worked. A company that skips straight to hiring DevRel is asking the hire to solve a measurement problem the company created before that person walked in the door.

The mistake that costs the most

Bacon opens one piece with an anecdote he says he sees more often than he'd like: a Series A company with four Developer Advocates, one person writing docs part-time, and no activation instrumentation at all. "Nobody can tell you what happens when a developer signs up, because nobody has actually measured it." He calls this the single most expensive DevRel mistake a company can make, because nothing existed yet to tell whether the hires' work moved anything.

His fix sizes a Series A team at three to four people, hired in a specific order: a DevRel engineer who can write code and ship demos first, a community or content operator second, and a Director or lead only once those two are already producing. Hiring the director first, before there's a team to lead, is a separate mistake he names, one he says he has watched happen more times than he can count.

Activation work, docs, quickstart, and onboarding instrumentation, is the team's stated first job at that stage, ahead of conference talks or Twitter threads.

Seed-stage DevRel can run on instinct and a shared belief that the work is helping, because a founder can see the effect directly. Bacon points to the pressure of a priced round as the reason that stops working at Series A. It changes what "good enough" means, headcount roughly doubles, and other departments, sales, marketing, product, start forming their own opinions about what DevRel is for.

DevRel or developer advocate first

Olga Koenig put together a hiring cheat sheet after chats with various companies facing this decision, and ties the choice to whether a developer community already exists.

A company with no existing developer relationships, that genuinely cares about the engagement itself, may do better hiring DevRel first, to identify and engage the developers who care about its product and build a strategy around them. A company with an established community may do better hiring a developer advocate first, to promote the product into that community and support the developers already using it.

Looking for one person who covers both, in her words, is "similar to looking for a unicorn," rare and, in her account, very time-consuming to find.