Plan and Execute Developer Advocacy Campaigns
A developer advocacy skill for conference talks, live coding demos, podcast guesting, building in public, and measuring impact.
Why it matters
Help developer advocates and DevRel professionals plan, prepare, and execute high-impact advocacy activities including conference talks, live coding demos, podcast appearances, and building-in-public campaigns that reach and engage technical audiences.
Outcomes
What it gets done
Write compelling conference talk proposals (CFPs) with proven title patterns, abstracts, and outlines
Prepare live coding demos with checkpoint systems, backup plans, and pre-demo checklists
Craft podcast pitch emails and prep talking points for guest appearances
Create building-in-public content strategies with platform-specific formats and posting cadences
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-developer-advocacy | bash Overview
Developer Advocacy
This skill covers developer advocacy: CFP proposals and talk prep, live coding demo risk mitigation, podcast guesting pitches, building-in-public content strategy, social presence, and measuring advocacy impact via proxy metrics. Use it for conference talks, CFPs, live coding, podcast guesting, building in public, or measuring developer advocacy impact.
What it does
This skill covers developer advocacy activities - conference talks, live coding demos, podcast appearances, and building in public - plus measuring their impact, loading an audience-context file first to know who to reach and what resonates. Conference talks are matched to venue type, from large industry conferences for reach to niche conferences for targeted expertise. CFP proposals follow a specific-problem-plus-unique-angle-plus-clear-takeaways formula and a fixed template covering title, abstract, detailed description, timed outline, audience and prerequisites, and bio, with proven title patterns and talk-type-to-length matching from five-minute lightning talks through multi-hour workshops. A prep timeline runs from outlining two months out through arriving early and testing audio-visual gear on the day.
Live coding and demos cover risk mitigation - a pre-recorded backup for internet failure, practiced typing to avoid freezing on a typo, checkpoint commits to jump to if stuck, timed cuts to avoid running over, and a high-contrast, large-font setup for projector visibility - through a ten-three-one rule of running the demo ten times, keeping three jump-to checkpoints, and having one backup recording, plus a pre-demo checklist covering closed apps, cleared tabs, disabled notifications, and a tested environment. Live-coding delivery favors typing slowly, narrating intent, explaining errors as they happen, using snippets only for boilerplate, and always showing the running result.
Podcast guesting covers finding shows through direct search, guest-matching networks, peer recommendations, and podcast search engines, a pitch template referencing a specific past episode and proposing a specific angle with credentials, pre-podcast prep including researching the host and prepping specific stories rather than generalities, do's and don'ts during the recording such as specific stories over generic advice and subtle promotion over a hard sell, and post-podcast follow-through covering same-day thanks, immediate sharing, and ongoing relationship building.
Building in public covers what to share - progress, challenges, decisions, transparent metrics, behind-the-scenes, and honest learnings - across formats matched to cadence, from daily tweet threads to weekly changelogs and newsletters, and what never to share, such as customer data, team conflicts, security details, or competitor attacks. Social presence guidance for developer-focused platforms allocates content by percentage, mostly value content with smaller shares for engagement, personal posts, and promotion, lists proven post formats like threads, hot takes, quick tips, and showcases, and recommends growing presence through consistency, niching down to one thing first, and adding value in others' replies before self-promoting.
Measuring impact tracks talks, content, social, podcasts, and community metrics, acknowledging attribution is notoriously hard and relying on proxy signals like traffic spikes, direct attribution responses, social mentions, and conference invites, rolled into a monthly reporting template covering appearances, content published, social growth, community activity, and explicit learnings on what worked and what's next. An advocacy career ladder runs from junior developer advocate through head of DevRel, with specific skill-development paths for public speaking, writing, video, technical depth, and community building, plus a tool list for brand monitoring, scheduling, streaming, editing, and social scheduling.
When to use - and when NOT to
Use it for developer advocacy activities - conference talks, CFPs, live coding, podcast guesting, or building in public - and for measuring their impact.
Inputs and outputs
Given an advocacy goal such as a talk, a podcast pitch, a public-building cadence, or a reporting need, it produces a matched template - a CFP submission, a demo-prep checklist, a podcast pitch, a content calendar, or a monthly advocacy report.
Integrations
Brand-monitoring, scheduling, streaming, editing, and social-scheduling tools, plus related skills for audience context, written devrel content, community building, open-source marketing, and Hacker News strategy.
Who it's for
Developer advocates and DevRel practitioners running conference talks, podcast appearances, or public-building programs who want proven templates and checklists rather than starting each activity from scratch.
Source README
Developer Advocacy
When to Use
Use this skill when you need when the user wants to do developer advocacy activities including conference talks, live coding, podcasts, and building in public. Trigger phrases include "developer advocacy," "devrel," "conference talk," "CFP," "call for papers," "live coding," "podcast," "building in public,"...
This skill helps you with developer advocacy activities: conference talks, live coding demos, podcast appearances, and building in public. Covers talk proposals, demo prep, social presence, and measuring impact.
Before You Start
Load your audience context first. Read .agents/developer-audience-context.md to understand:
- Who you're trying to reach (conferences they attend, podcasts they listen to)
- What topics resonate (pain points, interests)
- Your product's positioning (what story to tell)
- Voice & tone (how formal/technical to be)
If the context file doesn't exist, run the developer-audience-context skill first.
Conference Talks
Finding the Right Conferences
| Conference Type | Best For | Examples |
|---|---|---|
| Large industry | Brand awareness, reach | KubeCon, AWS re:Invent, React Summit |
| Regional | Local community, accessible | Local meetups, city tech conferences |
| Niche | Targeted audience, expertise | GraphQL Conf, RustConf |
| Company-hosted | Ecosystem presence | Vercel Ship, GitHub Universe |
| Unconferences | Community connection | BarCamps, DevOpsDays |
Talk Proposal (CFP) Framework
The winning formula:
Specific Problem + Unique Angle + Clear Takeaways = Accepted Talk
CFP Template:
### Title
[Action verb] + [specific outcome] + [with/using what]
Example: "Building Real-Time Features with Edge Functions and WebSockets"
### Abstract (100-200 words)
[Hook: Problem or curiosity gap]
[What you'll cover]
[What attendees will learn/be able to do]
### Description (detailed, for reviewers)
[Problem context]
[Why this approach]
[Talk structure]
[Your credibility to give this talk]
### Outline
- [Time] Introduction / Problem statement
- [Time] Section 1
- [Time] Section 2
- [Time] Section 3
- [Time] Live demo / walkthrough
- [Time] Key takeaways / Q&A
### Audience
[Who this is for]
[Prerequisite knowledge]
[What they'll learn]
### Bio
[Your relevant experience]
[Why you're qualified]
Title Patterns That Work
| Pattern | Example |
|---|---|
| How I X | "How I Reduced Deploy Time by 80%" |
| X in Y Minutes | "Kubernetes Security in 15 Minutes" |
| The X of Y | "The Psychology of Error Messages" |
| Beyond X | "Beyond Console.log: Modern Debugging" |
| X for Y | "GraphQL for REST Developers" |
| Lessons from X | "Lessons from 1000 Production Outages" |
Talk Types
| Type | Length | Best For |
|---|---|---|
| Lightning | 5-10 min | Single concept, quick demo |
| Standard | 25-45 min | Technical deep-dive |
| Keynote | 45-60 min | Big picture, inspiring |
| Workshop | 2-4 hours | Hands-on learning |
| Panel | 30-60 min | Discussion, multiple perspectives |
Talk Prep Checklist
| Phase | Tasks |
|---|---|
| 2 months before | Outline, start slides, test demos |
| 1 month before | Draft complete, first practice run |
| 2 weeks before | Slides polished, demos solid, practice 3x |
| 1 week before | Record yourself, get feedback, finalize |
| Day before | Test all tech, backup slides, rest |
| Day of | Arrive early, test A/V, hydrate |
Live Coding & Demos
The Demo Danger Zone
| Risk | Mitigation |
|---|---|
| Internet fails | Pre-record backup, local server |
| Typo freezes you | Practice typing same code 20x |
| Error you can't fix | Have working checkpoints to jump to |
| Runs over time | Time yourself, cut ruthlessly |
| Code too small | Zoom in, use large font (24pt+) |
| Dark theme blinding | Use high-contrast, light-friendly theme |
Demo Prep Framework
The 10-3-1 Rule:
- Run your demo 10 times in practice
- Have 3 checkpoints you can jump to if stuck
- 1 backup (video recording of it working)
Pre-demo checklist:
- Close unnecessary apps
- Clear browser history/tabs
- Notifications OFF (Slack, email, calendar)
- Font size: 24pt+ for terminal, 20pt+ for editor
- Git stash/branch for clean starting point
- Environment variables ready
- Test on the actual projector/screen if possible
Live Coding Tips
| Tip | Why |
|---|---|
| Type slowly | Audience needs to follow |
| Narrate what you type | "I'm creating a new handler..." |
| Explain errors | "This error means X, let me fix it" |
| Use snippets | For boilerplate, not core concepts |
| Show the result | Always run the code, show output |
| Checkpoint commits | git checkout checkpoint-1 |
Podcast Guesting
Finding Podcasts
| Approach | How |
|---|---|
| Direct search | "top [your tech] podcasts" |
| Guest networks | Podmatch, Matchmaker.fm |
| Peer asks | "What podcasts do you listen to?" |
| Twitter search | "[topic] podcast episode" |
| Listen Notes | Podcast search engine |
Pitch Template
Subject: Guest Idea: [Specific Topic] for [Podcast Name]
Hi [Host Name],
I've been listening to [Podcast] for [time] — loved your episode on [specific episode].
I'd love to come on and talk about [specific topic]. Here's the angle:
[2-3 sentences on what you'd discuss and why it matters to their audience]
A bit about me:
- [Relevant credential 1]
- [Relevant credential 2]
- [Link to past podcast/talk]
Would this be a fit?
[Your name]
Pre-Podcast Prep
| Prep Item | Details |
|---|---|
| Research the show | Listen to 2-3 episodes, understand format |
| Research the host | Their interests, style, Twitter |
| Prep talking points | 3-5 main things you want to say |
| Prep stories | Specific examples, not generalities |
| Audio setup | Good mic, quiet room, headphones |
| Water nearby | You'll be talking a lot |
During the Podcast
| Do | Don't |
|---|---|
| Tell stories with specifics | Give generic advice |
| Pause before answering | Um and ah nervously |
| Disagree respectfully | Always agree to be polite |
| Promote subtly | Hard sell your product |
| Be concise | Ramble without structure |
| Show enthusiasm | Be monotone |
Post-Podcast
| Action | Timing |
|---|---|
| Thank the host | Same day |
| Share when published | Immediately |
| Engage with comments | First week |
| Cross-promote | Your newsletter, blog |
| Stay in touch | Ongoing relationship |
Building in Public
What to Share
| Category | Content Ideas |
|---|---|
| Progress | "Shipped X today, here's what I learned" |
| Challenges | "Stuck on X, tried Y and Z, here's what worked" |
| Decisions | "Why we chose X over Y" |
| Metrics | Revenue, users, growth (transparently) |
| Behind scenes | Team, process, tools |
| Learnings | "Mistake we made and how we fixed it" |
Build in Public Formats
| Format | Platform | Cadence |
|---|---|---|
| Tweet thread | Twitter/X | Daily-weekly |
| Changelog | Blog, Notion, website | Weekly |
| Indie hacker posts | Indie Hackers, HN | Monthly |
| Video update | YouTube, Loom | Weekly-monthly |
| Newsletter | Weekly | |
| Livestream | Twitch, YouTube | Weekly |
What NOT to Share
| Avoid | Why |
|---|---|
| Customer data | Privacy, trust |
| Team conflicts | Professionalism |
| Security details | Vulnerability |
| Competitor attacks | Looks petty |
| Venting | Not productive |
Social Presence (Twitter/X)
Developer Twitter Playbook
| Content Type | % of Posts | Example |
|---|---|---|
| Value content | 60% | Tips, tutorials, insights |
| Engagement | 20% | Replies, retweets with commentary |
| Personal | 10% | Behind-the-scenes, personality |
| Promotion | 10% | Your product, talks, content |
Tweet Formats That Work
| Format | Example |
|---|---|
| Thread | "10 things I learned building X" |
| Hot take | "Unpopular opinion: [opinion]" |
| Quick tip | "TIL: You can do X by..." |
| Question | "What's your favorite way to..." |
| Meme/humor | Tech jokes, relatable content |
| Showcase | "Just shipped X, here's how it works" |
| Appreciation | "Shoutout to @person for..." |
Engagement Strategy
| Action | Frequency |
|---|---|
| Tweet original content | Daily |
| Reply to others | 5-10x daily |
| Quote tweet with value | 2-3x weekly |
| DM interesting people | Weekly |
| Join Twitter Spaces | As relevant |
Growing Your Presence
| Tactic | Implementation |
|---|---|
| Consistency | Post daily, engage daily |
| Niche down | Be known for ONE thing first |
| Reply game | Add value to big accounts' tweets |
| Collaborate | Twitter Spaces, threads together |
| Cross-promote | Newsletter, talks, blog |
Measuring Impact
Advocacy Metrics
| Activity | Metrics |
|---|---|
| Talks | Attendees, feedback scores, recording views |
| Content | Views, shares, engagement |
| Social | Followers, engagement rate, reach |
| Podcasts | Listener estimates, traffic spikes |
| Community | Growth, engagement, sentiment |
Attribution Challenges
Developer advocacy impact is notoriously hard to measure. Proxy metrics:
| Signal | What It Indicates |
|---|---|
| Traffic spikes | Content/talk/podcast drove visits |
| "How did you hear about us?" | Direct attribution |
| Social mentions | Brand awareness |
| Inbound leads quality | Community-qualified leads |
| Conference invites | Growing reputation |
Reporting Framework
Monthly advocacy report:
### Developer Advocacy Report - [Month]
### Talks & Appearances
- [Talk 1]: [Conference], [Attendees], [Link]
- [Podcast 1]: [Show], [Episode link]
### Content Published
- [Article 1]: [Views], [Engagement]
- [Video 1]: [Views]
### Social Growth
- Twitter: +X followers, Y impressions
- Notable tweets: [Links]
### Community
- Discord/Slack: +X members, Y messages
- Notable threads/discussions
### Learnings
- What worked: [X]
- What didn't: [Y]
- Trying next: [Z]
Advocacy Career Path
Role Levels
| Level | Focus |
|---|---|
| Junior DA | Content creation, community support, talk prep |
| Developer Advocate | Talks, own content strategy, community building |
| Senior DA | Strategy, mentoring, major conferences |
| Staff DA | Cross-company impact, industry thought leadership |
| Head of DevRel | Team building, strategy, executive alignment |
Skill Development
| Skill | How to Develop |
|---|---|
| Public speaking | Meetups, Toastmasters, practice |
| Writing | Blog consistently, get feedback |
| Video | YouTube, live streaming, improve iteratively |
| Technical depth | Build projects, contribute to OSS |
| Community | Moderate, organize events, connect people |
Tools
| Tool | Use Case |
|---|---|
| Octolens | Monitor your name/brand across GitHub, Twitter, Reddit, HN, Stack Overflow. Track conference mentions. Find podcast opportunities. Measure share of voice. |
| Cal.com / Calendly | Schedule podcast appearances |
| StreamYard | Live streaming setup |
| Descript | Video/podcast editing |
| Canva / Figma | Slides and graphics |
| Otter.ai | Transcription for talks |
| Notion | Talk prep, content calendar |
| Buffer / Typefully | Social scheduling |
Related Skills
developer-audience-context- Know who you're reachingdevrel-content- Written content strategycommunity-building- Community managementopen-source-marketing- OSS-specific advocacyhacker-news-strategy- HN engagement
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.