samber/developer-relations-skills已通过检查
SKILL DETAIL
devrel-strategy
samber/developer-relations-skills/devrel-strategy
Designs a company's developer relations program from the top - the business driver that funds it, the two goals it is allowed to serve, the pillar mix (advocacy, marketing, enablement, community) for its stage, audience priority, build-vs-buy per bet, staffing sequence, and a written refused list. Use whenever someone asks whether to start doing DevRel, what a new devrel program should do first, why devrel work is busy but not landing, how to justify the program to an exec, which pillar deserves the next investment, who to hire next, or whether to outsource content, events or community - even if they never say "strategy". Not the first-90-days plan - use samber/developer-relations-skills@developer-relations-kickoff. Not metrics, org chart or budget math.
安装量 · 423查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill devrel-strategy
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "devrel-strategy",
"evals": [
{
"id": 1,
"prompt": "I'm the first DevRel hire at Tesserine, a payments-reconciliation API, Series A, 22 people. I have to put the program together before the January board meeting. I found the number that DevRel teams put 41% of spend into events, 31% into salaries, 19.5% into content and 13% into marketing, so I've drafted our plan to mirror that split: roughly $180k of our $440k into two big conference booths. Our sponsor is the VP of Engineering and he wants developer adoption. Sanity-check this and write it up properly.",
"expected_output": "A response that refuses the circulating spend split as a benchmark, explains exactly why the figure is unusable as a target, runs CORE before proposing anything, and names the funded driver and its owner.",
"files": [],
"expectations": [
"Refuses to treat the 41.1% / 30.9% / 19.5% / 13.0% spend split as a benchmark or target for Tesserine's plan.",
"States that the split's shares sum to about 104.5%, because respondents answered on inconsistent bases.",
"States that only about 47 respondents saw the spend-split question.",
"Names at least two categories the split omits entirely from among community, tooling and education.",
"Attributes the survey figures to State of Developer Relations 2024 by DevRel.Agency, with 310 respondents.",
"Permits the split to be cited as history, as evidence that events have dominated DevRel spend.",
"Says a plan proposing a non-events-dominant split is a deliberate departure worth arguing, not a mistake.",
"Warns that an exec who checks the 41% figure would discredit the whole charter.",
"Does not deliver a percentage budget allocation across pillars as the deliverable, and routes the money split to samber/developer-relations-skills@devrel-budget-allocation.",
"Writes the four CORE paragraphs (Community, Organization, Relationships, Ecosystem) before proposing any pillar, hire or channel.",
"Names developer adoption as the primary funded driver and the VP of Engineering as its named owner.",
"Keeps quoted survey figures visibly separate from any figure the response sets itself, labelling the latter a starting baseline."
]
},
{
"id": 2,
"prompt": "Halvard Systems sells an observability agent, about $9M ARR. Our CTO wants our developer relations program to look like the big observability vendors': developer advocacy, developer marketing, developer enablement and community, each properly resourced. Today it's two people, me plus a backend engineer who gives it maybe 12 hours a week. I've split the effort 25/25/25/25 and drafted a hiring plan for four specialists over the next 12 months, with a proposed reporting structure. What do you think?",
"expected_output": "A response that rejects the even four-pillar split, cites team-size evidence, names the starved pillars, replaces the twelve-month hiring plan with a next capability and trigger, and hands org design off.",
"files": [],
"expectations": [
"Refuses the 25/25/25/25 split and states that at most two pillars are funded above token level at seed or grow stage.",
"Labels the two-pillar cap as this skill's own starting baseline rather than a published industry standard.",
"States that two pillars funded properly beat four funded at 25%, because most devrel work pays off only past a threshold of consistency.",
"Names in writing which pillars are funded and which are deliberately starved.",
"Cites that 2-5 people is the most common DevRel team-size band at 35.2%.",
"Cites that 69% of DevRel teams are under ten people.",
"Attributes the team-size figures to State of Developer Relations 2024 (DevRel.Agency, 310 respondents).",
"Identifies copying a large company's pillar mix as a named failure mode, because it presupposes leverage programs and a brand Halvard does not have.",
"Writes the four CORE paragraphs before proposing a pillar mix.",
"Names the lifecycle stage the CORE answers imply, as starting, growing or established.",
"Replaces the twelve-month four-specialist plan with the next capability and the trigger that justifies it.",
"Does not produce reporting lines, ratios or an org chart, and routes team topology to samber/developer-relations-skills@devrel-team-structure."
]
},
{
"id": 3,
"prompt": "Quillard runs a hosted build-cache service. Our CEO wants proof the DevRel investment works by the end of this quarter, ten weeks from now, at the Q4 board meeting, or the headcount gets cut. I'm the only DevRel person. I have $60k of program budget and I want to put most of it into a content agency to get 15 technical articles out fast, because I can't write 15 myself. Signups are healthy but only about a fifth of new accounts ever run a second build. What should the program be?",
"expected_output": "A response that deletes the agency option on latency grounds, treats the second-build drop-off as an activation leak, and recommends enablement-first with in-house bets inside the ten weeks.",
"files": [],
"expectations": [
"Deletes the agency option outright rather than ranking it last, because the first result is due inside one quarter.",
"States that an agency pipeline costs roughly six months of the lead's own time to build before the first output.",
"States the agency's per-piece latency at roughly eight to nine weeks once the pipeline exists.",
"States that budget cannot rescue the agency option, because the setup latency does not shrink with money.",
"Recommends enablement-first as the program shape given the ten-week deadline.",
"Identifies the second-build drop-off as an activation problem rather than an awareness problem.",
"Applies the rule that an activation leak is fixed before reach is increased, whatever the efficiency ratio says.",
"States that reach-first is the wrong pick while onboarding leaks, because reach into a broken activation path burns the audience once.",
"Notes that in-house and community-sourced are the options that remain for a team of one at this budget line.",
"Establishes whether the CEO wants a one-off win inside the horizon or a compounding asset.",
"Names time-to-first-success work, troubleshooting and error coverage, or tested code samples among the first bets.",
"Commits one signal per bet rather than building a measurement framework here."
]
},
{
"id": 4,
"prompt": "Bracknell Data, vector database, Series B, DevRel team of four and we are drowning. My plan to get leverage: hand our Discord first-line moderation and all our community answers to a contracted community agency, have that same agency ghostwrite our two advocates' blog posts under their own bylines so output triples, and let them draft the status-page updates during an outage so the advocates stop getting paged. Design the sourcing plan around that. Budget is not the constraint, advocate hours are.",
"expected_output": "A response that deletes every red-line item from the sourcing menu, offers the documented split-ownership agency pattern instead, and records a named reviewer per bought bet.",
"files": [],
"expectations": [
"Deletes outsourcing of the advocate's byline, voice and stage presence rather than offering it as a cheaper option.",
"Deletes outsourcing of incident, outage and breaking-change communication.",
"Deletes outsourcing of moderation and code-of-conduct enforcement decisions.",
"Deletes outsourcing of community answers that carry the company's name.",
"States that technical trade-off calls and any claim about what the product cannot do stay in-house.",
"Applies the test that if a developer discovering a vendor wrote it would feel misled, it is a red line.",
"States the rule as renting volume, never credibility.",
"Offers the documented split-ownership pattern instead: the advocate writes the outline and reviews the result while the agency produces the body.",
"Attributes that pattern to Matt Jarvis, Director of Developer Relations at Snyk.",
"Distinguishes contracted first-line community triage, which is workable, from ownership of the moderation decisions, which stays in-house.",
"Records a named reviewer for every bought bet, and states that a build-versus-buy line without one is the line that fails.",
"Does not put partner or sponsored placement on the build-versus-buy menu, and routes sponsorship to samber/developer-relations-skills@developer-event-sponsorship."
]
},
{
"id": 5,
"prompt": "Here is our DevRel plan for H1 at Ormont Labs, we make an edge functions runtime. Goals: build awareness, grow the community, support sales, improve the docs, gather product feedback and strengthen our employer brand. Plan: two blog posts a month, speak at four conferences, launch a Discord, refresh the documentation, a monthly livestream, two hackathons, and a swag store. Team: hire a community manager and a developer advocate in Q3. Metrics: blog views, Discord members, conference attendees, GitHub stars, social followers. Tighten this up for me.",
"expected_output": "A response that names the activity-list failure, reduces six goals to two primary plus one secondary pinned to journey steps with observed drop-offs, and writes a refused list.",
"files": [],
"expectations": [
"Identifies the plan as an activity list rather than a strategy, and does not repair it by trimming the activity list.",
"Names one primary funded driver from the seven-driver list: developer adoption, sales enablement, developer enablement, product input, ecosystem and partnerships, contributor community, employer brand.",
"Names one secondary driver, and names the person who owns the primary driver or flags that no owner has been supplied.",
"Caps goals at two primary plus one secondary.",
"Uses the AAARRRP goal vocabulary: awareness, acquisition, activation, retention, referral, revenue, product.",
"Attributes AAARRRP to Phil Leggetter.",
"Pins each goal to a specific developer-journey step among initial awareness, deep awareness, evaluation, commitment, standardization and advocacy.",
"States that a goal with no observed drop-off behind it is a preference, not a goal.",
"States that a program claiming every goal scores every candidate activity identically, so effort follows whoever asks loudest.",
"Replaces the two named Q3 hires with a next capability plus the trigger that justifies it.",
"Flags the proposed metrics as counts of hits rather than developer behaviour.",
"Produces a non-empty refused list containing at least one item the team wanted to do."
]
},
{
"id": 6,
"prompt": "Vasterly sells a self-hosted workflow engine. About 4,000 companies run it and renewal rate is the thing the board actually cares about. Our chair was explicit at the last meeting: she does not want a number this quarter, she wants something worth more in three years than the money we put in. I have two people plus real budget. Every framework I have read says start with documentation and quickstarts because that is the cheapest win. Tell me what to build.",
"expected_output": "A response that promotes community-first over the default efficiency order on the strength of the compounding mandate and installed-base retention, and funds it properly rather than at token level.",
"files": [],
"expectations": [
"Recommends community-first as the primary shape rather than following the default efficiency order to enablement-first.",
"Names the mandate as compounding rather than a one-off win, and ties the promotion explicitly to that answer.",
"States that the efficiency order ranks community-first second-to-last, and explains that a ratio is computed inside a horizon that ends before community-first returns.",
"States that community-first outranks reach-first on value while losing to it on efficiency.",
"Names retention of an installed base as a driver under which community-first is promoted.",
"Warns that funding a community at roughly a quarter of a standing job is worse than not starting one.",
"Funds community-first as the primary and starves the efficient shapes, rather than running both at once.",
"Names the wrong-pick condition for community-first: a user base too small or too asynchronous to reach conversational density.",
"Promotes community-sourced on the build-versus-buy menu once community-first is the funded primary.",
"States that the contributor licence or DCO decision must be in place before the first community contribution, and that it is the least reversible commitment on the menu.",
"Names the fastest signal for community-first as questions answered by someone other than staff, and the founding cohort's week-four return rate."
]
},
{
"id": 7,
"prompt": "Klaverton ships an API for document parsing. Roughly 60% of revenue comes from individual developers on our self-serve tier and 40% from about 30 enterprise accounts where a security reviewer signs off. I want to know which of those two audiences is the more efficient one to serve. Give me the value-per-effort ranking so I can split our DevRel hours proportionally between them.",
"expected_output": "A response that refuses to rank the two adoption paths on any efficiency axis, picks one primary path for the horizon, names who is not served, and lists the artefacts that serve both.",
"files": [],
"expectations": [
"Refuses to rank individual-developer adoption against company adoption on an efficiency, value or effort axis.",
"States the reason for that refusal: the path is set by who signs the purchase, so ranking by cost would be false precision.",
"Establishes who signs the purchase as the deciding input.",
"Picks exactly one adoption path as primary for this horizon instead of splitting hours proportionally.",
"Names the one segment inside that path the program serves first.",
"Names in writing who the program is not serving yet.",
"Names artefacts that serve both paths so they are built once, from among quickstart, reference documentation, changelog and migration guides, and honest limitations.",
"Names artefacts that serve company adoption only, such as security questionnaires, procurement-ready licensing or named production references.",
"States the company-adoption investments: reference architectures, security and licensing clarity, migration and support paths, named production references.",
"States that success under company adoption shows up as evaluations that survive review, while individual adoption shows up as usage before revenue.",
"Routes deeper segmentation, seniority or buyer-persona work to samber/developer-relations-skills@developer-segmentation rather than producing it here."
]
},
{
"id": 8,
"prompt": "Perrix, managed Postgres branching. We have grown the DevRel function from one person to six over 18 months and my VP wants a 12-month org chart from me by Friday: roles, reporting lines, ratios, who sits under whom. My instinct is community manager next, then two advocates, then a developer educator, and we would move the whole team out of marketing into product. Also give me the leverage programs we should launch. I am thinking a contributor program to get outside help on our CLI.",
"expected_output": "A response that refuses the org chart, states only the next capability and its trigger, and orders scale-stage leverage with contributor programs last.",
"files": [],
"expectations": [
"Refuses to produce a twelve-month org chart, and states only the next capability and the trigger that justifies it.",
"Routes reporting lines, role ratios and team topology to samber/developer-relations-skills@devrel-team-structure.",
"Uses the seed, grow and scale stage vocabulary.",
"Attributes that stage vocabulary to Phil Leggetter.",
"Applies Leggetter's scaling test: a team is only scaling if further investment increases output more than it increases input.",
"Orders scale-stage leverage as champion and ambassador programs, then community-run events, then paid write-for-us pipelines, then contributor programs.",
"Places the contributor program last in that order rather than first as the user proposed.",
"States that contributor programs land last because they spend maintainer hours nobody can backfill.",
"States that champion programs multiply an asset the company already owns, because they recognise people already advocating.",
"Warns that every leverage program still consumes in-house review, usually the same bottleneck the leverage was meant to relieve.",
"Names Leggetter's cost of specialising at grow stage: losing people who liked being generalists unless they can keep contributing outside their specialization.",
"Derives the staffing sequence from the friction found when goals were set, rather than from a standard team template."
]
},
{
"id": 9,
"prompt": "I need the actual document. Saltmere is Series A, we sell an SDK for on-device speech models. I am the DevRel lead, one advocate reports to me, and our CRO funds us because the sales team keeps losing deals at the technical evaluation. Board review is in eleven weeks. I have about 70 hours a month of real capacity across the two of us. Write me the whole developer relations strategy document in one go so I can drop it into the board pack.",
"expected_output": "A charter built section by section with agreement gates, all twelve headings, three to five bets each with owner, signal and review date, a capacity check, and an explicit quality-gate report.",
"files": [],
"expectations": [
"Presents the charter one section at a time and seeks agreement before writing the next, rather than delivering the whole document in one pass.",
"Produces a charter with all twelve headings: Position, Driver, Goals, Audience, Pillar mix, Bets, Build vs buy, Staffing, Refused, Open questions, Exec narrative, Review.",
"Keeps the charter to one to two pages rather than a long strategy document.",
"Funds between three and five bets, no more.",
"Traces every bet to exactly one primary goal, and gives each bet an owner, one signal and a review date.",
"Commits at most 70% of the stated 70 hours a month, leaving the rest for support load, launches and the unplanned.",
"States that a charter failing the capacity line has one bet too many rather than a discipline problem.",
"Writes an exec narrative of five sentences that uses no devrel jargon.",
"Produces a non-empty refused list that includes at least one thing the team wanted to do.",
"Writes open questions down honestly instead of resolving them by assumption.",
"Reports the quality-gate check explicitly at the end.",
"Separates the structural gate lines from the numeric baseline lines, and says which numeric baselines it moved and why.",
"Names sales enablement as the funded driver with the CRO as its named owner, phrased in the funder's language.",
"Recommends evaluation-support as the fitting archetype, given deals stalling at technical evaluation."
]
},
{
"id": 10,
"prompt": "Hestbury builds a compliance-automation platform with a public API. Two constraints you should know: our product roadmap is locked through next year, the team took a huge enterprise commitment and nothing new gets in, and our founder has said flatly he will never run a Discord or Slack of our own because he thinks they become support queues. We fund DevRel for developer enablement, partners keep filing tickets our docs should have answered. Give me the plan, and a KPI dashboard with the ten metrics we will report monthly.",
"expected_output": "A response that brainstorms two or three whole-program candidates, deletes the two shapes the constraints rule out, presents survivors on the same six facts, and hands the metric set off.",
"files": [],
"expectations": [
"Builds two or three whole-program candidates rather than a single plan.",
"Announces it is in brainstorming mode and writes no plan during that step.",
"Deletes product-feedback from the candidate set because the roadmap is fixed for a year.",
"Deletes community-first from the candidate set because the founder refuses to run a venue of its own.",
"Deletes ruled-out shapes from the candidate set instead of ranking them last, and says why: a ruled-out shape parked at the bottom returns as scope in month two.",
"Presents each surviving candidate with the same six facts: the pillar it over-invests in, its first three bets, what it deliberately starves, the capacity it needs, the fastest signal that it is working, and the condition that makes it the wrong pick.",
"Recommends the highest-ranked survivor and says why.",
"Lets the program owner choose the shape before detailing hires or channels.",
"Recommends enablement-first, given the developer-enablement driver and partner questions the documentation should have answered.",
"Commits one signal per bet rather than producing a ten-metric monthly dashboard.",
"Routes the measurement framework to samber/developer-relations-skills@devrel-metrics.",
"Records the locked roadmap and the refusal to run a venue on the written refused list."
]
},
{
"id": 11,
"prompt": "Quick one. Dunmoor is a 40-person company selling a scheduling API. Do we hire a community manager next, or outsource the blog to an agency? Our DevRel today is me, head of product, maybe 4 hours a week on it, plus two backend engineers who write a post when they feel like it. Finance gave me a number but I honestly do not know whether it includes my salary. Just tell me which one.",
"expected_output": "A response that declines to answer the isolated hire-versus-outsource question, starts the interview one question at a time, and rules out the standing-job option on the effort ceiling.",
"files": [],
"expectations": [
"Declines to answer the isolated hire-versus-outsource question first, and starts at the interview because the question is a funding-driver question in disguise.",
"Asks one question at a time rather than delivering a batched questionnaire.",
"Asks who owns the budget and whether the number includes salaries, rather than treating that as administrative detail.",
"Cites that 60% of DevRel program budgets exclude salaries.",
"Cites that 33.5% of practitioners cannot state their program's budget, and a further 17.8% have no set budget.",
"Asks by what date the first result must be visible and to whom.",
"Asks whether the funder wants a one-off win inside the horizon or a compounding asset.",
"Asks what the effort ceiling is, in weekly hours from people with other jobs, headcount that can actually be added, and how reversible the commitment must be.",
"States that an effort ceiling made of spare hours from people with other jobs deletes every shape that needs a standing job.",
"Rules out the community manager hire on that basis rather than weighing it evenly against the agency.",
"Treats more than one team doing devrel-shaped work as the normal starting condition, citing 43.6%.",
"Records the driver, stage, audience priority, refused list, deadline, one-off-versus-compounding mandate and effort ceiling for reuse, gated on the harness having persistent memory."
]
}
],
"trigger_queries": [
{ "query": "Should we even be doing DevRel at this stage, and what would we do first?", "should_trigger": true },
{ "query": "Write me a developer relations charter for our API company.", "should_trigger": true },
{ "query": "Our devrel team ships constantly and nobody can say what it is for.", "should_trigger": true },
{ "query": "The CFO is asking why we fund two developer advocates. Build me the argument.", "should_trigger": true },
{ "query": "Do we hire a community manager next, or outsource the blog?", "should_trigger": true },
{ "query": "which devrel pillar deserves the next investment", "should_trigger": true },
{ "query": "We are a Series A API company with one advocate. What should the program actually do?", "should_trigger": true },
{ "query": "I need to justify our developer relations program to the board next month.", "should_trigger": true },
{ "query": "how do I decide what our developer advocates should and should not be doing", "should_trigger": true },
{ "query": "We do a bit of everything for developers and none of it seems to land. Help.", "should_trigger": true },
{ "query": "Should we outsource our technical content to an agency or keep it in-house?", "should_trigger": true },
{ "query": "What business goal should a developer relations program serve?", "should_trigger": true },
{ "query": "our new CTO wants to know what devrel is for here, in one page", "should_trigger": true },
{ "query": "Pick between building a community and doubling down on docs for us.", "should_trigger": true },
{ "query": "We are starting developer relations from zero. What is the first thing to fund?", "should_trigger": true },
{ "query": "How many pillars should a two-person devrel team fund?", "should_trigger": true },
{ "query": "Help me write down what our developer program will refuse to do this year.", "should_trigger": true },
{ "query": "Is a developer advocate or a technical writer the right next hire for us?", "should_trigger": true },
{ "query": "give me a one page plan for our developer program that survives a budget review", "should_trigger": true },
{ "query": "We have four people doing developer-facing work across three teams and nobody owns it.", "should_trigger": true },
{ "query": "Which program shape fits a company selling a self-hosted database to platform teams?", "should_trigger": true },
{ "query": "should we build a community or is that a distraction at our size", "should_trigger": true },
{ "query": "My VP wants a devrel strategy deck by Friday.", "should_trigger": true },
{ "query": "What should our developer program stop doing?", "should_trigger": true },
{ "query": "Our developer marketing push produced 30 posts and nothing changed. What now?", "should_trigger": true },
{ "query": "how do I choose between serving individual devs and serving enterprise buyers first", "should_trigger": true },
{ "query": "We fund developer relations for sales enablement. What does that mean in practice?", "should_trigger": true },
{ "query": "Our board wants something that compounds, not a quarterly number. What do we build?", "should_trigger": true },
{ "query": "Everything our developer-facing team does is reactive. Give me a direction.", "should_trigger": true },
{ "query": "what should a devrel program at seed stage actually commit to", "should_trigger": true },
{ "query": "I inherited a developer relations team with no written goals.", "should_trigger": true },
{ "query": "Is it worth starting developer relations if we only have 2,000 users?", "should_trigger": true },
{ "query": "Draft the argument for keeping our developer advocacy headcount through the cut.", "should_trigger": true },
{ "query": "We want to replicate a big vendor's developer program at a twentieth of the size.", "should_trigger": true },
{ "query": "which of these should we fund: docs, events, community, or content", "should_trigger": true },
{ "query": "Our funding sponsor for the developer program just left the company.", "should_trigger": true },
{ "query": "How do I know if our developer program is serving too many goals?", "should_trigger": true },
{ "query": "figure out what our developer relations team is actually for", "should_trigger": true },
{ "query": "Can you rank the program options for a small devtools company by value per effort?", "should_trigger": true },
{ "query": "We need to pick two goals for the developer program and drop the rest.", "should_trigger": true },
{ "query": "What does an enablement-led developer program look like versus a reach-led one?", "should_trigger": true },
{ "query": "I want to stop the quarterly re-litigation of what devrel does here.", "should_trigger": true },
{ "query": "our devrel is busy but not landing", "should_trigger": true },
{ "query": "Should we build our technical content in-house, contract it, or use an agency?", "should_trigger": true },
{ "query": "Give me the case for funding a developer program at a company that sells to platform teams.", "should_trigger": true },
{ "query": "what capability does our developer program add next, and when", "should_trigger": true },
{ "query": "How do I set the audience priority for our developer program this half?", "should_trigger": true },
{ "query": "We just open-sourced our core engine. Does that change what our developer program should do?", "should_trigger": true },
{ "query": "Turn our list of devrel activities into an actual strategy.", "should_trigger": true },
{ "query": "I am the first DevRel hire. Nobody has told me what success looks like.", "should_trigger": true },
{ "query": "how much of our developer team's capacity should we commit up front", "should_trigger": true },
{ "query": "Our exec team cannot repeat what the developer program does. Fix that.", "should_trigger": true },
{ "query": "Do we need a devrel charter or is a roadmap enough?", "should_trigger": true },
{ "query": "We keep adding pillars every time someone joins the developer team.", "should_trigger": true },
{ "query": "What should the developer program refuse this horizon, and how do I defend it?", "should_trigger": true },
{ "query": "Does a locked product roadmap change which developer program shape we can run?", "should_trigger": true },
{ "query": "Should the developer program serve product feedback or adoption first?", "should_trigger": true },
{ "query": "Somebody needs to decide what our engineer-facing team is for before we hire again.", "should_trigger": true },
{ "query": "Which metrics should we report for devrel, and what is the attribution rule for each?", "should_trigger": false },
{ "query": "Split our $400k devrel budget across events, content and community into line items.", "should_trigger": false },
{ "query": "Should DevRel report into marketing or product, and what does each reporting line starve?", "should_trigger": false },
{ "query": "Cut our developer audience into named, sized segments with a weighted score.", "should_trigger": false },
{ "query": "Design the go-to-market motion for our developer tool: bottom-up self-serve or sales-led?", "should_trigger": false },
{ "query": "Should we go open core or hosted open source to make money?", "should_trigger": false },
{ "query": "Map our developer journey stage by stage with exit events and named owners.", "should_trigger": false },
{ "query": "Which conferences should we sponsor, at which tier, and what booth activation?", "should_trigger": false },
{ "query": "Route my current task to the right skill in the devrel collection.", "should_trigger": false },
{ "query": "Write the job posting and interview loop for a developer advocate role.", "should_trigger": false },
{ "query": "Audit my portfolio, am I ready to apply for a DevRel job?", "should_trigger": false },
{ "query": "Plan a quarter of devrel content as dated slots with owners and reviewers.", "should_trigger": false },
{ "query": "Benchmark a competitor's DevRel motion from publicly observable signals.", "should_trigger": false },
{ "query": "Build the event taxonomy and UTM discipline for our docs analytics.", "should_trigger": false },
{ "query": "Should we launch a Discord or a forum, and how do we seed the first 90 days?", "should_trigger": false },
{ "query": "Should our product open extension points to third parties and become a platform?", "should_trigger": false },
{ "query": "Do we need a certification program or a developer academy?", "should_trigger": false },
{ "query": "Where do we draw the open-core line, and what stays proprietary?", "should_trigger": false },
{ "query": "What should we charge for our developer tool, and where does the free tier stop?", "should_trigger": false },
{ "query": "Plan launch day for open-sourcing our repository and hitting GitHub Trending.", "should_trigger": false },
{ "query": "Design an unpaid ambassador program with a perk ladder and fixed terms.", "should_trigger": false },
{ "query": "Build the employer brand strategy for attracting more backend engineers.", "should_trigger": false },
{ "query": "Give me a watch list of DevRel podcasts and newsletters worth following.", "should_trigger": false },
{ "query": "Which community health metrics tell me whether our Discord is dying?", "should_trigger": false },
{ "query": "Write a GOVERNANCE.md: who decides in our open-source project?", "should_trigger": false },
{ "query": "Our docs do not rank. Fix canonicals and hreflang across the versioned pages.", "should_trigger": false },
{ "query": "Write a quickstart that gets a developer to a first successful call in ten minutes.", "should_trigger": false },
{ "query": "Rewrite my repository README so a stranger can run the first command in a minute.", "should_trigger": false },
{ "query": "Write a 'how we rewrote it in Rust' engineering blog post.", "should_trigger": false },
{ "query": "Turn my talk idea into a CFP submission for this conference.", "should_trigger": false },
{ "query": "My talk got accepted, give me a minute-by-minute outline and slide skeleton.", "should_trigger": false },
{ "query": "Start a monthly developer meetup and build a standing speaker pipeline.", "should_trigger": false },
{ "query": "Pick a license: MIT, Apache-2.0 or AGPL, and do we need a CLA?", "should_trigger": false },
{ "query": "Should we contribute upstream to this protocol or drive our own spec?", "should_trigger": false },
{ "query": "Which open-source maintainers should our company sponsor, and how much each?", "should_trigger": false },
{ "query": "Write a technical case study from this customer's production deployment.", "should_trigger": false },
{ "query": "Write the migration guide for our 3.0 breaking changes.", "should_trigger": false },
{ "query": "Classify our docs pages against Diataxis and find the mixed-mode ones.", "should_trigger": false },
{ "query": "Make our API docs something a coding agent can integrate from unattended.", "should_trigger": false },
{ "query": "Turn our support tickets into error-reference pages developers find by pasting the error.", "should_trigger": false },
{ "query": "Nobody contributes to my project. Write a CONTRIBUTING file and good-first-issues.", "should_trigger": false },
{ "query": "Our issue tracker is out of control. Design a triage system we can sustain.", "should_trigger": false },
{ "query": "What do developers actually search for? Build a keyword list from our docs search logs.", "should_trigger": false },
{ "query": "Pitch this launch to a reporter and handle the embargo.", "should_trigger": false },
{ "query": "Write the two-column shooting script for a five-minute screencast.", "should_trigger": false },
{ "query": "My live demo keeps breaking on stage. Give me checkpoints and a fallback plan.", "should_trigger": false },
{ "query": "How far up the disclosure ladder should I go building this project in public?", "should_trigger": false },
{ "query": "Turn these merged pull requests into release notes developers will actually read.", "should_trigger": false },
{ "query": "Write a learn-by-building tutorial with verifiable checkpoints for our SDK.", "should_trigger": false },
{ "query": "Our docs code samples no longer compile. Write the policy and audit the corpus.", "should_trigger": false },
{ "query": "What should I pin on our GitHub org profile, and what goes in the profile README?", "should_trigger": false },
{ "query": "How do people find our open-source project after launch week? Registry metadata, curated lists.", "should_trigger": false },
{ "query": "Write our code of conduct and the enforcement ladder behind it.", "should_trigger": false },
{ "query": "I am going on a podcast next week, prep my message spine and clip-safe sound bites.", "should_trigger": false },
{ "query": "Set up sponsorship tiers and rewards for my open-source project so companies can pay me.", "should_trigger": false },
{ "query": "Give me a content strategy: what topics should our blog cover this year?", "should_trigger": false },
{ "query": "Build our product strategy and roadmap for the next two quarters.", "should_trigger": false },
{ "query": "What is our GTM strategy for entering the European mid-market?", "should_trigger": false }
]
}
references/build-vs-buy.md›
# Build versus buy
Per-bet sourcing decisions for step 5: what a devrel program can rent, what it must own, and the costs each option hides.
## Contents
- [The decision test](#the-decision-test)
- [Option table per capability](#option-table-per-capability)
- [Red lines - never outsourced](#red-lines--never-outsourced)
- [The documented agency pattern](#the-documented-agency-pattern)
- [Hidden costs of buying](#hidden-costs-of-buying)
- [Hidden costs of building](#hidden-costs-of-building)
- [Writing the decision into the charter](#writing-the-decision-into-the-charter)
## The decision test
Answer in this order for each bet:
1. **Judgment or volume?** Work that requires a trade-off call, a limitation admitted, or a technical opinion is judgment. Work that requires more of a known shape is volume. Buy volume.
2. **Does the output carry a person's name?** A byline, a stage, a moderation decision or an incident update is a promise from a person. Keep it.
3. **What is the latency?** Rented pipelines add weeks between decision and output. If the bet is tied to a dated event, that latency may disqualify buying.
4. **What is the setup cost before the first output?** Vendor pipelines need briefs, templates, review loops and someone to run them, paid before anything ships.
5. **Who reviews it?** Bought output still consumes in-house review time, which is usually the same bottleneck the buy was meant to relieve.
6. **What happens when the contract ends?** A surface that decays into something actively wrong (stale docs, an abandoned community, an unmaintained sample repo) is worse than one that was never started.
## Option table per capability
This table says which options are viable per capability. Which of the viable ones to pick first is ordered in step 5 of `SKILL.md`, alongside the effort, value and compliance axes - do not re-derive an order here.
| Capability | Build in-house | Contractor / freelance | Agency | Community-sourced | Default |
| ----------------------------- | ------------------------------- | ------------------------------------------ | --------------------------------- | ---------------------------------------- | ----------------------------------------- |
| Technical blog volume | slow, high trust | good for niche depth | best throughput, needs a pipeline | write-for-us at scale stage | buy volume, own outlines and review |
| Reference documentation | own it | technical writers work well as contractors | rare fit | rarely | build, contract for surge |
| Quickstart and samples | own it | possible with strict review | no | no | build |
| Conference talks | own it | no | no | community speakers extend reach | build |
| Video production | script in-house | editing and motion work well outside | good for series | community screencasts | build the script, buy the post-production |
| Event presence | staff booths with practitioners | contract logistics | full production for own events | community-run meetups | mix |
| Community moderation | own the decisions | contracted first-line triage is workable | risky | volunteer moderators with a clear policy | build the policy, extend the staffing |
| Developer support | own escalation | contracted tier-one possible | no | peer answers with staff backstop | build the escalation path |
| Analytics and instrumentation | own the definitions | contract the plumbing | no | no | build definitions, buy tooling |
| Swag, design, brand assets | no | yes | yes | no | buy |
Partner/sponsored has no column here on purpose. It buys placement and access, never output or trust; it answers a channel question rather than a sourcing one.
A sponsored slot is an ad and has to be labelled as one. Send it to `samber/developer-relations-skills@developer-event-sponsorship`.
Treat the default column as a starting point, not a rule. A three-person program with one strong writer and no designers inverts several rows legitimately.
## Red lines - never outsourced
Developers grant approval to people who visibly get it and who will recommend a competitor when it is the right answer (Leslie Hawthorn, "DevRel and the approval economy", developerrelations.com, 2018). Everything below trades on that approval and breaks when rented:
- The advocate's byline, voice and stage presence.
- Technical trade-off calls and any statement about what the product cannot do.
- Incident, outage and breaking-change communication.
- Moderation and code-of-conduct enforcement decisions.
- Answers in the community that carry the company's name.
- The relationship with named champions and design partners.
A useful test: if a developer discovering that a vendor wrote it would feel misled, it is a red line.
## The documented agency pattern
The published model that works splits ownership rather than handing over the surface (Matt Jarvis, Director of Developer Relations at Snyk, "Scaling developer content production at Snyk", developerrelations.com): "our advocate creates an outline and then works with the agency to see it fleshed out."
- Advocates keep ideation and review.
- The agency produces the body.
- Automation carries the coordination because, in his words, "we needed to industrialise this process."
The pipeline setup time and the per-piece latency from that case study are in step 5's option table, where the sourcing decision is made. Two further constants from it, useful as defaults until your own numbers exist:
- Modelled impact per piece: deeper technical pieces around 1,000 sessions, introductory pieces around 500.
- Reported failure points: underestimating outline effort, and an adjustment period for advocates moving into the new workflow.
Read it as a volume-and-compounding play. It does not hit a launch date, and it does not replace an advocate.
## Hidden costs of buying
- **Review load lands on the same bottleneck.** Output multiplies; reviewer hours do not.
- **Brief quality is the ceiling.** A vague outline returns generic content, and generic technical content is worse than none.
- **Latency compounds with revisions.** Two rounds on an eight-week pipeline miss the quarter.
- **Institutional knowledge leaves with the vendor.** Nothing accumulates in the team unless the outlines and the review notes stay in-house.
- **Sameness.** Several vendors serving the same category produce recognisably similar content, which erases differentiation.
## Hidden costs of building
- **Opportunity cost of the generalist.** At seed stage, every hour written is an hour not spent unblocking the first users.
- **Single point of failure.** One person owning docs, talks and community means all three stop when they take leave or resign.
- **Skill mismatch.** An excellent advocate is not automatically an editor, a video producer or a community moderator.
- **Slower ramp.** In-house depth compounds, but the first outputs arrive later than a vendor's.
## Writing the decision into the charter
Record one line per bet: `bet | source (in-house / contractor / agency / community) | latency | setup cost | reviewer | what happens if it stops`. A build-versus-buy line without a named reviewer is the one that fails, because the review step is where the rented output either becomes yours or becomes noise.
references/charter-example.md›
# Worked charter and section quality
A full example charter, then weak-versus-strong versions of the sections that most often fail review. The example company is fictional; the numbers are illustrative placeholders, not benchmarks.
## Contents
- [Worked example](#worked-example)
- [Rejected charter - activity list as strategy](#rejected-charter--activity-list-as-strategy)
- [Weak vs strong sections](#weak-vs-strong-sections)
- [Second example in one paragraph - company-adoption motion](#second-example-in-one-paragraph--company-adoption-motion)
## Worked example
```markdown
# DevRel charter: Fictional Corp, H2
## Position
CORE, written after 14 user conversations and a support-ticket read.
Community: ~2,100 monthly active API keys, no venue of our own; questions land in
GitHub issues and one Discord we do not run. Engagement is transactional.
Organization: DevRel is one advocate hired three months ago, reporting into
product. Marketing owns the blog, engineering owns the docs repo. A previous
"developer marketing" push in the last fiscal year produced 30 posts and no
measurable adoption change; nobody could explain what it was for.
Relationships: two integration partners resell us into their own developer base;
our closest competitor runs a strong community and weak documentation.
Ecosystem: we are the third-known option in a category developers discover by
searching an error message, not by browsing.
Lifecycle stage: growing.
## Driver
Developer adoption. Owner: VP Product, who funds the role and will defend it.
Secondary: product input, because the roadmap for next year is still open.
## Goals
Primary: activation - 41% of new API keys never make a second successful call
(journey step: evaluation and validation).
Primary: awareness - we are absent from the error-message searches that produce
our best-converting arrivals (journey step: initial awareness).
Secondary: product - the top three friction points reach the backlog with an owner.
## Audience
Primary: individual backend developers adopting alone, in the Python and
TypeScript ecosystems, at companies under 200 people.
Not served this horizon: enterprise platform teams. We will answer their
questions but will not build procurement material for them yet.
## Pillar mix
Enablement 50%, marketing 30%, advocacy 20%, community 0%.
Community is deliberately starved: at ~2,100 monthly actives with transactional
engagement, a venue of our own would sit empty and argue against us.
## Bets
1. Rebuild the quickstart to first successful call under 10 minutes.
Goal: activation. Owner: advocate. Signal: share of new keys reaching a second
successful call. Review: week 8.
2. Publish troubleshooting pages for the 12 highest-volume support errors.
Goal: activation + awareness. Owner: advocate, drafted from support data.
Signal: organic arrivals on error pages, and tickets per 100 new keys.
Review: week 10.
3. Ship a monthly technical series on the two integration problems developers
already search for. Goal: awareness. Owner: advocate outlines, agency drafts.
Signal: non-paid qualified arrivals. Review: week 12.
4. Run six friction logs on our own onboarding and route findings to product.
Goal: product. Owner: advocate, VP Product accepts. Signal: shipped changes
traceable to a friction log. Review: quarterly.
## Build vs buy
Bet 1: in-house. Latency 3 weeks. Reviewer: engineering lead. Red line: yes,
it is the credibility surface.
Bet 2: in-house drafting, contracted editor. Latency 4 weeks. Setup: one style
brief. Reviewer: advocate.
Bet 3: agency drafting from in-house outlines. Latency 8-9 weeks per piece,
about 6 weeks of pipeline setup first. Reviewer: advocate. If the contract ends,
the series stops cleanly; no surface decays.
Bet 4: in-house only.
## Staffing
Stage: grow, one generalist. Next capability: a technical writer, triggered when
the advocate's review queue exceeds two weeks for a second consecutive month.
Not hiring a community manager this horizon; no community to manage yet.
## Refused
- No conference sponsorship this horizon: our arrivals come from search, and a
booth costs the equivalent of both bets 1 and 2.
- No Discord of our own until bet 1's activation number moves and question volume
exceeds what issues can absorb.
- No swag program. The team wanted one; it serves no goal on this list.
- No enterprise procurement material until an approver-gated deal actually stalls.
## Open questions
- Is the second-call drop-off concentrated in one SDK or spread across all four?
Nobody has cut it that way. Owner: data lead, by week 3; it decides bet 1's scope.
- Does the program budget include the advocate's salary? Finance and the VP Product
answer differently. Owner: VP Product, before the next planning cycle.
- No named production reference has agreed to be public. Owner: account team, by
week 6; without one, bet 3 loses its main asset.
## Exec narrative
We are funded to grow developer adoption. Four out of ten developers who sign up
never make a second successful call, and we are invisible in the searches that
bring us our best users. This half we fix the first ten minutes of the product and
own those searches, and we route what we learn into the roadmap. We are not
building a community or attending conferences yet, because neither addresses the
leak. By the end of the half you should see a higher share of new developers
reaching a working integration, and more of them arriving from search.
## Review
Re-decision at the end of the half. Early re-decision if the funding sponsor
changes, if the pricing model changes, or if bet 1's signal does not move by
week 10.
```
## Rejected charter - activity list as strategy
This is what the same company produces when it skips CORE and starts from the calendar. It is the most common failure, and it is tempting because every line is real work someone is genuinely willing to do. Recognise it and send it back.
```markdown
# DevRel plan: H2
## Goals
Build awareness, grow the community, support sales, improve docs, gather
product feedback, and strengthen our employer brand.
## Plan
- Publish two blog posts a month
- Speak at four conferences
- Launch a Discord
- Refresh the documentation
- Run a monthly livestream
- Attend two hackathons
- Ship a swag store
## Team
Hire a community manager and a developer advocate in Q3.
## Metrics
Blog views, Discord members, conference attendees, GitHub stars, social
followers.
```
Why it fails, in the order a reviewer will find it:
1. **Six goals is no goals.** Every activity below scores identically against them, so effort will follow whoever asks loudest, not the funded driver. There is no sponsor named anywhere.
2. **No position.** Nothing states what the community, organisation, relationships or ecosystem currently look like, so no reader can tell whether these are the right moves or another company's moves copied over.
3. **Activities with no drop-off behind them.** Not one line names a place developers are currently stuck. The Discord and the swag store in particular exist because they are normal, not because anything argues for them.
4. **All four pillars funded at once.** Advocacy, marketing, enablement and community all appear, at a company whose team is about to be two people - the median DevRel team size is 2-5, and this plan is shaped like a fifteen-person one.
5. **Hires with no trigger.** Two roles are named with no friction they remove and no condition that justifies them.
6. **Reach metrics only.** Views, members, attendees, stars and followers are all counts of hits, not of developer behaviour. The first exec question - "what did that change?" - has no answer.
7. **Nothing refused, nothing unknown.** With no refused list, every idea returns next quarter; with no open questions, the plan's assumptions are invisible until they break.
The repair is not to trim the list. It is to run steps 1 and 2, discover the one funded driver, and let most of these lines fall away on their own.
## Weak vs strong sections
**Driver**
- Weak: "Build awareness and community around our developer platform." Two goals, no owner, no funder's language, unfalsifiable.
- Strong: "Developer adoption. Owner: VP Product, who funds the role and will defend it." One reason, one named person, quotable in a budget review.
**Goals**
- Weak: "Increase engagement across our developer touchpoints." No journey step, no drop-off, no number.
- Strong: "Activation - 41% of new API keys never make a second successful call (journey step: evaluation and validation)." Observed behaviour, one step, correctable.
**Pillar mix**
- Weak: "Balanced investment across advocacy, marketing, enablement and community." Four pillars at 25% each is how a small program produces nothing four times.
- Strong: "Enablement 50%, marketing 30%, advocacy 20%, community 0%," plus the sentence explaining why community is starved. A starved pillar named on purpose stops the quarterly re-litigation.
**Bets**
- Weak: "Improve documentation and grow our content output." No owner, no signal, no date.
- Strong: numbered bets, each with goal, owner, signal and review date. The date is what turns a plan into something that can be wrong in public.
**Refused**
- Weak: absent, or "we will focus and say no to distractions."
- Strong: four named refusals with reasons, including one the team actively wanted. A refused list that costs nothing was not a decision.
**Exec narrative**
- Weak: "DevRel will drive developer love and community-led growth through a multi-channel engagement strategy." Jargon, no number, unrepeatable.
- Strong: five plain sentences naming the problem, the two moves, the explicit non-moves, and what the funder will see. The test is whether the funder can repeat it accurately without you in the room.
## Second example in one paragraph - company-adoption motion
A security-tooling vendor sells into platform teams; developers evaluate, a security architect approves. Driver: sales enablement, owner VP Sales. Goals: activation (proof-of-concept completion) and revenue (evaluations reaching a technical decision). Audience: platform engineers at 500-plus-employee companies; individual hobbyists explicitly not served. Pillar mix: enablement 60%, advocacy 30%, marketing 10%, community 0%. Bets: a scoped proof-of-concept kit, reference architectures for the three deployment shapes, a written security-and-licensing answer set, and two named production references. Build versus buy: everything in-house except diagram production and the case-study interviews' transcription. Refused: hobbyist content, meetup sponsorship, a public community - none of them reaches the approver who blocks the deal.
references/program-archetypes.md›
# Program archetypes
Candidate whole-program shapes to brainstorm from in step 3. Each one over-invests in one or two of the four pillars - developer advocacy, developer marketing, developer enablement, developer community. It starves the rest on purpose.
Pick by funding driver and stage, then adapt; never present only one.
## Contents
- [How to use these](#how-to-use-these)
- [Archetype 1 - Enablement-first](#archetype-1--enablement-first)
- [Archetype 2 - Product-feedback](#archetype-2--product-feedback)
- [Archetype 3 - Evaluation-support](#archetype-3--evaluation-support)
- [Archetype 4 - Reach-first](#archetype-4--reach-first)
- [Archetype 5 - Community-first](#archetype-5--community-first)
- [Archetype 6 - Contributor-first](#archetype-6--contributor-first)
- [Stage overlay](#stage-overlay)
- [Adoption-path overlay](#adoption-path-overlay)
- [Breaking a tie between two survivors](#breaking-a-tie-between-two-survivors)
## How to use these
Match the funding driver to a starting archetype, then check it against the stage overlay and the adoption-path overlay. Change the bets, not the shape: a program that funds three archetypes at once is the failure mode these exist to prevent.
They are listed here in the same efficiency order step 3 applies - `enablement-first > product-feedback > evaluation-support > reach-first > community-first > contributor-first`. Read top-down. The value and effort axes, the ties and the conditions that override the order live in step 3 of `SKILL.md`, where the choice is actually made.
## Archetype 1 - Enablement-first
- **Fits drivers:** developer enablement, developer adoption after a signup spike that does not convert.
- **Pillar mix:** enablement heavy, advocacy light, marketing and community token.
- **Goals it serves:** activation, retention.
- **First bets:** time-to-first-success quickstart, error and troubleshooting coverage for the top support signals, tested code samples in the two languages that actually matter, an agent-readable documentation surface.
- **Effort:** about a quarter of one person's writing time, then near-zero maintenance; no coordination beyond whoever owns the docs; fully reversible, because the artefacts outlive the program.
- **Starves:** events, social presence, community venue.
- **Fastest signal:** share of new signups reaching first success, and support tickets per hundred new developers.
- **Wrong pick when:** nobody arrives at all. Fixing activation for a trickle produces a very efficient trickle.
## Archetype 2 - Product-feedback
- **Fits drivers:** product input before or around product-market fit.
- **Pillar mix:** advocacy heavy, enablement medium, marketing and community token.
- **Goals it serves:** product, activation.
- **First bets:** friction logs on the real onboarding path, structured design-partner conversations, a route that gets developer pain into the product backlog with a named owner, public follow-through on what shipped because of it.
- **Effort:** about an hour a week of friction logging, plus standing attention from one product owner; reversible the day the roadmap closes.
- **Starves:** scale content, events, community programs.
- **Fastest signal:** product changes traceable to developer feedback per quarter.
- **Wrong pick when:** the roadmap is already fixed for a year. Collected feedback that changes nothing burns credibility with both developers and the product team.
## Archetype 3 - Evaluation-support
- **Fits drivers:** sales enablement, ecosystem and partnerships in an enterprise motion.
- **Pillar mix:** enablement heavy, advocacy medium (pre-sales facing), marketing light, community light.
- **Goals it serves:** activation, revenue.
- **First bets:** reference architectures, proof-of-concept kits with a scoped success definition, security/licensing/compliance answers written once, migration guides from the incumbent, named production references.
- **Effort:** about a quarter of one person's writing time, plus standing coordination with sales; reversible, since the artefacts outlive the program.
- **Starves:** hobbyist content, broad awareness plays.
- **Fastest signal:** evaluations that reach a technical decision, and time from first contact to a working proof of concept.
- **Wrong pick when:** the product is bought bottom-up by individuals. Approver material nobody reads is expensive.
## Archetype 4 - Reach-first
- **Fits drivers:** developer adoption at the awareness stage, employer brand.
- **Pillar mix:** marketing heavy, advocacy medium, enablement maintenance-only, community none.
- **Goals it serves:** awareness, acquisition.
- **First bets:** a search-durable content line on the problems developers already search for, one or two conference stages that match the ecosystem, a repeatable launch beat, presence where the ecosystem already gathers.
- **Effort:** a standing job - the cadence is the product. Unwinding it is cheap, but everything it compounded stops compounding.
- **Starves:** community venue, champions, certification.
- **Fastest signal:** qualified arrivals from non-paid sources, and whether new arrivals reach first success at the same rate as existing ones.
- **Wrong pick when:** onboarding leaks. Reach into a broken activation path burns the audience once and teaches it the product does not work.
## Archetype 5 - Community-first
- **Fits drivers:** contributor community, developer adoption in a peer-learning ecosystem, retention of an installed base.
- **Pillar mix:** community heavy, advocacy medium, enablement medium, marketing light.
- **Goals it serves:** retention, referral.
- **First bets:** a single venue chosen against where the audience already is, a founding cohort seeded by hand, answer-time discipline, recognition for the first peer answers, a champions pipeline once density allows.
- **Effort:** a standing job with daily answer-time discipline; the hardest shape to unwind, because closing a venue is public evidence against the program.
- **Starves:** paid reach, conference booths, gated content.
- **Fastest signal:** questions answered by someone other than staff, and week-four return rate of the founding cohort.
- **Wrong pick when:** the user base is too small or too asynchronous to reach conversational density. An empty venue is worse evidence than no venue.
## Archetype 6 - Contributor-first
- **Fits drivers:** contributor community around a company-owned or sponsored open-source project.
- **Pillar mix:** community heavy, enablement heavy (contributor-facing), advocacy light, marketing light.
- **Goals it serves:** product, referral.
- **First bets:** a first-contribution path, curated starter issues with real mentoring, a reproducible dev environment, published triage and review response targets, governance clarity about who decides.
- **Effort:** a standing job spent on maintainer hours nobody can backfill; barely reversible, since an abandoned starter-issue queue damages the project itself.
- **Starves:** paid reach, event sponsorship.
- **Fastest signal:** first-response time on issues and pull requests, and repeat contributors in the following quarter.
- **Wrong pick when:** the codebase cannot absorb outside changes, or maintainers have no review capacity. Recruiting contributors into a review backlog damages the project's reputation.
## Stage overlay
| Stage | Realistic shape | Do not |
| --------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------- |
| Seed (nobody or a part-time hat) | one archetype, one bet, finished before a second starts | run two archetypes, build a community venue, sponsor events |
| Grow (small team, specialising) | one primary archetype plus a maintenance line on the previous one | let every new hire start a new pillar |
| Scale (several specialised teams) | primary archetype plus leverage programs that multiply output per person | grow headcount linearly and call it scaling |
## Adoption-path overlay
- **Individual-developer adoption** pushes toward enablement-first, reach-first and community-first. The developer decides alone, so friction and peer proof dominate.
- **Company adoption** pushes toward evaluation-support and, later, community-first for the installed base. The developer's enthusiasm still starts it, but the approver's checklist finishes it.
- Artefacts serving both: quickstart, reference documentation, changelog and migration guides, honest limitations. Build these once and count them in both columns.
- Artefacts serving one only: hobbyist tutorials and swag reach individuals; security questionnaires, procurement-ready licensing and named references reach companies.
## Breaking a tie between two survivors
Two rules settle what the efficiency order leaves level:
- **Fix the leak before opening the tap.** An activation problem beats an awareness problem whatever the ratio says, because reach into a leaking funnel spends audience that does not come back.
- **Choose the one whose signal appears soonest, when still tied.** An unfalsifiable strategy cannot be corrected mid-horizon.
SKILL.md›
---
name: devrel-strategy
description: Designs a company's developer relations program from the top - the business driver that funds it, the two goals it is allowed to serve, the pillar mix (advocacy, marketing, enablement, community) for its stage, audience priority, build-vs-buy per bet, staffing sequence, and a written refused list. Use whenever someone asks whether to start doing DevRel, what a new devrel program should do first, why devrel work is busy but not landing, how to justify the program to an exec, which pillar deserves the next investment, who to hire next, or whether to outsource content, events or community - even if they never say "strategy". Not the first-90-days plan - use samber/developer-relations-skills@developer-relations-kickoff. Not metrics, org chart or budget math.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# DevRel Strategy
You are a developer relations program strategist. You decide, with the person accountable for the program:
- which business goal it serves
- which kinds of work it funds
- who it serves first
- what it builds versus rents
- which capability it adds next
- what it publicly refuses to do
The output is a **DevRel charter**: a short document that survives a budget review and tells every later tactical decision what it is for. You produce the decisions, never the talks, posts, docs or events themselves.
Two constraints shape every recommendation:
- Developer attention is earned by usefulness, not bought. A program that outsources or automates its credibility surfaces loses the audience it just paid to reach.
- DevRel effort compounds slowly, so a program that changes goals every quarter never gets to the compounding part.
## Invocation
Trigger on any of these, and start at the Interview however narrow the question sounds - a pillar or hiring question asked in isolation is almost always a driver question in disguise.
- "We're a Series A API company. Should we even be doing DevRel, and what would we do first?"
- "Our devrel team ships constantly and nobody can say what it's for. Fix the strategy."
- "The CFO is asking why we fund two advocates. Build me the argument."
- "Do we hire a community manager next, or outsource the blog?"
Return one artefact: a **DevRel charter**, presented section by section in the chat and assembled at the end. It runs one to two pages - twelve short headings, three to five bets, one signal each. Everything else you produce (archetype comparison, build-vs-buy table) is working material that supports a charter section, not a second deliverable.
## Interview
Ask one question at a time. Offer multiple-choice options where you can. Stop as soon as you can name the funding driver, the company stage, the real capacity and the answers to 12 to 14 - confirm the rest as you go.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the product, and what does a developer actually do with it - call an API, install a library, run infrastructure, extend a platform, learn a method?
2. In a purchase, is the developer the user, the decision-maker, both, or neither? Who signs?
3. Why is the company funding this work: developer adoption, sales enablement, developer enablement, product input, ecosystem and partnerships, contributor community, or employer brand? Which one would the funder name first?
4. What stage is the program at: nobody does this yet, one person wearing the hat part-time, a small team, or several specialised teams?
5. Who does devrel-shaped work today - founders, engineers, support, marketing. How many hours a week does that really amount to?
6. What already exists: docs, quickstart, community venue, blog, OSS project, events, champions?
7. What does the exec who funds this expect to see in two to four quarters, in their own words?
8. What has been tried and produced nothing, and what is the team's read on why?
9. What is off-limits: no travel, no paid ads, regulated claims, a competitor's community, a channel the founder refuses?
10. What changes in the next two quarters - a launch, a pricing change, a funding round, an open-sourcing, a rebrand. What should this plan be timed against?
11. Who owns the budget, and does that number include the team's salaries or only program spend?
12. By what date must the first result be visible, and to whom - a board meeting, a launch, a renewal, a budget review?
13. Does the funder want a one-off win inside this horizon, or a compounding asset that mostly pays from next year?
14. What is the effort ceiling - weekly hours from people who already have other jobs, headcount you can actually add, and how reversible the commitment has to be?
Never skip questions 12 to 14, however obvious the driver already looks: they set the ordering of every menu below, and each answer moves a named option.
- A date inside one quarter promotes enablement-first and deletes the agency pipeline, whose published setup latency alone is about six months.
- "Compounding asset" promotes community-first and contributor-first, which lose every efficiency round on their own.
- An effort ceiling made of spare hours from people with other jobs deletes every shape that needs a standing job.
Ask question 11 even when it feels administrative. Budget ownership is a named input to goal selection in Leggetter's own framework, and in the _State of Developer Relations 2024_ survey (DevRel.Agency, 310 respondents), 60% of program budgets exclude salaries while 33.5% of practitioners cannot state their budget at all. A plan built on the wrong side of that line proposes work nobody can pay for.
Record the answers. If your harness has persistent memory, store these there:
- the funding driver
- the stage
- the audience priority
- the refused list
- the deadline
- the one-off-versus-compounding mandate
- the effort ceiling
Every sibling skill and every later quarter re-uses them, and re-deriving them from scratch is where program drift starts.
## Sourced figures, self-set baselines
You will state numbers constantly - team sizes, spend shares, capacity ceilings. Keep the two kinds visibly apart, in your reasoning and in the charter itself; a self-set baseline dressed up as an industry standard is the fastest way to lose the exec who checks it.
**Quote freely, with attribution and sample size.** Every survey figure below comes from _State of Developer Relations 2024_ (DevRel.Agency, 310 respondents, published September 2024) - check whether a newer edition has since published, and prefer its numbers if so:
- Team size: 2-5 people is the most common band at 35.2%, solo practitioners are 18.2%, and 69% of teams are under ten people. Cite this the moment someone proposes a large company's pillar mix.
- 33.5% of practitioners cannot state their program's budget and a further 17.8% have no set budget. Establishing the envelope is a real first step, not a formality.
- 43.6% report more than one team doing DevRel work. Treat fragmentation as the normal starting condition, not an anomaly.
- Budget direction over the previous year: 29% increased, 24% flat, 24% decreased. Plan the cut scenario as a normal case.
**Cite as history, never as a target.** The same survey's spend split (events 41.1%, salaries 30.9%, content 19.5%, marketing 13.0%) fails as a benchmark for three reasons:
- Only 47 respondents saw the question.
- The shares sum to 104.5% (respondents answered on inconsistent bases).
- The categories omit community, tooling and education entirely.
Use it only as evidence that events have historically dominated DevRel spend, so a plan proposing otherwise is a deliberate departure worth arguing.
**Label as this skill's own baseline.** The capacity ceiling, pillar count, goal count, bet count and narrative length in the quality gate below are set by this skill. No published study backs the specific figures, and no published maturity model offers a substitute - check the Developer Relations Foundation's Maturity Model before citing it as one, since it may state a purpose without defining levels. Say "starting baseline" when you state one, and move it when the situation argues for it.
## Step 1 - Establish the position before proposing anything
Run the **CORE** situational analysis (Matthew Revell, developerrelations.com, 2016) and write one paragraph per quadrant:
- **Community** - who already uses or contributes, where they gather, how engaged they are, what blocks them.
- **Organization** - internal alignment with product, marketing and engineering; resources; who decides; what was tried before and how it ended.
- **Relationships** - collaborators, competitors and dependencies; how each is perceived; whether their goals align with yours.
- **Ecosystem** - the technical landscape, the competitive set, and where developers place you in it.
Name the lifecycle stage the answers imply: starting, growing, or established. Refuse to propose pillars, hires or channels before these four paragraphs exist - a plan written without them is a plan copied from another company.
## Step 2 - Name the funded driver, then pick at most two goals
Programs get funded for one of seven reasons (Revell's driver list, developerrelations.com):
- developer adoption
- sales enablement
- developer enablement
- product input
- ecosystem and partnerships
- contributor community
- employer brand
Say which one is primary, in the funder's language, and which one is secondary. If the answer is "all of them", the program has a sponsor problem, not a strategy problem - say so.
Translate the driver into goals with **AAARRRP** (Phil Leggetter, 2016):
- awareness
- acquisition
- activation
- retention
- referral
- revenue
- product
Pick **two primary goals and one secondary**, no more. Then locate each goal as a specific step on the developer journey (initial awareness, deep awareness, evaluation, commitment, standardization, advocacy) where developers currently drop off.
A goal with no observable drop-off behind it is a preference. A program claiming all seven has no strategy, because every candidate activity then scores identically.
## Step 3 - Brainstorm program shapes, then rank them
Announce that you are in brainstorming mode, and write no plan yet.
Spread the chosen goals across the four pillars - developer advocacy, developer marketing, developer enablement, developer community. Build **two or three whole-program candidates**, never one. Take the stage-and-driver archetypes, their effort, and what each one gives up, from [references/program-archetypes.md](./references/program-archetypes.md).
Filter before ranking. Keep only the archetypes the funded driver fits, then **delete** the ones the answers rule out:
- A roadmap already fixed for a year deletes product-feedback.
- A refusal to run a venue of your own deletes community-first.
- A codebase that cannot absorb outside changes deletes contributor-first.
Delete them from the candidate set instead of ranking them last - a ruled-out shape parked at the bottom comes back as scope in month two.
Then order the survivors. Effort here is headcount and the weekly hours of people who already have other jobs, the latency before the shape returns anything, the coordination it needs across pillars, and how hard it is to unwind:
- efficiency: `enablement-first > product-feedback > evaluation-support > reach-first > community-first > contributor-first`
- value: `enablement-first > evaluation-support > community-first > reach-first > contributor-first > product-feedback`
- effort: `product-feedback > enablement-first == evaluation-support > reach-first == community-first > contributor-first`
The axes disagree hardest at community-first, which outranks reach-first on value and ties it on effort, yet loses on efficiency: a ratio is computed inside a horizon, and community-first's return arrives after this one ends.
Both ties sit on the effort axis, and both are argued:
- Enablement-first and evaluation-support cost about the same quarter of one person's writing time and both leave artefacts that outlive the program, so both are equally reversible.
- Reach-first and community-first are each a standing job that produces nothing the month its cadence stops.
Present each surviving candidate with the same six facts:
- the pillar it over-invests in
- the first three bets it funds
- what it deliberately starves
- the capacity it needs
- the fastest signal that it is working
- the condition that makes it the wrong pick
Recommend the highest-ranked survivor and say why - then let the program owner choose before you detail anything, because a wrong shape propagates into every hire and channel below it.
This order starves community-first and contributor-first every round, and that is the intended consequence of an argument this skill already makes: two pillars funded properly beat four funded at 25%, because most devrel work only pays off past a threshold of consistency.
- Community-first is the clean case: third on value, second-to-last on efficiency, because the ratio cannot see a return that lands after the horizon.
- Contributor-first is starved differently: its value only exists under one driver, and a generic order is blind to it.
Promote one anyway when the driver is contributor community or retention of an installed base, or when question 13 came back "compounding asset" with a horizon past this one. Fund it as the primary and starve the efficient shapes: a community funded at a quarter of a standing job is the one investment worse than not starting.
The order is a default, not a law, and it shifts with who executes it. Re-rank it against what the Interview already told you:
- A team with a running content engine has already paid reach-first's standing job, so reach-first moves to the top for them.
- A funder who needs a number this quarter drops community-first and contributor-first off the list.
- A team of one keeps the top two and nothing else.
## Step 4 - Set audience priority
Pick the one segment the program serves first this horizon, and name who it is not serving yet. The two adoption paths differ enough to change every downstream choice:
- **Individual-developer adoption** - the developer discovers, tries and decides alone. Invest in discoverability, time-to-first-success, and peer proof. Success shows up as usage before revenue.
- **Company adoption** - a developer evaluates, but a manager, architect, security reviewer or procurement approver decides. Invest in evaluation material an approver can read: reference architectures, security and licensing clarity, migration and support paths, named production references. Success shows up as evaluations that survive review.
These two carry no efficiency ordering, deliberately: the path is set by who signs the purchase (question 2), not by what it costs to serve, so ranking them by effort would be false precision.
Most programs face both. Pick one for this horizon instead of splitting evenly, and state which artefacts serve both paths so they get built once. Deep segmentation (ecosystem, seniority, buyer personas) belongs to `samber/developer-relations-skills@developer-segmentation`; here you only need the primary path and the one segment inside it.
## Step 5 - Decide build versus buy per bet
For each funded bet, choose in-house, contractor, agency or community-sourced. Partner/sponsored is not on this menu: it buys placement and access, not output or trust, and it never answers "who makes this bet". Decide it in `samber/developer-relations-skills@developer-event-sponsorship`.
Use [references/build-vs-buy.md](./references/build-vs-buy.md) for the per-capability table, the red lines, and the hidden costs on both sides.
Effort here is the in-house hours the option still consumes, the latency before the first output, and how hard the decision is to unwind:
- efficiency: `contractor > in-house > agency > community-sourced`
- value: `in-house > community-sourced > agency > contractor`
- effort: `contractor > agency > in-house == community-sourced`
- compliance cost: `in-house == contractor > agency > community-sourced`
| Option | Effort before the first output | What it buys | Reversibility |
| ----------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------------- |
| Contractor | an hour to brief, about a week to delivery | niche depth, once | ends with the engagement |
| In-house | a standing job | credibility, and knowledge that stays in the team | one resignation stops all of it |
| Agency | roughly six months of the lead's own time to build the pipeline, then eight to nine weeks per piece | volume, past the setup | the series stops cleanly, nothing decays |
| Community-sourced | a standing job of recruiting, review and recognition, and only once density exists | peer proof in-house cannot produce | a merged contribution cannot be un-licensed |
Two ties are argued here, not assumed:
- In-house and community-sourced tie on effort because both cost a standing job: one paid as salary, one as recruiting and recognition. Both stop producing the month that person stops.
- In-house and contractor tie on compliance because both are work-for-hire: the rights question is answered by the employment or engagement contract, with no separate review.
Agency costs one contract review for rights assignment and byline disclosure, done once and reopened at renewal. Community-sourced costs a contributor licence or DCO decision that has to be in place before the first contribution, and it is the least reversible commitment on this page.
Two rules override the order:
- **Keep judgment and voice in-house.** Technical trade-off calls, the advocate's byline, incident communication, moderation decisions, and any claim about the product's limits are exactly what a developer audience checks for authenticity. On those surfaces there is no menu at all; the other three options are deleted rather than ranked last.
- **Rent volume, not credibility.** In the one published DevRel case study of this (Matt Jarvis, Director of Developer Relations at Snyk, on developerrelations.com), the advocate writes the outline and reviews the result while an agency produces the body.
The order starves community-sourced, high on value and high on effort, so a ratio never reaches it. Promote it when community-first or contributor-first is already the funded primary: the density is paid for, and community-sourced is then the only option whose output grows without a new standing job behind each unit.
The order is a default, and it moves with who executes it. Re-rank it against the Interview:
- A first result due this quarter deletes agency outright, because six months of pipeline setup does not fit inside that window however much budget it has.
- A team of one with no budget line has only in-house and community-sourced.
- A company with an editorial team already on payroll has effectively pre-paid the in-house row.
## Step 6 - Sequence the staffing
Derive the sequence from the friction found in step 2, never from a standard team template. The stage vocabulary is Leggetter's (2021):
- **Seed** - one generalist, often a part-time hat before a headcount. Fund one high-impact program and finish it before adding a second.
- **Grow** - specialise only when the generalist's queue is the constraint. Split toward developer educator, community manager, or advocate depending on which journey step still leaks. Warn the owner of Leggetter's named cost: you may lose people who liked being generalists unless they can keep contributing outside their specialization.
- **Scale** - add leverage, not headcount, in this order: `champion and ambassador programs > community-run events > paid write-for-us pipelines > contributor programs`. Hold to Leggetter's test: a team is only scaling if further investment increases output more than it increases input.
- Champion programs recognise people already advocating, so they multiply an asset you own.
- Contributor programs land last because they spend maintainer hours nobody can backfill.
- Every one of them still consumes in-house review, which is usually the bottleneck the leverage was meant to relieve.
State the _next_ hire and the trigger that justifies it, not a twelve-month org chart. Reporting lines, role ratios and team topology belong to `samber/developer-relations-skills@devrel-team-structure`.
## Step 7 - Write the charter and validate it section by section
```markdown
# DevRel charter: <company>, <horizon>
## Position CORE summary, lifecycle stage, what changed since last time
## Driver the funded reason, in the funder's words, and its owner
## Goals 2 primary + 1 secondary, each pinned to a journey step
## Audience primary path and segment; who is not served yet
## Pillar mix where effort goes, and which pillar is deliberately starved
## Bets 3-5 bets: goal served, owner, signal, review date
## Build vs buy per bet, with latency and setup cost
## Staffing next capability, its trigger, current stage
## Refused what this program will not do this horizon, and why
## Open questions unknowns that would change the plan, who resolves each, by when
## Exec narrative five sentences the funder can repeat without you
## Review re-decision cadence and what would force an early one
```
Present one section at a time and get agreement before writing the next. Catching a wrong driver at the second heading costs one paragraph; catching it at the tenth costs the whole document.
Fill "Open questions" honestly instead of papering over a gap - an unmeasured drop-off, an unnamed sponsor, a budget nobody can state. A charter that hides its unknowns gets ambushed by them at the exact review it was written to survive.
A full worked charter (a fictional company with illustrative numbers, plus a weak-versus-strong pair for every section and a rejected charter) is in [references/charter-example.md](./references/charter-example.md).
## Quality gate
Hold the charter to this gate and iterate until it passes. Report the check explicitly at the end, and say which lines are structural and which are baselines you moved.
Structural first - a charter failing any of these is incomplete, and there is nothing to negotiate.
- The driver is one named reason with one named owner, phrased as the funder would phrase it.
- Each goal names a journey step and an observed drop-off, not a preference.
- Every bet traces to exactly one primary goal and carries an owner, one signal and a review date.
- The refused list is non-empty and includes at least one thing the team wanted to do.
- Open questions are written down rather than resolved by assumption.
- Nothing on a credibility surface is outsourced.
- The exec narrative uses no devrel jargon.
The numeric lines are different in kind: this skill set them, no published study backs them, and you may move them - deliberately, saying why in the charter:
- At most 70% of declared capacity is committed; the rest absorbs support load, launches and the unplanned.
- At most two pillars are funded above token level at seed or grow stage.
- Three goals maximum (two primary, one secondary).
- Three to five bets per horizon.
- Five sentences for the exec narrative.
A charter failing the capacity line is not a discipline problem. It has one bet too many.
Which numbers prove the program works is a separate decision - see `samber/developer-relations-skills@devrel-metrics`. Here you only commit to one signal per bet, so the strategy stays falsifiable.
## Common failure modes
- **Copying a large company's program.** Their pillar mix presupposes leverage programs and a brand you do not have yet. Derive from CORE instead.
- **Activity list as strategy.** A calendar of talks, posts and events with no driver behind it survives exactly one budget review.
- **Serving every goal.** Seven goals score every activity identically, so effort follows whoever asks loudest.
- **Outsourcing the voice.** Agency-written advocacy under an advocate's byline is detected fast and costs more trust than the content earned.
- **Reorganising instead of re-scoping.** A program that misses its goal usually funded too many pillars, not the wrong org chart.
- **Measuring hits instead of humans.** Reach numbers with no developer behaviour behind them fail the first exec question.
- **Quoting a small-sample average as a benchmark.** The circulating "DevRel spends 41% on events" figure comes from 47 respondents whose answers sum to 104.5% and whose category set omits community, tooling and education. Cite it as history - events have dominated spend. Never as a target; an exec who checks it discredits the whole charter.
- **Ignoring where the practice is moving.** The DevRelCon New York 2025 programme (a reading of its talk titles, not a survey) puts agent-readable documentation, measurement literacy and doing more with less at the field's centre, with event-and-swag activity in decline. Weigh a plan that ignores that shift accordingly.
- **No refused list.** Without one, every idea gets re-litigated each quarter and the program's effort spreads back out.
- **A driver whose owner leaves.** Re-run the charter when the funding sponsor changes, before the budget review, not after.
## References
- [references/program-archetypes.md](./references/program-archetypes.md) - stage-and-driver archetypes in step 3's efficiency order, with each one's pillar mix, first bets, effort and trade-offs.
- [references/build-vs-buy.md](./references/build-vs-buy.md) - which sourcing options are viable per capability, the red lines, and the hidden costs of buying and of building.
- [references/charter-example.md](./references/charter-example.md) - a full worked charter (fictional company, illustrative numbers), a weak-versus-strong pair for every section, and a rejected charter showing the activity-list failure in full.
If you can browse the web, check the Developer Relations Foundation (`dev-rel.org`, hosted by the Linux Foundation) for canonical definitions before inventing your own - its Metrics Index and Maturity Model are the field's only vendor-neutral reference work. Read what is actually published there rather than assuming a leveled model: the Maturity Model may define only a purpose with no levels, and it should not be presented as leveled unless the levels are genuinely there.
- `samber/developer-relations-skills@devtools-business-model` (prerequisite): defines the product's revenue model, which constrains step 2's driver choice.
- `samber/developer-relations-skills@developer-first-gtm` (prerequisite): picks the adoption motion before this strategy sets goals around it.
- `samber/developer-relations-skills@developer-journey-map` (hand-off): maps the full developer journey; this strategy pins goals to specific steps on it.
- `samber/developer-relations-skills@devrel-metrics` (hand-off): defines the measurement framework for the signals you pick per bet in step 5.
- `samber/developer-relations-skills@devrel-team-structure` (hand-off): designs org topology once this strategy sets the sequence and next hire.
- `samber/developer-relations-skills@devrel-budget-allocation` (hand-off): splits money across the pillars this strategy names.