developer-advocacy

When this skill is activated, always start your first response with the 🧢 emoji.

Developer Advocacy

Developer advocacy is the practice of representing developers inside a company and representing the company's technology to the developer community. It sits at the intersection of engineering, marketing, and education - requiring the ability to write working code, explain it clearly, and build authentic relationships with technical audiences. This skill covers the five core pillars: conference talks, live demos, technical blog posts, SDK examples, and community engagement.

When to use this skill

Trigger this skill when the user:

• Needs to write or review a conference talk proposal (CFP submission)
• Wants to plan or script a live coding demo
• Asks about writing a technical blog post or tutorial for developers
• Needs to create SDK quickstart examples or code samples
• Wants to build a community engagement strategy (forums, Discord, GitHub)
• Asks about developer experience (DX) improvements for an API or SDK
• Needs to plan a hackathon, workshop, or developer event
• Wants to measure DevRel impact with metrics and KPIs

Do NOT trigger this skill for:

• Pure marketing copy aimed at non-technical buyers - use a marketing or copywriting skill
• Internal engineering documentation with no external audience - use a technical writing skill

Key principles

1. Code is the message - Every piece of developer advocacy content must contain

working, copy-pasteable code. Developers trust what they can run. A blog post without a working example is a press release.

1. Empathy over evangelism - Advocate for the developer's needs, not just the

product's features. Acknowledge pain points honestly. Developers detect sales pitches instantly and disengage.

1. Show, don't tell - A 90-second demo that works is worth more than a 30-minute

slide deck. Prioritize live, interactive formats. When slides are necessary, use them to frame a problem - then solve it with code.

1. Meet developers where they are - Use the platforms, languages, and tools your

audience already uses. Don't ask a Python shop to read TypeScript examples. Don't post docs if your community lives on Discord.

1. Compound over campaign - A single blog post fades; a series builds authority.

A one-off talk is forgotten; a consistent conference presence builds reputation. Invest in content that compounds: evergreen tutorials, maintained SDKs, active community channels.

Core concepts

The DevRel flywheel

Developer advocacy works as a feedback loop: Build (SDKs, examples, tools) -> Educate (talks, blogs, tutorials) -> Engage (community, support, events) -> Listen (feedback, pain points, feature requests) -> feed learnings back into Build. Breaking any link in this chain reduces the entire function's effectiveness.

Content formats by funnel stage

| Stage | Goal | Formats | |-------|------|---------| | Awareness | Developers learn you exist | Conference talks, social posts, podcasts | | Evaluation | Developers try your tool | Quickstarts, blog tutorials, sandbox environments | | Adoption | Developers ship with your tool | SDK examples, API guides, Stack Overflow answers | | Retention | Developers stay and grow | Community channels, changelog updates, migration guides | | Advocacy | Developers recommend you | Champion programs, guest blog invitations, co-speaking |

Measuring DevRel impact

DevRel metrics fall into three tiers. Track all three but report the tier that matches your stakeholder's concern.

• Activity metrics (leading): talks given, posts published, PRs to SDK repos
• Reach metrics (middle): unique visitors, video views, GitHub stars, community members
• Business metrics (lagging): API signups from DevRel-attributed sources, SDK adoption rate, time-to-first-API-call

Common tasks

1. Write a conference talk proposal (CFP)

A strong CFP answers three questions: what will the audience learn, why should they care, and why are you the right person to teach it.

CFP template:

Title: [Action verb] + [specific outcome] + [constraint/context]
  Example: "Ship production WebSockets in 15 minutes with Durable Objects"

Abstract (max 200 words):
  Paragraph 1 - The problem (what pain does the audience feel?)
  Paragraph 2 - The approach (what will you show/build?)
  Paragraph 3 - The takeaway (what do they leave with?)

Outline:
  - [0:00-3:00]  Problem framing - why this matters now
  - [3:00-15:00] Live demo / core content (biggest block)
  - [15:00-22:00] Deep dive on the non-obvious part
  - [22:00-25:00] Recap + next steps + resources

Target audience: [Beginner | Intermediate | Advanced]
Prerequisites: [What should attendees already know?]
Format: [Talk | Workshop | Lightning talk]

Avoid vague titles like "Introduction to X" or "X in 2026". Reviewers see hundreds

of those. Lead with the outcome the audience gets.

2. Script a live coding demo

Live demos fail when they are too ambitious. Scope ruthlessly.

The 3-act demo structure:

1. Setup (30 seconds) - Show the starting state. "Here's an empty project /

a broken feature / a slow endpoint."

1. Build (3-5 minutes) - Write the code live. Narrate what you type and why.

Never type silently for more than 10 seconds.

1. Payoff (30 seconds) - Run it. Show the working result. Celebrate briefly.

Demo safety checklist:

• Pre-install all dependencies; never run npm install live
• Have a git branch with the finished state as a fallback
• Use large font (24pt minimum in terminal, 20pt in editor)
• Disable notifications, Slack, email, system popups
• Test on the exact hardware/display you will present on
• Record a backup video of the demo running successfully
• Use environment variables, never paste API keys on screen

3. Write a technical blog post

Structure for developer blog posts:

1. Hook (2-3 sentences)      - State the problem. Make it personal.
2. Context (1 paragraph)     - Why this problem exists / why now
3. Solution overview          - One sentence: what you will build
4. Step-by-step walkthrough  - Numbered steps with code blocks
5. Complete example           - Full working code (copy-pasteable)
6. What's next               - Links to docs, repo, community

Writing rules:

• Lead with the problem, not the product
• Every code block must be runnable in isolation or clearly marked as a snippet
• Use second person ("you") not first person ("we")
• Keep paragraphs to 3-4 sentences maximum
• Include a "Prerequisites" section if the reader needs accounts, keys, or tools
• Add a TL;DR at the top for scanners

4. Create SDK quickstart examples

Quickstarts must get a developer from zero to a working API call in under 5 minutes. Anything longer and they leave.

Quickstart structure:

## Prerequisites
- Language runtime version (e.g., Node.js >= 18)
- API key (link to signup/dashboard)

## Install
<single install command>

## Authenticate
<2-3 lines showing how to set the API key>

## Make your first call
<5-15 lines of code that do something visible>

## Next steps
- [Link to full API reference]
- [Link to more examples]
- [Link to community/support]

Rules for code samples:

• Use the most common language for your audience first (JavaScript/Python)
• Show the import, setup, and call - never skip the import
• Use realistic values, not foo/bar - e.g., "acme-corp", "order_12345"
• Handle errors in examples; don't just show the happy path
• Pin SDK versions in install commands

5. Build a community engagement strategy

Channel selection framework:

| Channel | Best for | Effort | Response time | |---------|----------|--------|---------------| | GitHub Discussions | Long-form Q&A, RFCs | Medium | 24 hours | | Discord / Slack | Real-time help, casual chat | High | < 1 hour | | Stack Overflow | SEO-visible answers | Low |