带领 FDE 团队

证据覆盖了什么

先说局限，因为局限很大。没有人研究过 FDE 团队该怎么管：一位 FDE 能同时承担多少次交付，一位管理者能带多少位 FDE，哪种团队形态交付得更频繁，哪些指标能预示一次好的交付，都没有数据。没有任何 T1 证据，T2 材料都是自报的：人员规模、内部转岗的比例，以及一位高管描述他自己的团队。其余的是两份管理者招聘启事（作为雇主要求什么的一手证据；作为这份工作实际怎么做的证据，属于 T4），以及几则转述的其他团队的情况。除此之外，这里的一切都是本书自己的论证。章末的模板建立在“当交付失败时”的五个条件和“压力下的判断”的四个承诺之上。它是一位从业者的设计，没有被证明有效。

论证是这样的。FDE 管理者带的并不是一支恰好坐在客户那里的工程师团队，而是一个交付组合。有三个决定只属于管理者：哪些客户能得到 FDE；每个客户那些承重的承诺是否仍然成立；以及一线的工作有没有回到产品。一支按用掉的或计费的工时来管理的团队，不管章程怎么写，都会滑向服务，因为填满工时的正是服务。Jarvis 说，他在那些本想成为产品公司的咨询公司里，见过同样的滑落，它们被“服务收入的短期诱惑”拽了回去（引自“起源与经济账”；T4，一位从业者的经验）。下面每一节，都是管理者要么顶住这股拉力、要么悄悄向它让步的一个地方。

招聘启事笔下的这份工作

有两份招聘启事把这份工作定义得比任何文章都精确。Anthropic 的第一份 FDE 管理者启事称它是“一个兼顾带队与实干的角色，并明显偏向领导”。管理者要离得足够近，能够“审查架构、调试生产问题，并在关键时刻和团队结对”，但“你的主要影响将来自你招进来的人、你设定的标准和你营造的文化”。这些职责虽然没用“组合”这个词，实质就是管理一个组合。管理者要“在团队的整个组合中为客户交付配置人员并加以监督，在资源分配上平衡客户需求、团队成长和业务优先级”，还要与客户经理团队合作，“在售前阶段评估交付是否值得做、划定工作范围，并为工作说明书提供依据”。它还要求“可复用的操作手册、起步代码仓库”和“交付评审”。交付的后勤和干系人管理归另一个角色，交付经理（Anthropic，Manager, Forward Deployed Engineering；T4）。

OpenAI 的启事对管理者如何被评判说得更直接：“你的成功将以这几点来衡量：你的团队交付得有多稳定，你向研究和产品团队传递信号有多清晰，以及你的团队和交付模式证明自己有多持久。”管理者必须“定义我们如何为一线团队配置人员并提供支持”，同时仍要“编写并审查生产级代码”（OpenAI，Manager, Forward Deployed Engineering - NYC；T4）。

两份启事都没有提到利用率、可计费工时或人均收入；17.6 节会论证它们是对的。两份都希望管理者继续写代码，这就带出第一个实际问题：写多少？一条经验法则，出自本书，未经检验：审查、结对、帮人解围，但绝不亲自承担一次交付里的重阶段。一位亲自负责评测爬坡的管理者，会连续几周不再看整个组合，而别人也不会去看。如果你更想提高别人工作的标准，又不想为他们的职业发展或人员安排负责，“职级、倦怠与下一步”里的 Staff FDE 路线是另一扇门。

产能就是战略：挑选客户

组合的第一个决定，是哪些客户能得到 FDE，而做这个决定的常常是别人。销售承诺了一位工程师，刚好有人空着，于是在任何人问这个客户图什么之前，人就已经派过去了。“起源与经济账”论证过，每一位 FDE 都是一次押注，押的是今天的一线工作会变成明天的产品。让销售挑客户的管理者，等于让销售来下注。

关于有意识地挑选，Jarvis 给出了最清楚的公开说法。OpenAI 把它的 FDE 产能“按这两根杠杆”来分：一类是为某个明确的产品假设而选的设计合作伙伴，比如客户服务或临床试验文档撰写；另一类是半导体或生命科学这样的行业，那里的问题能教会模型一些东西。“起源与经济账”讲了其中的经济账（Altimeter Capital，对 Colin Jarvis 的访谈，2025 年 11 月；T2，供应商高管描述自己的团队）。他给想组建这种团队的人的建议，正是管理者的那一份：“要非常清楚这支 FDE 团队的目的是什么”，以及“要准备好在一些非常艰难的时刻说不，比如你知道有人会出很多钱，让你去做一件不具战略意义的事”（同一来源；T4，建议）。

