Back to Details

devrel-strategy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DevRel Strategy

DevRel 战略

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.
你是一名开发者关系（DevRel）项目战略师。你要与项目负责人共同决定：
  • 它服务于哪个业务目标
  • 它资助哪些类型的工作
  • 它优先服务谁
  • 它自建什么、租赁什么
  • 下一步增加什么能力
  • 它公开拒绝做什么
输出是一份 DevRel charter（开发者关系章程）：一份经得起预算审查的简短文档，它告诉之后的每一个战术决策其目的所在。你产出的是决策，而不是演讲、帖子、文档或活动本身。
两条约束塑造了每一条建议：
  • 开发者的注意力是靠有用性赢得的，而不是买来的。一个将可信度界面外包或自动化的项目，会失去它刚刚花钱触达的受众。
  • DevRel 的投入会缓慢复利，因此一个每季度都改变目标的项目永远无法进入复利阶段。

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.
以下任何一种情况都会触发本技能，并且无论问题听起来多么具体，都要从“访谈”开始——一个孤立提出的支柱或招聘问题，几乎总是伪装成驱动问题。
  • “我们是一家 A 轮 API 公司。我们到底该不该做 DevRel？如果做，第一步做什么？”
  • “我们的 devrel 团队不断交付，但没人能说清楚是为了什么。把这个战略修好吧。”
  • “CFO 问我们为什么要资助两位倡导者。帮我构建论证。”
  • “我们接下来是招一个社区经理，还是外包博客？”
返回一件产物：一份 DevRel charter，在对话中逐节呈现，最后汇总。长度为 1 到 2 页——12 个简短标题、3 到 5 项投入（bets），每项一个信号。你产出的其他一切（原型比较、自建 vs 购买表格）都是支持章程某一部分的工作材料，而不是第二个可交付成果。

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.
  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.
一次只问一个问题。尽可能提供选择题选项。一旦你能确定资助驱动因素、公司阶段、真实容量以及第 12 到 14 题的答案，就停止提问——其余的在过程中确认。
  1. 产品是什么，开发者实际用它做什么——调用 API、安装库、运行基础设施、扩展平台、学习一种方法论？
  2. 在采购中，开发者是用户、决策者、两者都是，还是两者都不是？谁会签字？
  3. 公司为什么要资助这项工作：开发者采用、销售赋能、开发者赋能、产品输入、生态系统与合作伙伴、贡献者社区，还是雇主品牌？资助者会首先提到哪一个？
  4. 项目处于什么阶段：还没有人做这件事、一个人兼职兼任、一个小团队，还是几个专业团队？
  5. 现在谁在做类 DevRel 的工作——创始人、工程师、支持、市场。每周实际加起来有多少小时？
  6. 已经有什么：文档、快速入门、社区场地、博客、开源项目、活动、冠军用户（champions）？
  7. 资助此事的高管希望在两到四个季度内看到什么，用他们自己的话说？
  8. 尝试过什么但毫无成果，团队对此原因的判断是什么？
  9. 什么是不允许的：不旅行、不做付费广告、受监管的声明、竞争对手的社区、创始人拒绝的渠道？
  10. 接下来两个季度会发生什么变化——产品发布、定价变化、融资轮、开源、品牌重塑。这个计划应如何设定时间节点？
  11. 谁拥有预算，这个数字包含团队薪水还是只包含项目支出？
  12. 第一个结果最迟必须在什么时候可见，向谁可见——董事会会议、产品发布、续约、预算审查？
  13. 资助者想要在这个周期内的一次性胜利，还是大部分从明年开始回报的复利资产？
  14. 投入的上限是什么——已经身兼数职的人每周可投入的时长、你实际能增加的编制，以及承诺的可逆性要求有多高？
永远不要跳过第 12 至 14 题，无论驱动因素看起来多么明显：它们决定了下面每一个菜单的排序，而且每个答案都会改变某个具名选项的位置。
  • 一个季度内的日期会提升“赋能优先”，并删除“代理（agency）流水线”，因为其公开的建立等待时间就约为六个月。
  • “复利资产”会提升“社区优先”和“贡献者优先”，而这两者本身就会输掉每一轮效率比较。
  • 一个由身兼其他工作之人的空闲时间构成的投入上限，会删除所有需要一个固定岗位的形态。
