Hiring a head of DevRel is a challenge. A founder decides they need developer relations, which is a great instinct. They interview a parade of people with gorgeous slide decks, enormous social followings and a conference talk somebody still raves about.
A year later they’re in a board meeting explaining why the developer program produced a mountain of “engagement” and almost no change in how many active users they have. The program gets cut. The hire leaves with a heartfelt LinkedIn post about how DevRel is misunderstood. Then the next founder starts again, with the same job post.
The root cause is almost insultingly simple. Nobody decided what the job was before interviewing for it, so they mistook a famous speaker for a system builder: someone who creates a repeatable process that moves a number. The speaker looks exactly like what everyone pictures when they imagine a Head of DevRel. The system builder looks like a slightly harried operator who wants to talk about funnels and metrics. Guess who wins the vibe check.
Here’s the rubric we use at Stateshift to judge whether a Head of DevRel can get developers to start using your product, reach a first real result and keep coming back. I call that owning adoption.
Why the bar for a Head of Devrel has moved
The job has changed, and most interview loops are still running the old script. In the 2024 State of DevRel survey, “proving the business impact of DevRel” (28.5%) jumped to second place among program challenges, up from seventh in 2023. The same report found that 66% name driving awareness and adoption of products as the top purpose of a developer program, and 44% put Active Users in their top three success metrics. The job moved from “be visible” to “show what changed,” and plenty of hiring panels are still asking the first question.
If your questions reward reach and stage presence, you are recruiting for a job that has been retired, then judging the hire on the one that replaced it. You could have hired a world-class wine maker and you’re about to fire them over a bland pizza they made for you. That’s not their failure. That’s yours.
Set the evaluation bar before you meet any candidates
This is the step almost nobody does. An evaluation bar is a short written document, agreed before the first candidate call, that answers three questions. What outcome is this person accountable for? Which qualities are must-haves, and which can you teach? What proof of past work will every candidate show?
Skip it and you’ll score people against a moving target, which in practice means whoever charmed you most in the last conversation. That’s a popularity contest with a calendar invite. Hire on charm alone and you end up employing Jay Gatsby: spectacular parties, a magnetic presence, and nobody can quite explain where the revenue came from.
The instinct is to fix this with Process, capital P. A seven-stakeholder interview loop. A 40-row scoring spreadsheet. A kickoff meeting to discuss the spreadsheet, then a follow-up to discuss why nobody filled it in. Six weeks later you’ve hired nobody and everyone is quietly weeping into their calendar. The bar is the opposite: one page that forces the argument early, while it’s cheap, then gets out of your way.
Agree on the metric and the must-haves
Write down what this hire is accountable for: more developers reaching a first real result, more of them staying, or both. Put a target on paper, something like “lift trial-to-activated by 15%,” which just means 15% more trial users reaching that first real result.
If the role also covers awareness, give that a real number too. We use Influence Hours, which weights reach by time spent and by how intimate the format is, so a conference talk and a blog post land on the same scale. Track conversions per Influence Hour alongside it and you can see whether the awareness work is feeding the adoption number this person owns.
Then get product, marketing and the CEO to agree, because those teams often hold quietly different ideas of what DevRel is for. If you can’t state the metric this person owns, you’re not ready to hire. You’re ready to have interesting conversations with interesting people, which is a different and far more expensive hobby.
Then make two lists: what you’ll screen out on, and what you’ll coach after they join. Only screen out on what you can’t teach. “Has owned a funnel metric end-to-end and can walk you through how they moved it” is a must-have. A funnel metric is a number that tracks developers from sign-up to active use. “Can run a launch” is coachable. “Speaks well on stage” is mostly polish, unless you’re hiring an evangelist.
Get this wrong and you’ll reject the operator who stumbled on a whiteboard exercise but has moved real numbers, then hand the role to someone with dazzling stage presence who has never owned a number in their life. None of us is immune to a good speaking reel, and I’m usually first in line.
The DevRel leader evaluation rubric
With the bar set, the interview gets easier. Use three tools together: interview questions, work samples and a scorecard.
Interview questions
A good question produces answers that sound noticeably different depending on who’s giving them.
1. “Walk me through a funnel metric you’ve owned end-to-end. What was the baseline, what did you change, what happened?”
A failing answer pivots to “the community grew a lot,” then a viral tweet, then a conference, then a slightly bigger viral tweet. A good answer names the metric, the baseline and two or three changes, then volunteers the ones that flopped, which tells you they were actually there.
2. “What’s the difference between getting a developer to a first real result and getting them to keep coming back, and which would you fix first at our stage?”
A failing answer uses the two interchangeably and files both under “engagement,” the junk drawer of DevRel metrics where everything goes and nothing gets found. A good answer separates them cleanly, says which comes first at your stage, and names a measure for it. Time to first call is a refreshingly unglamorous example. Postman describes it as a measure of onboarding, and one way to quantify it is the time from getting API credentials to a first API call.
In Postman’s data from one API publisher, developers made a first successful call in 10 minutes with the publisher-provided collection versus 17 minutes overall for that API, about 1.7 times faster. Seven minutes of a developer’s life, handed back.
3. “Pick a piece of content you’re proud of. What business outcome did it move, and how do you know?”
A failing answer describes impressions, stars and followers, then circles back to the same numbers wearing a different hat when you push. A good answer ties the piece to a specific outcome and explains how it was measured. Push on documentation, the least glamorous corner of DevRel and the resource developers use most for learning to code.
4. “Tell me about a program that failed. What was your part in it?”
A failing answer can’t name a real failure, offers a flattering one (“I care too much”), or blames timing and leadership. If every failure in their career was somebody else’s fault, you’re interviewing the unluckiest person alive. A good answer describes a specific miss, owns it, and says what changed.
Work samples every finalist should produce
Questions are useful, but work samples cut through interview polish. Ask every finalist for the same things. Start with something they’ve already made, such as a funnel diagram or a written adoption plan with the assumptions labeled. If they can’t share past work, that’s a data point, not a rejection, so also ask for fresh work. Give each finalist a week, and pay them if the scope justifies it.
- A one-page content plan sketch showing what gets produced and which metric each piece is designed to move.
- A proposal for getting new developers to a first real result, with a hypothesis and a measurement plan. A system builder hands you something you could run on Monday. A famous speaker hands you a strategy deck in a beautiful font. I have personally been guilty of the font.
- A 90-day plan in prose, not slides, because nobody has ever hidden a weak plan inside a paragraph. Cover weeks one to four, five to eight and nine to twelve, with a measurement checkpoint in each.
The scorecard
Score every candidate against the same criteria, with an explicit green and red flag for each. This is what stops the process becoming a beauty contest.
| Criterion | Green flag | Red flag |
|---|---|---|
| Ownership of a funnel metric | Names the metric, the baseline and the intervention. | Talks about impact in vibes. “The community was electric.” No number. |
| First result vs coming back | Distinguishes them cleanly and names leading indicators for each. | Uses the words interchangeably, or files both under “engagement.” |
| Connecting content to an outcome | Every piece of content has a job. | Content described by format and reach: views, stars, followers. |
| Instrumentation | Names specific indicators, such as docs engagement and the share of trial users reaching a first result, and how they’d capture them. | “We’d survey the community.” Outsources measurement to a feeling. |
| Failure honesty | A specific failure with a lesson that isn’t self-flattering. | Can’t think of one, or it’s a humblebrag. |
If a candidate lights up green on ownership, instrumentation and content-to-outcome, you’ve probably found your leader. If they’re green on stagecraft and red on ownership, you’ve found a brilliant senior advocate, which is a great hire for a different job. Put them there and keep looking for the person who’ll run adoption.
Common Questions On Hiring A Head Of DevRel
What makes a good head of DevRel?
A good developer relations leader owns three measurable outcomes: developers starting to use the product, reaching a first real result with it, and coming back. They can name a funnel metric they’ve moved and tie every piece of content to a job.
What’s the most important factor in hiring a DevRel leader candidate?
At Stateshift, we always require that you write your evaluation bar before the first interview, then put every finalist through the same interview questions, work samples and scorecard.
What interview questions reveal whether a DevRel candidate can drive adoption?
Ask candidates to walk you through a funnel metric they owned end to end, including the baseline, what they changed, and what happened. Ask them to explain the difference between getting a developer to a first result and keeping them coming back, and to tie a piece of content they’re proud of to a business outcome. Strong candidates answer with specific numbers and mention the experiments that flopped. Weaker candidates fall back on community growth, followers, and viral posts.
What are the red flags when hiring a Head of DevRel?
The biggest red flag is a candidate who describes impact without numbers, such as “the community was electric,” and who has never owned a funnel metric. Other warning signs include treating activation and retention as the same thing under the label “engagement,” measuring content only by views or stars, and being unable to name a real failure they were responsible for. A candidate who is strong on stage presence but weak on ownership may make an excellent senior advocate, but probably not the right person to lead adoption.
