Back in 2016, a developer advocate slid into my DMs. I’d just published a grumpy post about an API with documentation that felt like a practical joke. His message wasn’t a pitch. It was short, human, and ended with an offer to pair-debug the issue. No slide deck. No “we’d love to jump on a call to understand your workflow.” Just a sandbox link and a time slot. That one interaction turned me into a paying customer for three years. Fast forward to now, and my inbox is a graveyard of templated outreach from people who call themselves advocates but act like sales reps nursing a free-tier quota. The title “Developer Advocate” has been hollowed out, and the people who lose most are the developers these roles were supposed to serve.
The rot isn’t subtle. It starts when advocacy teams get measured by pipeline contribution instead of community health. It deepens when conference talks morph into product demos, and it calcifies when the advocate’s GitHub profile shows nothing but a green square on the day they joined the company. The issue isn’t that advocacy has a sales component—every role in a business eventually supports revenue. The issue is when the advocacy feels like sales, and the developer on the other end stops trusting anything you say.
The Trust Thermocline
There’s a concept in community building called the trust thermocline. Above a certain temperature, the water is warm and welcoming. Below it, the temperature drops off a cliff. Developer trust works the same way. You can erode goodwill for months with thinly-veiled product pitches, and on the surface, everything looks fine—until one day, it doesn’t. The community stops answering your questions. Your open-source repos gather dust. Your Discord server becomes a ghost town where the only messages are from your own bot.
I’ve watched this happen to companies that should know better. They hire brilliant engineers, dress them in company hoodies, and then hand them a content calendar that reads like a marketing brochure. The advocate becomes a mouthpiece, not a bridge. And the developer community, which can smell inauthenticity from a mile away, simply disengages. No one sends an angry email. They just stop showing up.
When Code Becomes Collateral
The most egregious pattern I see is the weaponization of example code. A genuine developer advocate writes code to solve a problem, then shares it because the solution is interesting. The code might use their company’s product—that’s natural, they know it best—but the primary value is the solution itself. The sales-advocate hybrid writes code that requires their product to function, then packages it as a tutorial. The difference is subtle but devastating.
Consider this Python snippet from a real “advocacy” post I found last week:
# Import our amazing platform SDK
from amazing_platform import MagicSDK
# Initialize with your API key (sign up for free!)
sdk = MagicSDK(api_key="YOUR_KEY_HERE")
# This only works with our proprietary model
result = sdk.do_the_thing(input_data)
print(result)
There’s no educational value here. The code doesn’t teach a transferable skill. It’s a sales demo dressed in a Markdown cell. A real advocate would have shown how to solve the underlying problem with open-source tools first, then explained where their product adds value—if it actually does. The difference is between teaching someone to fish and selling them a fishing rod they can only use in your private lake.
The Metrics That Kill Authenticity
Behind every hollow advocacy program is a set of metrics designed by someone who has never built a community. I’ve seen scorecards that track “qualified leads generated” per blog post, “pipeline influenced” per workshop, and “conversion rate” per conference talk. These are sales metrics. They measure extraction, not contribution. When an advocate’s performance review depends on how many signups their tutorial drove, the tutorial stops being a tutorial and becomes a funnel.
The alternative isn’t to abandon measurement—it’s to measure what actually matters for developer trust. Things like:
- Issue resolution time on repos the advocate maintains
- Community member progression (from lurker to contributor to maintainer)
- Unprompted mentions and referrals from developers
- Quality of feedback flowing from the community back to engineering
These are leading indicators of a healthy ecosystem. They’re harder to quantify than MQLs, but they predict long-term adoption far better than a spike in trial signups after a Hacker News launch.
The Open-Source Litmus Test
Here’s a simple heuristic I use to evaluate whether a company’s advocacy is genuine: look at their open-source contributions. Not their own repos—every company maintains those. Look at what their advocates contribute to other projects. Are they fixing bugs in dependencies their product uses? Are they submitting patches to frameworks that compete with their offering? If the answer is no, their advocacy is probably just marketing with a developer-friendly face.
I once interviewed a candidate for a developer relations role who had an impressive GitHub history—until I noticed every single commit was to their employer’s monorepo. They’d never opened a PR against an external project. They’d never filed a bug report for a library they didn’t own. That’s not advocacy. That’s a developer who happens to work in marketing.
The Feedback Loop That’s Actually Broken
Companies love to talk about “closing the feedback loop” between developers and product teams. In practice, this usually means the advocate collects complaints, files them in a CRM, and then the product team ignores them because they’re busy building what the CEO wants. The loop isn’t closed—it’s a black hole with a Slack integration.
Real advocacy means the advocate has enough organizational power to say “no” to a product manager. It means they can kill a feature that the community hates, or delay a launch because the developer experience is garbage. If your advocates can’t influence the roadmap, they’re not advocates. They’re human shields.
I’ve seen this play out painfully at a database company I won’t name. Their advocates spent months telling the product team that a new query syntax was confusing and poorly documented. The product team shipped it anyway. The advocates then had to go on Twitter and pretend it was great. The community saw through it immediately. Trust burned. The advocates left within six months.
What Good Advocacy Looks Like in Practice
Let me give you a concrete example. A few years ago, I was evaluating a new observability tool. Their developer advocate didn’t send me a whitepaper. They sent me a link to a GitHub repo where they’d built a reference implementation using competitor tools, with a clear explanation of where their product fit in and where it didn’t. They’d filed bugs against their own SDK based on that work. That’s advocacy. That’s someone who cares more about the developer experience than the sale.
Here’s what that looked like in practice. They had a section in their README that said, essentially:
## When NOT to use OurTool
If your system meets these criteria:
- Request volume under 10k/day
- Single service architecture
- You’re already comfortable with Prometheus/Grafana
Then you probably don’t need us. Here’s a setup guide for that stack.
That paragraph did more for their credibility than any case study ever could. It told me they understood the problem space, respected my intelligence, and weren’t desperate for my credit card. I ended up recommending them to a team that did need their tool, because I trusted them.
The Conference Talk Smell Test
Conference talks are another reliable indicator. A real advocate gives talks that are useful even if you never touch their product. They explain concepts, patterns, and pitfalls that apply across the ecosystem. A sales-advocate gives talks that are 20 minutes of context followed by 10 minutes of demo. You can spot the difference in the abstract: if the talk title includes the product name, it’s probably a pitch. If it includes a problem statement, it might be worth attending.
I’ve started applying a simple rule: if I can remove every mention of the company’s product from the talk and the audience still learns something valuable, it’s advocacy. If removing the product makes the talk collapse, it’s a commercial.
The Incentive Problem
Why does this keep happening? Because companies optimize for the wrong thing. They see developer advocates as a growth channel, not a trust function. They want advocates who can “drive adoption,” which is code for “get more people to use the free tier so we can upsell them later.” The advocates who thrive in that environment are the ones who are comfortable with that framing. The ones who push back get managed out or leave voluntarily.
The fix requires a structural change. Advocate teams should report to engineering, not marketing. Their success metrics should be decoupled from revenue targets. Their compensation should not include a variable component tied to signups or conversions. This isn’t radical—it’s how the best developer tools companies already operate. But it requires leadership that understands the difference between extracting value from a community and investing in one.
Code Review as Advocacy
One of the most underrated forms of advocacy is the code review. When a company’s engineers review external pull requests with the same rigor and respect they’d give an internal teammate, that’s advocacy. When they take the time to explain why a certain approach won’t work, instead of just closing the PR with a “wontfix” label, that’s advocacy. When they thank contributors for catching edge cases and credit them in release notes, that’s advocacy.
I’ve seen this done brilliantly by a small infrastructure startup. Their CTO personally reviewed every external PR for the first two years. Not just a rubber-stamp approval—detailed, thoughtful reviews that often ran longer than the code changes themselves. Contributors became champions. Champions became employees. The company built a reputation for technical excellence that no amount of content marketing could buy.
When Advocacy Becomes Apologetics
There’s another dark pattern I’ve seen emerge: the advocate as apologist. When a company ships a breaking change with no migration path, or deprecates a widely-used feature without warning, the advocate is sent out to calm the mob. They write blog posts about “the vision” and “long-term architecture decisions.” They host AMAs where they deflect hard questions with corporate speak. This isn’t advocacy—it’s PR for a technical audience, and developers see through it instantly.
The right response to a breaking change is honesty. “We messed up. Here’s what we should have done. Here’s what we’re doing to fix it. Here’s how we’ll prevent it next time.” If your advocate can’t say that publicly, your company has a culture problem, not a messaging problem.
Building Advocacy That Lasts
So what does sustainable advocacy look like? It starts with hiring. Look for people who were contributing to your community before you had a job opening. They’re the ones filing thoughtful issues, answering questions on Stack Overflow, and maintaining unofficial libraries. They already have the intrinsic motivation. Your job is to give them resources and get out of their way.
It continues with protection. Shield your advocates from marketing KPIs. Let them write critical posts about your product if the criticism is valid. When they tell you the API is confusing, believe them—they’re the ones fielding the support tickets. And when they ask for six months to build a community around a new open-source project before you attach any product expectations, give them twelve.
The companies that get this right treat advocacy as R&D for developer experience. The output isn’t leads—it’s insights, trust, and a community that will defend you when you make mistakes because they know you’ll own up to them. That’s not soft and fuzzy. That’s the hardest competitive advantage to replicate.
FAQ
What’s the difference between a developer advocate and a sales engineer?
A sales engineer supports a specific deal cycle. They work with prospects who are already in the pipeline, answering technical questions and building proof-of-concepts. A developer advocate works with the broader community, often with people who will never become customers. The advocate’s goal is education and trust-building, not closing. When the two roles blur, it’s usually because the company views community members as leads-in-waiting rather than as peers.
How can I tell if a company’s advocacy program is genuine before joining?
Look at the team’s output over the past year. Read their blog posts, watch their talks, and check their code contributions. Ask yourself: would this content still be valuable if the product didn’t exist? Also, talk to former advocates from the company—they’re often candid about whether they were empowered or just used as a marketing channel. Finally, ask in the interview how the team’s success is measured. If the answer includes “pipeline” or “conversion,” proceed with caution.
Can a company have effective advocacy while still being sales-driven?
It’s possible but rare. The tension is structural: sales optimizes for short-term revenue, advocacy optimizes for long-term trust. When resources get tight, the advocacy budget is often the first to be redirected toward “higher-impact” activities, which means the trust-building work stops. The companies that make it work usually have a founder or CTO who personally values developer relations and protects it from quarterly pressures. Without that top-cover, advocacy inevitably slides into sales support.
What should individual contributors do if they’re pushed into sales-style advocacy?
First, document the disconnect. Keep a log of community feedback that contradicts the company’s messaging, and present it to your manager with specific examples of how the current approach is eroding trust. If you have the organizational capital, propose a pilot program where you spend 20% of your time on non-product, purely educational content, and measure engagement metrics instead of pipeline. If the company won’t budge, you have a choice: accept that you’re in a sales role with a different title, or find a company that understands what advocacy actually means. The market for genuine developer advocates is strong—don’t settle for being a funnel.