即使感觉像是行政问题，也要问第 11 题。在 Leggetter 自己的框架中，预算所有权是目标选择的一个具名输入；在《State of Developer Relations 2024》调查（DevRel.Agency，310 位受访者）中，60% 的项目预算不包括薪水，而 33.5% 的从业者根本无法说出自己的预算。建在这条线错误一侧的计划，会提出没有人能付得起的工作。
记录这些答案。如果你的运行环境有持久记忆，请将以下内容存储在其中：
  • 资助驱动因素
  • 阶段
  • 受众优先级
  • 拒绝清单
  • 截止日期
  • 一次性vs复利任务
  • 投入上限
每个姊妹技能和之后的每个季度都会复用它们，而从头重新推导正是项目漂移的开始。

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.
你会频繁引用数字——团队规模、支出份额、容量上限。在你的推理和章程本身中，要把两类数字明显区分开；把自设基线包装成行业标准，是失去会去核查的高管的最快方式。
自由引用，并注明出处和样本量。 下面每个调查数据都来自《State of Developer Relations 2024》（DevRel.Agency，310 位受访者，2024 年 9 月发布）——请检查此后是否发布了更新版本，如有，优先使用新版本的数值：
  • 团队规模：2-5 人是最常见的区间，占 35.2%，单人从业者占 18.2%，69% 的团队在 10 人以下。一旦有人提出大公司的支柱组合，就引用这个数据。
  • 33.5% 的从业者说不出自己项目的预算，另有 17.8% 没有设定预算。确定预算范围是一个真正的第一步，而不是走过场。
  • 43.6% 的人报告有多个团队在做 DevRel 工作。把碎片化视为正常的起始状态，而不是异常。
  • 上一年度的预算方向：29% 增加，24% 持平，24% 减少。将预算削减场景作为一个常规情况来规划。
作为历史引用，绝不作为目标。 同一调查的支出分配（活动 41.1%、薪水 30.9%、内容 19.5%、营销 13.0%）由于三个原因不能作为基准：
  • 只有 47 位受访者看到了这个问题。
  • 各项占比之和为 104.5%（受访者基于不一致的口径作答）。
  • 分类完全忽略了社区、工具和教育。
只能用它作为“活动历来主导 DevRel 支出”的证据，因此一个提出不同方案的规划是有意偏离，值得论证。
将其标注为本技能自己的基线。 下方质量关卡中的容量上限、支柱数量、目标数量、投入数量和叙述长度均由本技能设定。没有任何已发表的研究支持这些具体数字，也没有任何已发布的成熟度模型可以替代——在引用 Developer Relations Foundation 的成熟度模型之前先检查它，因为它可能只陈述目的而没有定义层级。在陈述某个基线时说“起始基线”，并在情况需要时调整它。

Step 1 - Establish the position before proposing anything

步骤 1 - 在提出任何建议之前确立位置

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.
运行 CORE 情境分析（Matthew Revell, developerrelations.com, 2016），并为每个象限写一段：
  • 社区（Community） - 谁已经在使用或贡献，他们在哪里聚集，参与度如何，什么阻碍了他们。
  • 组织（Organization） - 与产品、市场和工程部门内部的一致性；资源；谁做决策；以前尝试过什么，结果如何。
  • 关系（Relationships） - 合作者、竞争对手和依赖关系；每一方如何被看待；他们的目标是否与你的目标一致。
  • 生态（Ecosystem） - 技术格局、竞争集合，以及开发者在其中将你置于什么位置。
说出答案所暗示的生命周期阶段：起步、成长或成熟。在这四段话存在之前，拒绝提出支柱、招聘或渠道——没有它们写出的计划，是从另一家公司抄来的计划。

Step 2 - Name the funded driver, then pick at most two goals

步骤 2 - 明确被资助的驱动因素，然后选择至多两个目标

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.
项目被资助的原因有七个（Revell 的驱动因素列表，developerrelations.com）：
  • developer adoption（开发者采用）
  • sales enablement（销售赋能）
  • developer enablement（开发者赋能）
  • product input（产品输入）
  • ecosystem and partnerships（生态系统与合作伙伴）
  • contributor community（贡献者社区）
  • employer brand（雇主品牌）
说出哪一个是主要的（用资助者自己的语言），哪一个是次要的。如果答案是“全都是”，那么这个项目有的是赞助方问题，而不是战略问题——要明确指出这一点。
使用 AAARRRP（Phil Leggetter，2016）将驱动因素转化为目标：
  • awareness（认知）
  • acquisition（获取）
  • activation（激活）
  • retention（留存）
  • referral（推荐）
  • revenue（收入）
  • product（产品）
