1.5 组织归属：FDE 团队该放哪个部门

概念：组织定位决定行为模式

FDE 团队放在哪个部门，不是个行政问题，而是个机制问题。放错了地方，考核和协作方式就不对，FDE 的"学习沉淀"动作就会被挤压。

提示

组织归属决定 FDE 的命运：放在销售体系容易被当作签单赠品，沉淀动力弱；放在交付体系容易固化成项目制团队；放在产品体系有利于沉淀但可能远离一线。更合理的是矩阵制 ——行政上与产品保持强连接确保经验回流，业务上与销售、客户成功协作确保贴近客户，考核上既看客户价值也看知识产出。

展开看每种模式适合什么情况：

模式一：放交付/实施部门

适合：客户数量多、交付压力大的阶段。FDE 团队和交付团队一起调度，响应速度快。

问题：交付部门的天然 KPI 是"交付周期"和"客户满意度"，沉淀能力这种"重要但不紧急"的事会被无限挤压。一年下来，交付了很多项目，但平台能力没增长。

模式二：放产品/研发部门

适合：平台需要大量补充行业能力、快速沉淀 Skill 和知识包的阶段。FDE 团队和产品团队一起，把现场经验直接变成产品能力。

问题：研发部门离客户远，FDE 去客户现场的动力不足，容易变成"在办公室设计通用能力"——设计出来的东西到了客户现场发现不适用。

模式三：独立 FDE 团队（双线汇报）

适合：FDE 机制成熟、管理层理解"交付 + 沉淀"双目标的阶段。FDE 团队同时向"客户成功/交付"和"产品/研发"两个方向汇报，考核也包含交付指标和沉淀指标。

问题：管理复杂度高。两个婆婆管一个媳妇，如果没有明确的优先级机制，FDE 团队会左右为难。

**⚠️ 风险提示：**没有"唯一正确"的组织归属。关键原则是： FDE 团队的考核维度必须同时包含"交付"和"沉淀"两个方向。如果考核只有交付指标，放哪个部门都会变成陷阱三（考核错位）。如果考核只有沉淀指标，放哪个部门都会脱离客户现场。

某腾讯云生态伙伴的 FDE 团队是这样设计的：

这个设计的关键是"两个 50%"。如果你把沉淀设成 10%，那大家还是会全副精力扑在交付上。只有当沉淀和交付在考核里同等重要，FDE 才会真正"在交付的同时完成学习"。

FDE 的本质是一线交付型技术角色 ：不是传统的"售前支持"或"实施顾问"，而是前置到客户一线、以工程手段直接交付解决方案，并将一线实践（行业知识、系统接口、流程规则）反哺为可复用能力。
试金石是一张表 ：项目结束后，除了客户那套系统，还留下了什么？有平台能力增量 = 真 FDE；只有项目文档 = 普通；只有个人经验 = 半 FDE（最容易被忽视的坑）。
Echo 与 Delta 是两种能力侧 ：Echo 判断该做什么（更稀缺），Delta 把它做出来（AI 让它变便宜）。不需要每个人都是全栈，但两种能力都要有人覆盖。
三个陷阱要避开 ：伪 FDE（在前线但不沉淀）、传话式 FDE（判断和执行隔了一层传话）、考核错位（只考核交付不考核沉淀）。
验证交付的分水岭是评测 ：演示跑通 ≠ 验收证据，冻结样本集的统计结果才是客户付费买的"能用"；评测集本身也是可沉淀的平台资产。
组织归属看考核 ：放哪个部门不是关键，考核维度同时包含"交付"和"沉淀"才是关键。两个 50% 比一个 90% + 一个 10% 更健康。