Developer relations has become a standard answer to marketing to developers, and for good reason. In my experience, traditional campaigns struggle with this audience, and a credible engineer who talks to other engineers often works where a campaign doesn't.
Then the function gets loaded with everything. Community, content, conference talks, docs, product feedback, support escalation, and increasingly a pipeline number. Small teams are asked to be the entire top of funnel for a technical audience. In DevRel.Agency's 2024 State of Developer Relations survey, the most recent edition, a team of two to five was the most common size, and 18% of respondents were on one-person teams. When results plateau, the team tends to get the blame rather than the structure.
In my view, the cause is structural, not effort. Developer relations can attract new developers and deepen relationships with existing ones, but an employee's advocacy can't be the independent validation a developer looks for before adopting your tool.
Key takeaways
- In DevRel.Agency's 2024 State of Developer Relations survey of 310 practitioners, 61% named proving impact with data and metrics as one of the biggest challenges for DevRel, the most common answer.
- In the same survey, 66% named driving awareness and adoption as a main purpose of their developer program, while the most common DevRel team had two to five people and 18% of respondents worked on one-person teams.
- Marketing is the most common reporting line for DevRel teams, at 33% in that survey, followed by product (22%), the CEO (20%) and engineering (20%).
What can't developer relations do?
Developer relations can't supply independent validation, because a developer advocate is an employee. Developers know this, correctly discount for it, and the discount doesn't disappear because the advocate is genuinely knowledgeable and genuinely helpful.
That doesn't make DevRel ineffective. It sets a ceiling on what DevRel alone can accomplish. Your advocate can demonstrate competence, answer questions honestly, and build real relationships. What they can't do is be the independent validation a developer is looking for before committing their team to a dependency.
Only someone who doesn't work for you can supply that.
How is DevRel different from PR?
DevRel and earned coverage are good at different things, and they work best when they're coordinated.
DevRel does well: depth, responsiveness, credibility in conversation, product feedback that reaches engineering, and the sustained presence in community that makes a company feel real rather than transactional. It's also the function best placed to answer a hard technical question in public, quickly.
A founder I used to work with drove signups and leads through Reddit without getting flagged as spam. He'd find open questions that were getting traction, answer them with real best practices, and add one short line at the end about why he started his company. Developers have no tolerance for shilling, especially from accounts that haven't earned any karma, and this didn't read as shilling.
Earned coverage does well: reaching developers who have never heard of you, supplying third-party validation that survives the employee discount when a reporter tests your claims against outside sources, and putting your name in places engineers read for reasons unrelated to you.
In my view, DevRel with no outside validation at all can look like a company talking to itself. And when coverage draws technical questions, someone needs to be assigned to answer them and to feed the recurring ones into future outreach.
In my experience, devtools companies often invest heavily in one and treat the other as optional.
The missing handoff
In my experience, the gap between DevRel and earned coverage is the handoff: a developer reads something independent, gets curious, shows up in your community or your docs, and finds no path from interest to a real conversation. Or the reverse: your advocate has a great exchange with an engineer who then can't find any outside evidence the company is legitimate.
Both halves working, neither connected.
The fix is unglamorous. Know which independent pieces are driving arrivals so your advocate can meet those people with context. Feed the questions your advocate keeps answering back into what gets pitched externally, because a question asked repeatedly in your Discord may suggest a story worth pitching to a technical publication. Let your advocate be quoted in outside coverage rather than only publishing on your own properties.
In my view, that last one is worth the most, and it's often skipped. An advocate quoted in independent reporting reaches readers your blog doesn't. The quote is still the company's perspective, so it doesn't replace independent validation, but it puts your advocate's expertise in front of a new audience.
An engineering leader at one of our developer-tools clients posted a strong opinion in our shared Slack channel. We turned it into an op-ed, and The New Stack agreed to run it. For a busy engineer, that's the low-effort version: a few minutes of saying what you think, sent to us in Slack.
In my view, a pitch for a technical guest should lead with the argument the person will make and why it matters to that audience, not with their credentials.
Where does DevRel get misused?
In my experience, DevRel gets misused in three ways: as a pipeline function, as a documentation team and as a substitute for a technical spokesperson.
As a pipeline function. Attribution for community work is genuinely poor. In the same survey, 61% of practitioners named proving impact with data and metrics as one of the biggest challenges for DevRel, the most common answer. In my view, a sourced-pipeline target can miss what DevRel contributes when attribution doesn't capture community activity or technical education. The risk is that the team chases whatever the metric counts, or gets cut for underperforming against a metric that never fit.
As a documentation team. Docs matter enormously and need dedicated time and technical-writing skill. In the same survey, 43% of DevRel teams included technical writing. In my view, if DevRel owns docs, that work has to be staffed and planned explicitly, or both get squeezed.
As a substitute for a technical spokesperson. These are different jobs. An advocate builds relationships with practitioners; a spokesperson represents the company's position to press and analysts. Some people do both well. In my view, asking one person to be both without planning for it tends to produce a weaker version of each.
The version that works
The version of developer relations that works runs alongside earned media: two functions with different jobs, planned together, with someone owning the handoff between them.
Common questions
What is developer relations? Developer relations, or DevRel, is a function that builds relationships with developers through community participation, technical content, talks and direct support. Its credibility depends on technical expertise, useful work and honest engagement with developers.
What does a developer advocate do? A developer advocate builds a company's relationships with developers: speaking at conferences and meetups, writing technical posts, tutorials and sample code, and carrying developer feedback back to the product and engineering teams. In the 2024 State of Developer Relations survey, developer advocacy was the most common function on DevRel teams, present on 82% of them.
Should DevRel report to marketing or engineering? Both structures work, and both are common: marketing is the most frequent home, at about a third of teams, followed by product, the CEO and engineering at about a fifth each. What matters more is whether DevRel is measured on something it can actually influence. If DevRel reports to marketing, its targets should reflect the program's goals and what its attribution can reliably measure.
How do you measure developer relations? Better through leading indicators than pipeline: community activity that isn't staff-generated, inbound technical questions, and whether developers arrive already knowing what you do. In the 2024 State of Developer Relations survey, active users (44%) and content engagement (38%) were the most common measures of program success.
Can DevRel replace PR for a developer tools company? No, and not because of quality. They do different jobs. DevRel attracts and supports developers through technical education and community work. PR complements it by seeking independent reporting that reaches additional audiences and, when reporters test your claims, gives developers a view from people who don't work for you.
Sources
- DevRel.Agency (Caroline Lewko, steward), State of Developer Relations Report 2024 (11th annual survey, 310 valid respondents), State of Developer Relations, September 10, 2024
- Matthew Revell, What is developer relations?, DeveloperRelations.com (Hoopy), updated February 8, 2025
Salient PR works with developer tools companies across CI/CD, testing infrastructure and developer platforms, building spokesperson and earned-media programs alongside in-house DevRel teams.
About Salient PR
Salient is a B2B tech PR agency. We help startups become the story — landing tier-one coverage, building executive visibility, and turning attention into pipeline.
Senior team. No hand-offs. Radical transparency. If you’re ready to talk, reach out.