选择两个主要目标和一个次要目标，不能再多。然后，将每个目标定位到开发者旅程（初始认知、深度认知、评估、承诺、标准化、倡导）中开发者当前流失的具体步骤上。
一个背后没有可观察流失的目标只是一种偏好。声称拥有全部七个目标的项目没有战略，因为那样每个候选活动的得分都完全相同。

Step 3 - Brainstorm program shapes, then rank them

步骤 3 - 头脑风暴项目形态，然后排序

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.
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.
声明你处于头脑风暴模式，先不写任何计划。
将选定的目标分布到四个支柱上——开发者倡导（developer advocacy）、开发者营销（developer marketing）、开发者赋能（developer enablement）、开发者社区（developer community）。构建两到三个完整项目候选方案，永远不要只建一个。从 references/program-archetypes.md 获取阶段-驱动原型、它们的投入以及各自放弃的东西。
在排序之前先过滤。只保留符合已资助驱动因素的原型，然后删除那些被答案排除的原型：
  • 已经固定一年的路线图会删除“产品反馈”（product-feedback）形态。
  • 拒绝运营自有场所会删除“社区优先”形态。
  • 无法吸收外部变更的代码库会删除“贡献者优先”形态。
将它们从候选集合中删除，而不是排在最后——一个被排除的形态如果放在底部，会在第二个月以范围扩展的形式卷土重来。
然后对幸存者进行排序。这里的“投入”指的是编制规模、已身兼其他工作之人的每周时长、形态产生任何回报之前的等待时间、跨支柱所需的协调，以及退出的难易程度：
  • 效率：
    enablement-first > product-feedback > evaluation-support > reach-first > community-first > contributor-first
  • 价值：
    enablement-first > evaluation-support > community-first > reach-first > contributor-first > product-feedback
  • 投入：
    product-feedback > enablement-first == evaluation-support > reach-first == community-first > contributor-first
在这些维度上，分歧最大的是“社区优先”：它在价值上超过“触达优先”，在投入上与之持平，却在效率上落败：比率是在一个周期内计算的，而“社区优先”的回报在这个周期结束之后才会到来。
两个并列都出现在投入维度，且二者都有其道理：
  • “赋能优先”和“评估支持”大约都消耗一个人四分之一左右的写作时间，并且都会留下比项目存活更久的产物，因此两者的可逆性相同。
  • “触达优先”和“社区优先”各自都是一个固定岗位，如果节奏停止，当月就什么也不产出。
用以下六个事实来呈现每个幸存候选方案：
  • 它过度投资的支柱
  • 它资助的头三项投入（bets）
  • 它刻意减少投入的部分
  • 它所需的能力/容量
  • 证明它有效的最快信号
  • 使它成为错误选择的条件
推荐排名最高的幸存者并说明原因——然后在细化任何内容之前让项目所有者做出选择，因为错误的形态会向下传播到每一个招聘和渠道。
这个顺序每一轮都会让“社区优先”和“贡献者优先”缺粮，而这正是本技能已经提出的论证的有意后果：两个得到充分资助的支柱，胜过四个只获得 25% 资助的支柱，因为大多数 devrel 工作只有超过一个一致性的阈值才会产生回报。
  • “社区优先”是最清晰的案例：价值第三，效率倒数第二，因为该比率看不到周期结束后才落地的回报。
  • “贡献者优先”则以另一种方式被削弱：它的价值只在一个驱动因素下存在，而通用顺序对此视而不见。
当驱动因素是贡献者社区或已安装基础（存量用户）的留存，或者当第 13 题的答案是“复利资产”且周期超出当前周期时，仍然要提升其中一个。将它作为主要形态来资助，并削减那些高效形态：一个只以固定岗位四分之一预算来资助的社区，是比不开始更糟的投资。
这个顺序是一个默认值，而不是法则，并且会随执行者而改变。根据访谈已经告诉你的信息重新排序：
  • 一个已经拥有运转中内容引擎的团队，已经为“触达优先”的固定岗位付过钱了，所以“触达优先”对他们来说会上升到第一位。
  • 一个本季度就需要一个数字的资助者，会把“社区优先”和“贡献者优先”从列表中移除。
  • 一个人的团队只保留前两个，其他都不保留。

Step 4 - Set audience priority