大多数雇主不是实验室，但这条规则同样适用：每个客户都应当说得出它能教会产品什么。然后再加上第 II 部分的筛子。一个不接受“交付开始之前”里那些条款（一个由发起人负责的 KPI、第 5 天前拿到数据权限、一个结束日期、一个价格）的客户，不管看起来多有战略意义，都不太可能走到生产环境。所以人员安排的问题有两半：

• 我们能学到什么？说出那个产品假设，或者你期望复用的模式。“这是个大牌客户”是销售的理由，不是答案。
• 它能落地吗？检查“当交付失败时”里的五个条件是否具备，或者每一个都有一位具名的人承诺在某个日期前提供。在派人之前问这个问题，而不是到第八个月才问。

两项都不合格的客户，得到的是自助产品、一家合作伙伴，或者一句客气的拒绝。能落地却什么都教不会的客户，就是服务工作。卖它也许是一个合理的商业决定，但要公开地做；悄悄派一位 FDE 过去，意味着没有人做过决定。

团队形态与负载

少数公开过的团队形态在一点上是一致的：在大客户上，由第二个角色承担战略、关系或后勤，好让工程师专心构建。

• Salesforce 说，它的一些 FDE“开始以小组形式工作，一个小组由一名部署策略师和两名 FDE 组成”。小组“全职专注于一个客户，大约三个月”，而“许多人是单独与一个客户合作的”（Salesforce，2025 年 11 月；T4，公司描述自己）。
• Glean 让它的创始 FDE“与前线部署产品经理同在一个小组”（Glean，Founding Forward Deployed Engineer；T4）。
• Anthropic 让团队与交付经理搭档（17.2 节；T4）。
• Cresta 的 FDE 负责人在接受中文科技媒体硅谷101采访时，描述了 FDE 与前线部署产品经理搭档的做法：后者负责智能体的行为和能力水平，同时处理需求、风险升级和增购（硅谷101，经腾讯新闻，2026 年 6 月；T4，一次采访）。

设计上的要点，就是“FDE 是什么，不是什么”里关于归属的那一点。搭档角色可以接过后勤、日程和大部分高管关系，但不能接过阈值或“暂不做”清单，否则 FDE 就成了一个按别人定的范围干活的构建者。设计小组时，写下由谁来商定阈值；如果只由策略师一个人定，这个角色就已经变了。

关于负载，证据只有一句话：Cresta 的负责人说，每位 FDE 目前承担“两到三个项目”，随着工具进步，将来可能提高到五六个（同一采访；T4，单个团队的估计和一个预测）。谁声称有更好的数字，都不要轻信；何况客户数本来就是错误的单位。一个处在评测爬坡中的客户会占满一位 FDE；一个交接之后进入稳定状态的客户，每周只需要一小时。本书提出的工作法则是数阶段，不数客户：

• 重：需求挖掘、划定范围、数据接入、评测爬坡、构建。每位 FDE 同一时间最多一个。
• 中：分阶段上线、交接演练、撰写产品反馈简报。
• 轻：交接之后的支持，以及和一位已经有阈值负责人的发起人一起为扩展划定范围。

按这条法则，每位 FDE 可以承担一个重阶段，外加一两个中或轻阶段，恰好与 Cresta 的数字吻合；把这种吻合当作微弱的支持，因为没有人知道他的项目处在哪些阶段。这条法则未经检验。它的逻辑来自第 II 部分：重阶段正是四个承诺被谈定的地方，一位同时扛着两个重阶段的 FDE，会在排在后面的那场会议上放弃其中一个。它最有用的地方，是能暴露隐藏的负载。一个“纸面上很重，实际上闲着”的客户，是一次停滞的交付，它应当在评审里作为一个信号出现，而不是作为空余产能。

招聘与入职

按行为招人，而不是按技能清单。“技能地图”论证过，招聘启事对技术和客户两个领域的行为筛得很好，对产品和判断两个领域几乎不筛，而能纠正这一点的人正是管理者。实际做法是，追问简历显示不出来的那两个领域：“讲一个你商定了却没达到的阈值。之后那一周你做了什么？”以及“你上一次交付改变了产品里的什么，是谁拍板的？”“拿到录用”从候选人的角度讲面试流程。

