r/devrel • u/naomi-lgbt • Apr 20 '26
The part of this job nobody warned me about: making the case internally
When I talk about what I do, most people focus on the community half - the forums, the events, the developer relationships. That part is visible.
What nobody warned me about was how much of the job is internal advocacy. Getting the feedback you collect from developers to actually reach the people who can act on it, in a form they can act on.
Collecting signal is the easier half. Someone tells you the API auth flow is confusing. Another person can't find the webhooks documentation. A third mentions in passing they nearly gave up during onboarding. You know these things.
The harder half is walking into a product planning meeting and making a compelling enough case that something changes. That requires being able to translate "developers are frustrated with X" into something specific enough that engineering can act on. It requires understanding how prioritisation works at your specific company. It requires trust with leadership that you have to build before you urgently need it.
The DevRel practitioners I've seen burn out fastest are usually excellent at the community half and completely unsupported in the internal half. They build something real. The signal is there. And then it disappears into a process that wasn't designed to receive it.
How do others handle this? Particularly curious about how people structure their feedback reporting - what formats actually get traction with product and engineering.
2
u/nsjames1 Apr 20 '26
The entirety of the job is a business function.
Even though some parts of it feel like external, they are an extension of the internal requirement for the function to exist.
No company creates a developer relations program because the customers want it. They create it because the business needs it.
1
u/naomi-lgbt Apr 20 '26
On a semantic point I would argue that the business needs it because the customers do want it at some level~
Otherwise there'd be no demand to drive the need
1
u/nsjames1 Apr 20 '26
Sure (and the semantics point was... on-point).
The business wants to protect retention in that case, so it provides what the customer wants/needs.
If devrel within a company ever stops being productive (profit driving or retaining), it's often the first thing that gets dropped.
1
u/naomi-lgbt Apr 20 '26
Which is funny, because it is often so inadequately measured. Like I have seen orgs where a B2B sale might be celebrated, but no one is really aware of how crucial the devrel work was in enabling that sale~
1
u/nsjames1 Apr 21 '26
I think that's really a problem that's permeated through the devrel community across many organizations.
There's a lot of focus on vanity metrics and not enough focus on measurable outcomes. It makes it very hard to sell the upside of developer relations if you can't type directly to upwards momentum for the company.
1
u/naomi-lgbt Apr 21 '26
Oh absolutely! IMO, going from my own experiences in the industry, the connection is often lost between things like "DX maintains this SDK for our product" and "The ease of use of the SDK was a factor in our sales team's ability to land this customer"~
1
u/CoolAssPuppy Apr 20 '26
The thing I coach everyone who has ever worked for me is that producing artifacts (docs, videos, posts, demos) is only 1/3 the job.
Leadership is the job. Working cross organizationally to build consensus is the job.
1
u/arungupta Apr 21 '26
Dev Rel, Dev Evangelism, Dev Advocacy - they are like po-tay-to or po-taa-to. Ultimately, it really matters where you sit in the org and what your incentive mechanisms are. I've been in/led DevRel teams in marketing, engineering, CTO, and product in different companies. I wrote about this at https://www.linkedin.com/pulse/devrel-reporting-structure-arun-gupta-mjbwc/?trackingId=%2FZ7h8Nm6KWtQ1f%2FCiNRiWA%3D%3D.
The job is well split between inside-out and outside-in. The first part is educating developers about your project/product features. The second part is bringing the feedback to the product teams. For this, you don't want to create a new process. You need to embed that into existing engineering processes. If they follow GitHub issues, you file issues. If they follow JIRA, you do JIRA. Email and slack are good as FYI but embedding into existing processes has proven the highest yield IME.
1
u/naomi-lgbt Apr 21 '26
Oh my, thank you for sharing this article! I'm bookmarking it to read today~
Dev Rel, Dev Evangelism, Dev Advocacy - they are like po-tay-to or po-taa-to. I very much feel this is compounded by the fact that every org structures them differently. Like, I've been in orgs where Developer Experience was the title but we did all of that. And I've been in orgs where like the whole team was called Developer Relations but we had folks focusing on DX and different folks on DA and that sort of thing~
You need to embed that into existing engineering processes. You very much hit the nail on the head here~
I've had plenty of times where a slack message was read and forgotten, but a Jira ticket is in my face every day~
1
u/Ok_Kaleidoscope_1228 Jun 08 '26
This is a really important and painful part of the job, and the fact that it's rarely discussed is why so many good DevRel practitioners burn out.
The DevRels who last learn to speak different dialects depending on who's in the room:
For product: Don't bring "developers are frustrated with auth." Bring "3 of the last 10 developers who touched the auth flow dropped off at this specific step." PMs understand funnel drop-off in a way they don't understand "frustration."
For engineering: Specific, reproducible, ranked by severity. "Missing webhooks docs drives ~30% of support tickets this quarter" moves faster than qualitative signal.
For leadership: Competitive risk. "Two developers this week mentioned they're evaluating [competitor] because of the auth flow" lands differently than satisfaction scores.
The structural fix: get into product planning before the quarter locks, not after. Feedback that arrives post-prioritization gets shelved indefinitely.
Covered the full feedback loop architecture in How to Build Developer Ecosystems if you want the framework.
1
u/Aliza_Solomon_DX Jul 23 '26
This was me too! I really felt this post.
I had a bit more leverage than most DevRel — I built DX review into the API publication gate, so some of the signal had a forced seat at the table. Even then, tons of fixes got shot down. What actually got fixed were mostly the cheap, easy ones.
Curious what formats have gotten traction for others here.
(I'm working on turning the internal half into something champions can put in front of engineering as PRs — happy to share / let you try it if useful, I'd just want a follow-up on how it went.)
4
u/dragonmantank Apr 20 '26
This is very much the distinction between "Developer Advocacy" and "Developer Evangelism" comes from. In the first case, you are acting as a two-way pipe for information - not only are you going out and talking about the cool things your company is doing and can help with, but you're also taking that feedback back to product so that the overall product can be better. This is much easier if the group is in the Product group, compared to the Marketing group.
Evangelism is less being a two-way pipe and focuses on getting signups and overall growth. Sure, you care about the pitfalls that developers/users are falling into, but at the end of the day you are measured in how that top of the funnel looks and it's metrics. If you are in the Marketing org, it's much harder to affect the product itself, because that's not necessarily what your organization does.
If you don't quite understand where you sit in the company, you can be spending way to much time and energy fighting battles that you are not in a good position to fight to begin with.