When Developer Relations Starts Sounding Like a Sales Pitch

I was sitting in a technical workshop last month, watching a developer advocate walk through a new API integration. The slides were polished. The demo gods were merciful. But about fifteen minutes in, I realized something was off. The code examples were trivial—happy-path snippets that would never survive a real production environment. The Q&A dodged hard questions about rate limiting and error handling. The whole thing felt less like a technical deep-dive and more like a product launch with curly braces.

This is the quiet crisis in developer advocacy. Not the loud, obvious kind where someone reads from a marketing deck. The subtle kind, where the advocate genuinely knows their stuff but has been nudged—by metrics, by management, by the gravitational pull of quarterly goals—into a role that prioritizes conversion over education. The result is a strange hybrid: a technically precise person delivering content that feels, at its core, like a sales funnel.

The Code Smell of Advocacy

In software, we talk about code smells—surface indicators that something deeper is wrong. Developer advocacy has its own smells. One of the most pungent is the demo that never fails. Real systems fail. Networks time out. Authentication tokens expire mid-request. A live demo that glides through without a hiccup isn’t a sign of a solid product; it’s a sign of a carefully manicured path. When I see a workshop where every curl command returns a perfect 200, I start to suspect the advocate has optimized for applause, not for learning.

Consider this snippet you might see in a typical advocacy-led tutorial:

const response = await fetch('https://api.example.com/v2/data', {
  headers: { Authorization: `Bearer ${token}` }
});
const data = await response.json();
console.log(data.results);

Clean. Simple. It works in the controlled environment. But what’s missing? No error handling. No retry logic for a 429. No fallback for a malformed JSON response. A developer who copies this into production will hit a wall within hours. The advocate knows this. But adding proper error handling would complicate the narrative, introduce friction, and—let’s be honest—make the product look less magical. So the complexity gets swept under the rug.

This is where advocacy starts to smell like sales. The goal shifts from “here’s how to use this effectively in the real world” to “here’s how easy it is to get started.” The former serves the developer. The latter serves the vendor’s adoption numbers.

The Metrics Trap

Developer relations teams are increasingly measured on metrics that belong in a marketing dashboard: sign-ups, API key creations, sandbox activations. These numbers are easy to track and even easier to present to executives. But they measure interest, not capability. A developer who signs up for a free tier and never builds anything is a vanity metric. A developer who integrates your SDK into a production system after six months of evaluation is the real win—but that’s harder to attribute to a single workshop or blog post.

When advocates are judged by sign-ups, their content inevitably bends toward the top of the funnel. Tutorials become “Getting Started in 5 Minutes” rather than “Debugging Common Integration Failures.” Conference talks emphasize the happy path. Documentation highlights the simplest use case. The technical depth that would actually help a senior engineer make an adoption decision gets buried because it doesn’t convert as well at the entry level.

I’ve seen this play out with a database company that shall remain nameless. Their advocacy team produced excellent deep-dive content for years—articles on query optimization, replication strategies, failure modes. Then the metrics regime changed. Suddenly the blog was full of “Build a Todo App in 10 Minutes” posts. The conference talks became product demos with Q&A scrubbed of anything uncomfortable. The advocates were still brilliant engineers, but the system had turned them into a sales enablement function.

What Real Technical Advocacy Looks Like

Genuine developer advocacy starts from a different premise: the advocate’s primary allegiance is to the developer community, not to their employer’s revenue targets. This doesn’t mean they’re disloyal or subversive. It means they understand that the long-term health of the product depends on developers trusting the people who represent it. Trust is built by telling the truth about limitations, by showing workarounds for rough edges, and by admitting when a competing tool might be a better fit for a specific use case.

I once watched an advocate from a monitoring platform do something remarkable during a workshop. A participant asked about a specific Prometheus feature their product didn’t support. Instead of deflecting, the advocate said: “We don’t handle that well yet. Here’s the GitHub issue tracking it. In the meantime, if that’s a dealbreaker for you, here’s how you’d set it up with Grafana’s native tooling.” He then showed the competitor’s configuration. The room didn’t empty out. People leaned in. They took notes. Several told me afterward that moment was why they ended up evaluating the product seriously.

That’s the counterintuitive truth: honesty about weaknesses is a strength signal. Developers are pattern-matchers. They’ve been burned by overpromising vendors. When an advocate demonstrates that they understand the full landscape—including where their own tool falls short—it signals competence and integrity. It says: “I’m not just here to sell you something. I’m here because I believe this is the right tool for enough of your problems that it’s worth your time to evaluate.”

The Technical Debt of Shallow Content

There’s a parallel here to technical debt in code. When you ship a feature quickly without proper error handling, you accrue debt that someone will have to pay later—usually in the form of 3 AM pages and angry customers. Shallow advocacy content creates a similar debt. It brings in developers with unrealistic expectations. Those developers start building, hit the unmentioned limitations, and then flood your forums, your support channels, and your issue tracker with frustration. Your support team pays the debt. Your engineering team pays the debt. Your product’s reputation pays the debt.