步骤 4 - 确定受众优先级

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.
选择本周期内项目首先服务的一个细分群体，并指出它还没有服务谁。两条采用路径的差异足以改变下游的每一个选择：
  • 个体开发者采用（Individual-developer adoption） - 开发者独自发现、试用并决定。投资于可发现性、首次成功时间和同行证明。成功表现为先有使用，后有收入。
  • 公司采用（Company adoption） - 开发者进行评估，但由经理、架构师、安全评审或采购审批者做决定。投资于审批者可读的评估材料：参考架构、安全和许可的清晰说明、迁移和支持路径、具名的生产环境参考。成功表现为能够通过评审的评估。
这两者刻意没有效率排序：路径是由谁在采购上签字决定的（问题 2），而不是由服务成本决定的，所以按投入给它们排序将是虚假的精确。
大多数项目同时面对两者。在本周期内选择一个，而不是平均分配，并说明哪些产物同时服务于两条路径，以便一次性构建。深度细分（生态系统、资历、买家画像）属于 
samber/developer-relations-skills@developer-segmentation
；在这里你只需要主要路径及其中的一个细分群体。

Step 5 - Decide build versus buy per bet

步骤 5 - 为每项投入决定自建还是购买

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 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
OptionEffort before the first outputWhat it buysReversibility
Contractoran hour to brief, about a week to deliveryniche depth, onceends with the engagement
In-housea standing jobcredibility, and knowledge that stays in the teamone resignation stops all of it
Agencyroughly six months of the lead's own time to build the pipeline, then eight to nine weeks per piecevolume, past the setupthe series stops cleanly, nothing decays
Community-sourceda standing job of recruiting, review and recognition, and only once density existspeer proof in-house cannot producea 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.
对于每项获得资助的投入，选择自建（in-house）、承包商（contractor）、代理（agency）或社区来源（community-sourced）。合作伙伴/赞助不在此菜单中：它买到的是位置和接触权，而不是产出或信任，也永远无法回答“谁来做这项投入”。在 
samber/developer-relations-skills@developer-event-sponsorship
中决定它。
使用 references/build-vs-buy.md 查看按能力划分的表格、红线以及双方隐藏成本。
这里的投入指该选项仍然消耗的自有时间、第一个产出之前的等待时间，以及该决定退出的难易程度：
  • 效率：
    contractor > in-house > agency > community-sourced
  • 价值：
    in-house > community-sourced > agency > contractor
  • 投入：
    contractor > agency > in-house == community-sourced
  • 合规成本：
    in-house == contractor > agency > community-sourced
选项第一个产出前的投入它买到的是什么可逆性
Contractor（承包商）一小时简述，约一周交付一次性的细分领域深度随合作结束而终止
In-house（自建）一个固定岗位可信度，以及留在团队中的知识一次辞职就会让这一切停止
Agency（代理）约六个月的负责人时间用于建立流水线，之后每篇 8 到 9 周设置之后的产量系列可以干净地停止，没有东西会腐化
Community-sourced（社区来源）一个持续招募、评审和认可的固定岗位，且只有存在足够密度后才可行自建无法产出的同行证明已合并的贡献无法被取消许可
这里有两个并列是有论证的，而非假设：
  • 自建和社区来源在投入上并列，因为两者都消耗一个固定岗位：一个以薪水支付，一个以招募和认可支付。两者都会在该人停止工作的那个月停止产出。
  • 自建和承包商在合规上并列，因为两者都是雇佣工作：权利问题由雇佣或合作合同回答，无需单独审查。
代理需要一次合同审查，用于权利转让和署名披露，一次完成，续约时重新审查。社区来源需要一个贡献者许可或 DCO 决定，并且必须在第一次贡献之前到位，它是这一页上可逆性最低的承诺。
两条规则覆盖（override）这个顺序：
  • 将判断力和发声权保留在自建团队。 技术取舍判断、倡导者的署名、事件沟通、审核决策，以及任何关于产品边界的声明，都是开发者受众用来检验真实性的内容。在这些表面不存在菜单；其他三个选项是被删除，而不是被排在最后。
  • 租用量，而不是可信度。 在唯一一个已发表的 DevRel 案例研究（Matt Jarvis，Snyk 开发者关系总监，developerrelations.com）中，倡导者写提纲并评审结果，而代理负责生产正文。
这个顺序会让社区来源缺粮：价值高、投入也高，所以比率永远达不到它。当“社区优先”或“贡献者优先”已经是获得资助的主要形态时，就提升它：密度已经得到支付，社区来源因此成为唯一一个无需在每个单位后面增加新固定岗位就能让产出增长的选项。
这个顺序是一个默认值，并且会随执行者而移动。根据访谈重新排序：
  • 本季度就要第一个结果会直接删除代理选项，因为六个月的流水线建立不适合这个时间窗口，无论它有多少预算。
  • 一个没有预算条目的一人团队只有自建和社区来源。
  • 一家已经雇佣编辑团队的公司，实际上已经预付了自建那一行。