Salesforce 从三个内部团队组建了它的队伍，“工程、专业服务和客户成功”，并说“Salesforce 大约 40% 到 50% 的 FDE 流动来自内部”（Salesforce Newsroom，见上文；T2，自报）。Cresta 的负责人在资历上走的是另一条路：他不招初级 FDE（“我这边是不招任何初级的FDE”），因为一个项目通常只有一两个人，初级工程师很难赢得客户 CTO 的信任。他希望新人在“两到三个礼拜”之内就进项目，而不是先培训两三个月（硅谷101，见上文；T4）。他的理由给了你检验自己团队的办法：如果一次交付会让某个人独自面对客户的高层，就按这个标准招人，或者给这次交付配好人，让谁都不必独自面对。Salesforce 的入职培训为期六周，两周培训，四周在岗（Salesforce Newsroom；T2）。两者都没有证明自己的做法更好；放在一起，它们框出了一个选择的两端：培训熟悉你产品的人，还是招熟悉这个领域的人。

怀疑者最有力的证据，是一次招聘失败。Orosz 报道中那位称这份工作是“典型的 IT 外包思维”、“4 周后就辞职了”的工程师，在“FDE 是什么，不是什么”里讲过；对管理者要紧的细节是，公司想让这个人“更多地做交付负责人那一侧的事”（Pragmatic Engineer，2026 年 3 月；T4，Orosz 交谈过的两位工程师中被引用的一位）。从管理者这边读，候选人被推销的是一份工作，拿到的是另一份。补救的成本很低。给每一位进入最后一轮的候选人看一份填好的每周评审（17.7 节），隐去名字。它会显示负载、有没有人写简报，以及由谁商定阈值。读完就走的候选人，本来也会在第四周辞职。

衡量这套论点所衡量的东西

服务型企业衡量利用率，因为它们卖的就是工时，而 FDE 团队从为它们出钱的那一方继承了这个习惯。从结构上说，它就是错误的指标。把 FDE 和外包承包商区分开来的那些行为，全都会拉低它：

• 从一个无法落地的范围里撤出；
• 拒绝一个什么都教不会的客户；
• 为一份产品反馈简报留出几天时间；
• 交接得彻底到客户不再打电话来。

拉高它的行为，则是留下来当运营方、对每一次延长交付都点头、为第三个客户再重建一遍同样的流水线。按利用率给团队发钱，你买到的就是“技能地图”描述的那种向服务的塌缩。

力推这种模式的投资者，对销售配额也有类似的看法。a16z 写道：“很少能找到愿意背销售配额的实施负责人，而且这也可能导致适得其反的行为”（a16z，“Trading Margin for Moat”，2025 年 6 月；T4，观点）。OpenAI 的启事点出了它的三项衡量：交付、信号和持久性。下面是一个可以计数的版本，根据第 II 部分整理而来。它是本书的提议，不是经过验证的计分卡：

有两条规则让它保持诚实。“及早叫停”必须算作成功；如果停止一次交付只会显示为丢了一个客户，团队就不再宣告失败，组合里就会塞满停滞的工作。还有，绝不要把这六项加成一个数字：一支团队可能跨过了每一个阈值，却什么都没教会产品，而平均数会把这一点藏起来。

新晋升的管理者应当在第一个月内，和自己的上级把三个问题书面定下来，免得第一次季度评审替你默认定下：

• 由谁决定哪些客户能得到 FDE？如果答案是“销售定，你来配人”，那么 17.3 节里的选择就不归你，组合会慢慢滑走。
• 团队按什么来衡量？让上级同意这六项衡量，或者你自己的版本，包括及早叫停算作成功。
• 谁接收产品反馈简报，最晚什么时候做决定？没有具名接收人的简报，只是一份没人读的现场日志。

模板：每周客户评审

Anthropic 的启事把“交付评审”列为管理者的固定节奏之一，此外再没多说。下面是一种设计。它把每个客户那些承重的承诺放在一页纸上，显示出任何一位 FDE 单独看不到的东西：两次交付撞上同一个产品缺口，一位 FDE 扛着两个重阶段，一个销售承诺即将吃掉下个月的产能。每周做一次，每个客户五分钟；超过五分钟的，就变成一个有负责人的决定。

WEEKLY ACCOUNT REVIEW                        week of: ____________
Manager: _______________   FDEs: ____   Live accounts: ____