I’ve traced this pattern through several open-source projects. The ones with advocacy teams that publish honest, deep content have healthier communities. Their GitHub issues contain more feature requests and fewer “this doesn’t work” complaints. Their Stack Overflow tags have higher answer rates. The correlation isn’t perfect, but it’s strong enough that I now use advocacy content quality as a signal when evaluating whether to adopt a new tool.

Let me give you a concrete example. Compare two API documentation approaches:

Approach A (Sales-smelling):

// Easy! Just call this endpoint.
GET /api/v1/users

Approach B (Advocacy):

// Returns paginated users. Default page size is 20, max 100.
// Rate limit: 60 requests per minute per API key.
// On 429, retry after the Retry-After header duration.
// Fields may be null if the user hasn't completed profile setup.
GET /api/v1/users

// Example with error handling and pagination:
async function getUsers(page = 1, pageSize = 20) {
  const url = new URL('https://api.example.com/v1/users');
  url.searchParams.set('page', page);
  url.searchParams.set('page_size', Math.min(pageSize, 100));

  try {
    const response = await fetch(url, {
      headers: { Authorization: `Bearer ${token}` }
    });

    if (response.status === 429) {
      const retryAfter = response.headers.get('Retry-After') || 60;
      await new Promise(r => setTimeout(r, retryAfter * 1000));
      return getUsers(page, pageSize);
    }

    if (!response.ok) {
      throw new Error(`API error: ${response.status}`);
    }

    const data = await response.json();
    return data.users.map(user => ({
      ...user,
      email: user.email || 'Not provided'
    }));
  } catch (error) {
    console.error('Failed to fetch users:', error);
    throw error;
  }
}

The second version is longer. It’s less “sexy.” But it’s what a developer actually needs. It respects the reader’s intelligence and their real-world constraints. It doesn’t pretend the API is magic. It shows the advocate has used this in production and knows where the bodies are buried.

Why This Happens

I don’t think most advocates want to produce sales-smelling content. The pressure comes from organizational design. When DevRel reports into Marketing, the gravitational pull is toward lead generation. When it reports into Product, the pull is toward feature promotion. When it reports into Engineering, the pull is toward technical accuracy but often with less budget and less visibility. The ideal structure—DevRel as an independent function with dotted lines to all three—is rare because it requires executive-level understanding of what developer advocacy actually does.

There’s also a hiring problem. Companies often hire advocates for their charisma and stage presence, then discover they lack the technical depth to create content that senior engineers respect. Or they hire brilliant engineers who can’t communicate effectively with a room full of strangers. The unicorn who can do both exists but is, by definition, rare. When the balance tips toward charisma, the content inevitably becomes more presentation than substance.

But the deepest cause is philosophical. Many companies don’t actually believe in developer advocacy as a discipline. They believe in developer marketing and call it advocacy because that sounds more authentic. The difference is existential. Advocacy starts with the question “What do developers need to be successful?” Marketing starts with “How do we get more developers to use our product?” Those questions can align, but they often diverge. When they diverge, the advocate’s job is to fight for the developer’s needs. If they don’t—or can’t—they’re not advocates. They’re sales engineers with a better Twitter presence.

Signs You’re Reading Sales-Smelling Advocacy

Over years of evaluating tools and watching countless technical talks, I’ve developed a mental checklist. None of these are dealbreakers alone, but three or more in a single piece of content is a strong signal that you’re being sold to, not educated.

• No failure modes discussed. Every system has failure modes. If the content doesn’t mention any, it’s incomplete.
• Code examples lack error handling. Production code handles errors. Demo code that doesn’t is a red flag.
• Comparisons only with weaker competitors. If they compare against a strawman or a tool everyone knows is inferior, they’re not confident in a fair fight.
• No mention of versioning or deprecation policies. Real adopters care about API stability. If it’s not discussed, the content is targeting tire-kickers.
• Q&A is tightly controlled. Pre-screened questions, no live coding, no “let me try that right now” moments.
• Metrics are vanity numbers. “Over 10,000 developers signed up!” tells you nothing about how many built something useful.

I recently applied this checklist to a webinar from an API gateway company. Six out of six. The chat was disabled “due to the large audience.” The demo used a local mock server, not the actual product. The comparison page showed their gateway against a three-year-old version of a competitor. I closed the tab and moved on. Life’s too short for sales pitches disguised as education.

What Good Advocacy Demands

If you’re a developer advocate reading this and feeling defensive, I get it. The constraints are real. But here’s what I believe good advocacy demands, regardless of your reporting structure:

Push for a portfolio approach to content. Yes, you need the “Getting Started” pieces. But you also need the “When Things Go Wrong” pieces, the “Deep Dive on Our Architecture” pieces, and the “Honest Comparison with Competitor X” pieces. If your leadership resists the latter categories, that’s a conversation worth having. Frame it as developer trust infrastructure. The shallow content brings people in; the deep content makes them stay.

Show your scars. The most memorable technical talks I’ve seen included war stories—times the advocate’s own production system went down because of the very tool they were now representing. They explained what happened, how they fixed it, and what the engineering team changed to prevent it. That vulnerability didn’t weaken their message. It made them credible. Nobody trusts a surgeon who claims they’ve never lost a patient.

Write code that would pass review. Before publishing a tutorial, ask yourself: would I submit this code to my own team’s pull request process? If the answer is no, add the error handling, the edge case comments, the retry logic. Yes, it makes the tutorial longer. Yes, some beginners might find it intimidating. But beginners who are intimidated by proper error handling aren’t ready to use your product in production anyway. And senior developers—the ones who influence team adoption decisions—will notice and respect the thoroughness.

Advocate internally for the developers you serve externally. This is the part of the job that doesn’t show up in conference talks. When you hear the same complaint from five different community members, you need to bring that to your product team with the same energy you’d bring to a sales objection. “Our rate limiting is driving developers away” should carry as much weight as “we’re losing deals to Competitor X.” If your organization doesn’t treat those two statements as equally important, you have a structural problem that no amount of good content can fix.

The Long Game

Developer advocacy that feels like sales might hit its quarterly numbers. It might even look successful on a dashboard. But it’s building on sand. The developers who sign up from shallow content are the ones who churn fastest. The ones who would have become champions—who would have given conference talks about your product, written books about it, built businesses on it—they’re the ones who saw through the sales smell and walked away.

I’ve been on both sides of this. As a developer evaluating tools, I’ve learned to spot the difference between advocacy and marketing within the first few minutes of a talk or the first few paragraphs of a blog post. As someone who’s done advocacy work, I’ve felt the pressure to simplify, to smooth over, to close the deal. The pressure is real. But giving in to it is a betrayal of what the role claims to be.

The advocates I respect most are the ones who treat their community like a codebase: they refactor their content when it gets bloated with marketing-speak, they fix bugs in their tutorials when the API changes, and they never ship a feature—or a talk—without proper error handling. They understand that their reputation is the most valuable asset they have, and they protect it by being useful, not by being persuasive.

If you’re a developer reading this: be skeptical. Look for the error handling. Ask the hard questions. If the advocate dodges them gracefully, that’s still a dodge. If you’re an advocate reading this: your community needs you to be an engineer first and a promoter second. The sales team can handle the persuasion. Your job is to make sure that when a developer finally does sign up, they know exactly what they’re getting into—and they’re equipped to handle it when things go wrong.

FAQ

How can I tell if a developer advocate is genuinely technical or just performing?

Ask them to live-code a solution to a problem that’s slightly outside their prepared demo. Watch how they handle it. A genuinely technical advocate will engage with the problem, even if they don’t solve it perfectly on the spot. They’ll talk through their debugging process, show you their terminal history, or admit they need to look something up. A performer will redirect to a prepared slide or give a high-level answer that avoids the implementation details. Also, check their GitHub activity. Advocates who contribute code—to their own company’s repos or to the broader ecosystem—tend to be more technically grounded than those who only produce talks and blog posts.

Why do companies let advocacy become sales-y when it clearly backfires long-term?

Because the long-term backfire is diffuse and hard to measure, while the short-term metrics are concrete and easy to report. A VP can show a dashboard with 15,000 new sandbox sign-ups this quarter. They can’t easily show the 500 senior engineers who evaluated the product, found the advocacy content shallow, and quietly chose a competitor. Organizational incentives favor the measurable, even when the measurable is misleading. Changing this requires leadership that understands developer products specifically—not just SaaS metrics in general.

Should I avoid a product if its developer advocacy feels sales-y?

Not necessarily. The product itself might be excellent, and the advocacy team might be under pressures they can’t control. But you should adjust your evaluation process. Seek out third-party content: independent blog posts, conference talks by actual users, GitHub issues, Stack Overflow threads. If the official advocacy content is shallow, you’ll need to do more of your own research to understand the product’s real limitations and failure modes. If that independent content is also scarce or overly positive, that’s a stronger negative signal about the product and its community.

What’s the difference between a developer advocate and a sales engineer?

A sales engineer works with qualified prospects who are already in a purchasing process. Their goal is to prove the product fits the prospect’s specific requirements and to remove technical objections to closing a deal. A developer advocate works with a much broader audience, most of whom are not currently buying anything. Their goal is to educate, build trust, and help developers solve problems—sometimes with their company’s product, sometimes with alternatives. When an advocate starts behaving like a sales engineer—focusing on conversion, avoiding weaknesses, tailoring demos to close—they’ve crossed the line. The roles have different audiences, different time horizons, and different definitions of success.