当 DevRel 团队汇报线、团队形态…

为 DevRel 负责人设计汇报线、团队形态、职能覆盖、接口与再组织触发条件的 org design brief。

适用场景

解决思路

1. 先与对 DevRel 职能负责的人对齐：确定汇报线、团队形态、覆盖职能、与相邻团队接口、以及触发下一次重组的条件；产出物是 DevRel org design brief，不是招聘帖、面试流程或具体工作。
2. 把 2024 State of Developer Relations（DevRel.Agency, 310 人）的两条事实作为背景：汇报线无多数（marketing 33.1%、product 21.7%、CEO 20.3%、engineering 19.9%、sales 3.2%），放置是权衡不是最佳实践；43.6% 的团队已有多个团队做 DevRel 工作，因此通常是在重画既有边界。引用前检查是否有更新版本，并保留引用年份。
3. 按一次一个问题、尽量多选的方式做访谈；一旦能说出 funded driver、headcount、existing owners 就停止，其余边做边确认。
4. 问：今天有多少人做 DevRel 工作，其中多少全职？
5. 问：今天哪些职能已被覆盖（即使部分覆盖）：advocacy、community、technical writing、developer marketing、developer education、developer-experience engineering？
6. 问：这些职能目前各自向谁汇报？要具体到 manager，而不是团队。
7. 问：公司为什么资助这件事：developer adoption、sales enablement、developer enablement、product input、ecosystem、contributor community、employer brand？
8. 问：开发者是 user、buyer、两者都是，还是都不是？
9. 问：团队当前服务多少条产品线、SDK 语言、地区和社区？
10. 问：是什么触发了这个问题：新 hire、re-org、leader 离开、budget review，还是工作掉到缝里？
11. 问：哪些没人计划的工作总落到这个团队？
12. 问：谁拥有 headcount budget，谁拥有 program budget？二者常常不是同一个人。
13. 问：什么是政治上固定的：不能改的汇报线、不能动的 manager、公司强制的 title convention？
14. 问：新结构必须何时到位，什么驱动这个日期：一次 hire、re-org window、board review？
15. 问：你要的是一次性解决当前痛点，还是随公司增长可复利的结构？
16. 问：努力上限是多少：能新增多少 headcount、每周能投入多少小时跨团队协调、能为可能撤销的变更花多少政治资本？
17. 用问题 11-13 重新给团队形态排序，并说明哪个答案推动了哪个形态：硬性近期日期促进 centralized；复利 mandate 促进 hub-and-spoke；以 headcount 表示的上限删除所有 staffing floor 高于它的形态；拒绝花政治资本删除 embedded。
18. 记录访谈答案；如果运行环境有持久记忆，存储 funded driver、current owners map 和 reporting line，因为下一次 re-org 会从同一份清单开始。
19. 第一步永远是访谈，然后是 work inventory，绝不先画组织图。
20. 对每个数字打标签：引用来源时带来源和年份；把自设基线标为「本技能自设，可调整」；直接拒绝 headcount ratios 和 compensation bands。
21. Step 1：在画任何图之前盘点工作。列出公司已承诺的每个 recurring DevRel surface：docs set、quickstart、blog、community venue、event calendar、SDK set、sample apps、champions cohort、changelog、support presence、OSS repos。
22. Step 1：对每个 surface 记录四列：今日 owner（具体人）、其 manager、每周实际耗时、如果停掉会发生什么。
23. Step 1：把每个 surface 标为 owned、shared、unowned，或被不同 title 的人 informally absorbed。
24. Step 1：在这张表存在之前拒绝提出结构；跳过它会重新分配原本由隐形人做的工作，该人会在组织图改变当天停止做。
25. Step 2：选择汇报线。选择其 leader 拥有问题 4 的 funded driver 的那条线：adoption/awareness 指向 marketing；product-input/enablement 指向 product 或 engineering；sales enablement 指向 product 或 marketing 并加 sales interlock，不指向 sales；founder-led 且无其他可信 sponsor 指向 CEO，并附 re-decision date。
26. Step 2：为每条线列出它优化什么、饿死什么、典型失败、反制动作、以及何时是错误选择（references/reporting-line-tradeoffs.md）。
27. Step 2：用四部分格式陈述选择：DevRel reports to `<function>`，因为 funded driver 是 `<driver>` 且 `<leader>` 拥有它。这条线会饿死 `<pillar>`。`<named person or team>` 覆盖该缺口，在 `<date>` 复审。必须命名被饿死的 pillar，否则失败会静默发生。
28. Step 3：选择团队形态。按单位努力的价值排序，努力 = standing headcount + 每周新增协调 + 撤销难度，绝不用 salary 表示。
29. Step 3：记住三种排序：效率：centralized > hub-and-spoke > split by focus > embedded；价值（roadmap proximity 和 product feedback）：embedded > hub-and-spoke > split by focus > centralized；努力：embedded > split by focus > hub-and-spoke > centralized。排序故意不一致。
30. Step 3：评估 centralized：一个团队、一个 manager、一个 budget 服务一切。Floor 一人，新增协调近零，一周可撤销；买到共享 calendar、共享 voice、一个说不的地方；代价是远离各产品线，以及内部客户超过一个 manager 能排优先级后出现请求队列。
31. Step 3：评估 hub-and-spoke：小 hub 拥有 craft、standards、tooling、calendar；spokes 贴近产品线或区域执行。Floor 为 2-3 人 hub + 至少 2 个 spokes + management layer + standing forum，一个季度建立、一个季度撤销；买到一致性加本地性；代价是 hub 一旦开始审批工作而非赋能，就成瓶颈。
32. Step 3：评估 split by focus：两个团队放在不同 parent 下，按工作目的划分。Floor 约 8 人，因为每半边都需要可行团队；协调是永久而非搭建期，撤销需要两个 leader 同意各让出一个团队；买到 enablement 和 awareness 同时有深度；代价是共享 voice 问题：两个团队、一个受众、两套 calendar、两套 metric。
33. Step 3：评估 embedded：advocates 汇报进 product、engineering 或 regional teams。Floor 为每个 host team 一名 advocate + 某处有 craft owner；协调是长期工作；最不可逆，因为每个 advocate 由 host manager 定级和晋升，而该 manager 拥有该 headcount；买到最好的 product feedback；代价是共享 craft、共享 calendar，通常还有 career ladder。
34. Step 3：注意默认排序会饿死 embedded：普通情况下效率最后，但它是 DevRel 最常被资助产出的第一项。仅当四条同时成立才提升它：问题 4 的 funded driver 是 product input；产品线有真正不同的受众；每个 host team 能出资并能定级该角色；host teams 之外仍有命名的 craft owner。缺一条，embedded 换来的反馈就无法转成工作。
35. Step 3：把答案排除的形态删除，而不是降级保留，并说明删了哪些。全职约 10 人以下时，split、embedded、hub-and-spoke 都出局，只剩 centralized。十人线是本技能基线，不是已发表发现；survey 支持的是背景：69% 团队少于十人，其他形态会把 headcount 花在常见情况下没有的协调上。被排除却留在列表底部的形态会在一个季度后作为 scope 重新出现。
36. Step 3：把排序当默认而非法律，按上下文和执行者重排：host team 已出资并定级的 advocate 已为该产品线预付 embedded 的努力；问题 10 的政治固定线会删除需要移动它的形态；问题 11-13 也会重排。
37. Step 3：对任何增加人或管理层级的形态，用 Phil Leggetter 的 scaling test（leggetter.co.uk, 2021）检验：只有进一步投资带来的产出增长超过投入增长，才算真正在扩展团队。两个 extra hires 只产出两个人的量，就是只买到了协调。
38. Step 3：推荐前明确进入 brainstorming mode，构建 2-3 个完整候选结构，每个候选都是 line、shape、coverage split 的组合。为每个候选给出：什么变容易、什么变难；假设的 headcount；新增的每周协调和撤销成本；第一件会坏的事；在什么条件下它是错误选择。
39. Step 3：按效率给候选排序，推荐一个并说明理由，让 accountable person 先选择，然后再细化下面内容。一次通过就决定的结构会被重新争论一年；相对两个被拒替代方案选出的结构能站住。
40. Step 3：形态选定后读 references/team-shapes-and-interlocks.md 获取示例和 per-shape guard。
41. Step 3：用 Conway's Law 做 sanity check（Hoopy/Common Room job-titles report，Revell and Shardlow, May 2023）：DevRel 团队结构会印刻到工作上。按产品线拆分产生 per-product content 和无跨产品故事；按渠道拆分产生 channel metrics 和无 journey。
42. Step 4：先定覆盖，后定 headcount。对六个职能各标一个状态：本团队拥有、另一个命名团队拥有、与命名对象共享及如何拆、无人拥有、或有意拒绝。六个职能：Advocacy、Community management、Technical writing、Developer marketing、Developer education、Developer-experience engineering。
43. Step 4：用 2024 survey 覆盖率做现实检查：Advocacy 82.2%、Community management 52.7%、Technical writing 42.7%、Developer marketing 37.7%、Developer education 35.6%、Developer-experience engineering 27.4%。部分覆盖是常态，未拥有职能要记为决策，不能藏成尴尬。
44. Step 4：覆盖图完整后才把覆盖转成人数。两条基线：每个 surface 需要一个 accountable owner 和一个 named backup；bus factor 为一是等着辞职的 outage。按不超过申报 capacity 的 70% 做计划；support、launches、travel 占其余，按 100% 计划会在一季度内变成计划外加班。
45. Step 4：覆盖缺口有四种解决方式，不是一种：Hire；Re-scope 到现有 owner；书面 Refuse 该 surface；Contract it out。外包是 program-strategy 决策，但组织后果归你：外包 surface 仍需一个内部 accountable owner，否则合同结束当天它消失。
46. Step 4：三个核心角色的职责拆分用 Mary Thengvall 的 awareness → enablement → engagement 映射（2021）：Advocates 拥有 awareness；Developer experience 拥有 enablement；Community management 拥有 engagement。它是最清晰的已发表划分，对内外都适用。
47. Step 4：拒绝把 headcount ratio 当 benchmark 陈述。所有流传的 advocate 对 developer、产品线或工程师的比例都是单公司轶事，不是测量标准。从 Step 1 的 surface 表推导人数，并说明你就是这么做的。
48. Step 4：受众改变职能配比：个人开发者采用偏重 advocacy、community 和 content；公司/企业采用偏重 enablement、developer-experience engineering 和 technical writing，因为审批者读的是文档而不是演讲。多数项目两者都面对：按当前 horizon 排序，而不是平均拆分。消费营销组织模式不可迁移；开发者受众评估 artefact，从不评估 campaign。
49. Step 5：定义接口。没有接口的组织图只是把争论挪个位置。对每个相邻团队——product、engineering、docs/technical writing、support、developer marketing、sales、customer success——声明一种交互模式，借用 Team Topologies：Collaboration（为发现新事物在限定时间内一起工作，高带宽、时间盒，适合 launch 或新 SDK）；X-as-a-service（一方提供、一方消费，通过清晰接口，适合 docs 请求、review 队列、event 支持）；Facilitation（一队辅导另一队，适合教工程师写作或运营 champions program）。
50. Step 5：每个相邻团队只选一种模式（本技能规则，不是 Team Topologies 的）：多于一种就没人能说清边界。Collaboration 是最贵模式；一个团队同时与 product、marketing、support、sales 永久 collaboration，不是 integrated，而是 interrupt-driven。中断负荷已真实存在：39% 团队每周与 product 协作，39% 与 engineering 协作。
51. Step 5：每个 interlock 写成一行：`<team> - <mode> - <what crosses the boundary> - <who arbitrates when it stalls>`。仲裁列是大家跳过、但会被用到的列。
52. Step 6：说明团队角色坐在哪个 career ladder：engineering ladder、marketing ladder，还是 DevRel-specific ladder。借来的 ladder 会用不描述其工作的标准来晋升，这是慢速 retention leak，不是响亮失败。
53. Step 6：检查 title 与 scope 是否匹配：如果最高一级是负责公司级目标的 manager，该角色就值得 director 的 title 和影响力（Kim Maida, “Advocate to Exec”, DevRelCon 2021）。“Head of” 对内对外都模糊，要解析成真实 level。
54. Step 6：如果形态增加 manager，检查 span：lead 带两个 report 和 manager 带十四个人都值得质疑。说明该检查来自 general management practice，因为没有 DevRel 专属 span 数据。
55. Step 6：分别记录谁拥有 headcount budget 和谁拥有 program budget。60% survey 项目中员工薪资不在 DevRel program budget 内，所以批准 event 的人常常不是批准 hire 的人。program budget 在各 pillar 间如何分配是另一个决策。
56. Step 7：写 brief，并逐节验证。使用模板：`# DevRel org design brief - <company>, <date>`；Situation；Work inventory；Reporting line；Shape；Coverage；Roles；Interlocks；Ladder & titles；Budget；Re-org triggers；Transition。
57. Step 7：写每个数字时立刻附上标签——来源和年份，或「our baseline, adjustable」——不要最后统一清理。读者永远不应猜数字属于哪类。
58. Step 7：一次只呈现一节，获得同意后再写下一节。第三节发现汇报线错误只花一段话；第十一节发现要花整份文档。
59. Step 7：需要完整示例时读 references/org-design-brief-example.md，其中包含 contested sections 的弱版和强版。
60. 收尾：写 re-org triggers，作为可观察条件而非日期：funded driver 变了，或拥有它的 sponsor 离开；第二个团队开始做 DevRel 工作且没有声明 interlock；任何 surface 失去 backup 并保持 bus factor 为一整个季度；团队因覆盖不足第三次拒绝同一类请求；headcount 越过十人线，其他形态变得可负担；interlock 在创建它的事情结束后仍停留在 collaboration 模式。提前命名触发条件，把下一次 re-org 从政治事件变成计划事件。
61. 质量门：按阈值检查并迭代直到通过，最后明确报告检查结果：work inventory 为每个 surface 列出具体人（包括不归本团队的 surface）；reporting line 命名 driver、leader、被饿死 pillar 和覆盖者；shape 由它买到的协调来论证，不是由大公司做法，且被排除形态已删除而非列在底部；六个职能都有五种覆盖状态之一，无空白；没有 surface 在未标记已知风险时 bus factor 为一；每个相邻团队恰好一种 interaction mode 和命名 arbiter；计划工作不超过申报 capacity 的 70%，且 brief 说明该上限是选定基线；每个数字都有来源+年份或明确 baseline 标签；不把 headcount ratio 当 benchmark 引用，完全不出现 compensation band；re-org trigger 列表非空且无需 survey 即可观察。
62. 如果 brief 不通过 capacity 线，不要当作纪律问题；它多了一个 surface，修复方式是移走、拒绝或配人。
63. 避免常见失败：先画组织图；照搬大公司形态；用重组代替重新划定 scope；引用 staffing ratio；把基线提升为标准；静默导入通用组织 benchmark；把 docs ownership 留在隐含状态；汇报给 sales；CEO 线没有到期日；从另一条 ladder 借 title；每个新 leader 都来一次 re-org。
64. 相关决策拆走：program budget 在各 pillar 间的拆分用 samber/developer-relations-skills@devrel-budget-allocation；招聘、面试 loop、ramp plan 用 samber/developer-relations-skills@devrel-hiring；当结构问题其实是 platform-team 问题时看 samber/developer-platform-skills。

适用边界 · 注意事项

• 不要用它做 program budget 在各 pillar 间的分配，改用 devrel-budget-allocation。
• 不要用它写招聘帖、面试流程或 ramp plan，或执行具体 DevRel 工作；那些改用 devrel-hiring 或相应流程。
• 当问题本质是 platform team 结构时，改用 developer-platform-skills。