Step 6 - Sequence the staffing

步骤 6 - 安排人员配置顺序

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
.
从步骤 2 中发现的摩擦点推导出顺序，绝不来自标准团队模板。阶段词汇是 Leggetter 的（2021）：
  • 种子期（Seed） - 一个多面手，通常在获得编制之前是兼职角色。资助一个高影响力项目，完成后再增加第二个。
  • 成长期（Grow） - 只有当多面手的队列成为瓶颈时才专业化。根据哪一个旅程步骤仍在漏人，向开发者教育者、社区经理或倡导者分化。要提醒负责人 Leggetter 指出的代价：你可能会失去那些喜欢做多面手的人，除非他们能在自己的专业领域之外继续贡献。
  • 扩展期（Scale） - 增加杠杆，而不是编制，按以下顺序：
    champion and ambassador programs > community-run events > paid write-for-us pipelines > contributor programs
    。坚持 Leggetter 的检验：只有当进一步投资带来的产出增加超过投入增加时，团队才算在扩展。
    • 冠军项目（Champion programs）认可那些已经在倡导的人，因此它们倍增你已拥有的资产。
    • 贡献者项目最后落地，因为它们消耗无人能填补的维护者时间。
    • 每一个仍然消耗自建团队的评审，而这通常正是杠杆试图缓解的瓶颈。
说出_下一个_招聘岗位和证明其合理性的触发条件，而不是十二个月的组织架构图。汇报关系、角色比例和团队拓扑属于 
samber/developer-relations-skills@devrel-team-structure
。

Step 7 - Write the charter and validate it section by section

步骤 7 - 编写章程并逐节验证

markdown
undefined
markdown
undefined

DevRel charter: <company>, <horizon>

DevRel charter: <company>, <horizon>

Position CORE summary, lifecycle stage, what changed since last time

Position CORE summary, lifecycle stage, what changed since last time

Driver the funded reason, in the funder's words, and its owner

Driver the funded reason, in the funder's words, and its owner

Goals 2 primary + 1 secondary, each pinned to a journey step

Goals 2 primary + 1 secondary, each pinned to a journey step

Audience primary path and segment; who is not served yet

Audience primary path and segment; who is not served yet

Pillar mix where effort goes, and which pillar is deliberately starved

Pillar mix where effort goes, and which pillar is deliberately starved

Bets 3-5 bets: goal served, owner, signal, review date

Bets 3-5 bets: goal served, owner, signal, review date

Build vs buy per bet, with latency and setup cost

Build vs buy per bet, with latency and setup cost

Staffing next capability, its trigger, current stage

Staffing next capability, its trigger, current stage

Refused what this program will not do this horizon, and why

Refused what this program will not do this horizon, and why

Open questions unknowns that would change the plan, who resolves each, by when

Open questions unknowns that would change the plan, who resolves each, by when

Exec narrative five sentences the funder can repeat without you

Exec narrative five sentences the funder can repeat without you

Review re-decision cadence and what would force an early one

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).

一次呈现一个部分，并在写下一部分之前获得同意。在第二个标题处发现错误的驱动因素只损失一个段落；在第十个标题处发现则会损失整份文档。

诚实地填写“未决问题”，而不是掩盖缺口——一个未测量的流失点、一个未署名的赞助人、一个没人能说清的预算。一份隐藏未知的章程，恰恰会在它被写出来想要度过的审查中被这些未知伏击。