Rules: five minutes per account. Any commitment not OK gets a
name and a date. Two signals inside four weeks: schedule the
post-mortem this week. Count phases, not accounts.

ACCOUNT: _________________   phase: _____________________________
  Threshold     written? Y/N   owner: __________   status: ______
  Commitments   threshold __  data path __  sponsor __  exit __
                (OK / AT RISK / GONE; for each not OK:
                 restorer ____________  by ________)
  Signals, 4wk  _________________________________________________
  FDE load      FDE: _________   phase weight: heavy/medium/light
                other phases this FDE carries: _________________
  Product loop  field log? Y/N   brief: _________  reuse: _______
  Decision      continue / reset / post-mortem / walk / staff
                owner: ____________   by: ________

(repeat the block for each account)

PORTFOLIO
  FDEs with more than one heavy phase: __________________________
  Requests waiting for an FDE: ___________________________________
    learn: product hypothesis / research / reuse / none
    land:  KPI owner / data by day 5 / end date / price  Y/N each
  Signal to product this week: ___________________________________
  Decisions to take upward: ______________________________________

那一周的这页纸，填好之后是这样，所有数字都是区间：

WEEKLY ACCOUNT REVIEW                       week of: month 8, wk 2
Manager: the lead (part-time)   FDEs: 2   Live accounts: 2 (+1 req)

Rules: five minutes per account. Any commitment not OK gets a
name and a date. Two signals inside four weeks: schedule the
post-mortem this week. Count phases, not accounts.

ACCOUNT: the insurer, auto    phase: post-handoff (since month 5)
  Threshold     written? Y   owner: claims dir.   status: met
  Commitments   threshold OK  data path OK  sponsor OK  exit OK
  Signals, 4wk  none; overrides still improving suggestions
  FDE load      FDE: FDE 1     phase weight: light
  Product loop  field log? Y   brief: month 5, decided (build)
  Decision      continue      owner: insurer ops   by: n/a

ACCOUNT: the insurer, property   phase: expansion scope (month 6)
  Threshold     written? N   owner: head of property, unnamed
  Commitments   threshold GONE  data path OK  sponsor GONE  exit OK
                (restorer: COO, threshold owner + labelled set
                 within a few weeks, or walk)
  Signals, 4wk  steering moved twice, then skipped; "let's see
                what it can do first"; labelling a fraction done
  FDE load      FDE: FDE 1     phase weight: heavy on paper, idle
  Product loop  property docs logged; no brief yet
  Decision      post-mortem   owner: the lead   by: next invoice

ACCOUNT: second insurer   phase: pilot, eval climb (months 6-8)
  Threshold     written? Y   owner: their claims lead   status:
                below threshold; re-measure date agreed
  Commitments   threshold OK  data path OK  sponsor OK  exit OK
  Signals, 4wk  none
  FDE load      FDE: FDE 2     phase weight: heavy
                other phases this FDE carries: none
  Product loop  started from template; a fifth to a third reused;
                mixed-packet failures recurring here too
  Decision      continue      owner: FDE 2   by: re-measure date

PORTFOLIO
  FDEs with more than one heavy phase: none (FDE 1's is idle)
  Requests waiting for an FDE: new account, AE promised a free,
    open-ended PoC on document search
    learn: none (search is in the product already)
    land:  KPI owner N / data by day 5 N / end date N / price N
  Signal to product this week: mixed packets seen at 2 insurers;
    second column for the month-5 brief
  Decisions to take upward: no FDE for the new account; offer
    30-day paid pilot or self-serve. If property stops, FDE 1 to
    the template work for 2-3 weeks, then next engagement.

决定落在三行上。“heavy on paper, idle”（纸面上很重，实际闲着）把一个停滞的客户从空余产能变成了一个信号。“learn: none”和四个“N”，让拒绝的标准成了客户经理也能看懂的东西，而不是负责人的个人偏好。混合文档包出现在两个客户下面，这是两位 FDE 各自都看不到的：正如“反哺产品”所论证的，这就是那个把一项发现变成产品决定的第二个客户。

管理者的失败信号

这些信号分散在整个组合里，所以只有管理者看得到。

还有一个从内部很难看出来：最好的 FDE 总是待在最黏人的客户那里。一个从不放走强工程师的客户，已经把供应商变成了它的运营方。在一个计划好的日期把这位 FDE 轮换出来；如果客户扛不住，那么交接从来就没有发生过。