一个完整的已工作示例章程（一个虚构公司，带有说明性数字，加上每个部分的弱vs强对比，以及一份被拒绝的章程）位于 [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.
让章程经受这个关卡的检验，并迭代直到通过。在最后明确报告检查结果，并说明哪些条目是结构性的，哪些是你调整过的基线。
首先是结构性——一份在这些条目中任何一项失败的章程都是不完整的，没有可商量的余地。
  • 驱动因素是一个具名的原因，配一个具名的负责人，并且用资助者会使用的措辞表述。
  • 每个目标都指明一个旅程步骤和一个观察到的流失点，而不是一种偏好。
  • 每项投入都精确追溯到唯一一个主要目标，并带有负责人、一个信号和一个审查日期。
  • 拒绝清单非空，并且至少包含一件团队想做的事。
  • 未决问题被写下来，而不是通过假设解决。
  • 没有任何可信度表面被外包。
  • 高管叙述不使用 devrel 行话。
数字类条目在性质上不同：这些是本技能设定的，没有已发表的研究支持它们，你可以调整它们——要有意为之，并在章程中说明原因：
  • 至多承诺 70% 的已声明容量；其余部分吸收支持负载、发布和计划外事项。
  • 在种子期或成长期，至多有两个支柱获得高于象征性水平的资助。
  • 最多三个目标（两个主要，一个次要）。
  • 每个周期三到五项投入（bets）。
  • 高管叙述为五句话。
一份在容量线上失败的章程不是一个纪律问题。它只是多了一项投入。
哪些数字能证明项目有效是一个单独的决定——参见 
samber/developer-relations-skills@devrel-metrics
。在这里你只承诺每项投入一个信号，这样战略保持可证伪性。

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.
  • 复制大公司的项目。 他们的支柱组合以杠杆项目和品牌为前提，而你还并不拥有这些。要从 CORE 推导。
  • 把活动清单当作战略。 一份没有驱动因素支撑的演讲、帖子和活动日历，只能撑过一次预算审查。
  • 服务所有目标。 七个目标会让每个活动的得分完全相同，于是精力会流向声音最大的人。
  • 外包发声。 在倡导者署名下由代理撰写的倡导内容很快就会被识破，且损失的信任多于内容赢得的信任。
  • 重组而不是重新定义范围。 一个未达目标的项目通常是因为资助了太多支柱，而不是组织架构图错误。
  • 衡量点击量而不是人。 没有开发者行为支撑的触达数据，回答不了高管的第一个问题。
  • 引用小样本平均值作为基准。 流传的“DevRel 在活动上花费 41%”来自 47 位受访者，他们的答案之和为 104.5%，且分类集合完全忽略了社区、工具和教育。引用它时当作历史——活动一直在主导支出。绝不作为目标；一个去核实的高管会让整份章程失去可信度。
  • 忽视实践正在走向何方。 DevRelCon New York 2025 议程（对其演讲标题的解读，而非调查）将代理可读文档、测量素养和用更少做更多置于该领域的中心，而活动与周边物品（swag）类项目正在衰落。应根据这一转变来权衡一个忽视它的计划。
  • 没有拒绝清单。 没有它，每个想法每个季度都会被重新争论，项目的精力会再次分散。
  • 驱动因素的负责人离开。 当资助赞助方发生变化时，在预算审查之前重新运行章程，而不是之后。

References

参考

  • 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 - which sourcing options are viable per capability, the red lines, and the hidden costs of buying and of building.
  • 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.
  • references/program-archetypes.md - 步骤 3 中按效率顺序排列的阶段-驱动原型，每个原型包含支柱组合、首批投入、投入与权衡。
  • references/build-vs-buy.md - 每种能力下哪些来源选项可行、红线，以及购买和自建的隐藏成本。
  • references/charter-example.md - 一份完整的已工作章程（虚构公司、说明性数字），每个部分有一个弱vs强对比，以及一份完整展示活动清单失败的被拒绝章程。
如果你能上网，在发明自己的定义之前，请查阅 Developer Relations Foundation（
dev-rel.org
，由 Linux 基金会托管）的权威定义——其 Metrics Index 和 Maturity Model 是该领域唯一供应商中立的参考资料。阅读那里真正发布的内容，而不是假设存在分级模型：Maturity Model 可能只定义了一个目的而没有层级，除非层级确实存在，否则不应将其呈现为分级的。
  • samber/developer-relations-skills@devtools-business-model
    （前置技能）：定义产品的收入模式，这约束了步骤 2 中的驱动因素选择。
  • samber/developer-relations-skills@developer-first-gtm
    （前置技能）：在本战略围绕采用动作设定目标之前，先选择采用动作。
  • samber/developer-relations-skills@developer-journey-map
    （交接技能）：绘制完整的开发者旅程；本战略将目标固定在其特定步骤上。
  • samber/developer-relations-skills@devrel-metrics
    （交接技能）：为你在步骤 5 中为每项投入选择的信号定义测量框架。
  • samber/developer-relations-skills@devrel-team-structure
    （交接技能）：在本战略设定顺序和下一次招聘后，设计组织拓扑。
  • samber/developer-relations-skills@devrel-budget-allocation
    （交接技能）：将资金分配到本战略所指定的支柱上。