# 在 Deepgram，一名 FDE 只服务一个客户

> 战略客户岗位要求第 60 天前有东西上线生产环境，有些阶段八成时间要在客户现场。

原文: https://fdetimes.net/zh/analysis/deepgram-fde-one-strategic-customer/

Deepgram 招聘战略客户前线部署工程师（FDE）的启事里，有一句话说得非常直白：派驻期间，小组负责的客户就是你唯一的工作，不把时间分给其他客户或团队。每名工程师一次只对接一个战略客户。

这听上去像是一种优待：有专注的空间，很少需要切换上下文。但继续读下去，看完驻场时间、第 60 天和第 90 天的里程碑以及生产责任这几部分，就会发现这份专注是有明确代价的。

如果你是 FDE，或者想成为 FDE，Deepgram 这份启事值得细读，因为它相当准确地描述了一类 FDE：深度嵌入客户，有团队支撑，考核标准是客户系统里实际在跑的东西。

## 专注落在个人层面，而不是团队层面

小组（pod）模式并非 Deepgram 首创。Perspective 关于 FDE 职能的实践手册把一个小组描述为一名 FDE 加一名产品经理和一名数据或平台工程师，共同负责一个战略客户。

同一份手册也指出，在团队层面，FDE 职能仍然可以同时推进多个项目。所以绝对的专注落在个人身上：公司有很多客户，每名工程师却只有一个。

从这个结构推下去，结果是 FDE 几乎没有藏身之处。手上有十个客户时，一个进展缓慢的集成项目可能淹没在其他项目里。只有一个客户、时间又不分摊时，一次生产事故很容易追溯到坐在那里的工程师身上。

**要点:** 只服务一个客户时，一次生产事故很容易就落到你的名下。

## 从每月一次到最高 80%

战略客户岗位的启事给出了基本的驻场节奏：每月至少去客户现场一到两次。但在项目的高峰阶段，驻场时间可达 80%。

按每周五个工作日算，80% 意味着四天待在客户办公室，只剩一天用来和小组同步、阅读内部文档，以及做需要不被打断、集中精力的工作。

相比之下，每月一到两次只是大约二十个工作日中的几天。同一个岗位，不同阶段的生活节奏可能完全不同。

和高级岗位的启事对比，差距更加明显。Enterprise 团队的高级 FDE 启事只提到偶尔出差拜访客户、支持销售交易和参加关键的现场工作会议。卡尔加里（Calgary）的高级 FDE 战略客户岗位启事同样只写了偶尔出差拜访客户。

一边是最高 80% 的时间待在客户那里，一边是偶尔出差。差距可能来自资历，可能来自各份启事描述的项目阶段不同，也可能只是启事写法不同，因为启事里并没有解释。

公司为什么希望工程师花这么多时间待在客户那里？CRV 在对 FDE 岗位的分析中认为，到现场才能让隐藏的约束浮出水面。如果你要申请，不要去猜，直接问清楚平时和高峰期的驻场比例各是多少。

## 第 60 天上线，第 90 天全面负责

启事里的里程碑按天计算，而不是按驻场周数计算。到第 60 天，工程师必须已经上线到生产环境。到第 90 天，要求是端到端地全面负责自己的工作。

这里的“负责”有具体含义。4dayweek.io 上的这份启事写道，你要监控、调试和优化自己上线到生产环境的东西。工作并不在代码合并时结束。

设想一个假想场景：客户是一家大型呼叫中心，想在话务处理管道中加入语音转文字。到第 60 天，语音转文字管道必须在真实通话上跑起来。

从那时到第 90 天，高峰时段延迟上升，或者某一批通话识别出错，第一个要去翻日志的人就是你。

正是在这里，一次只对接一个客户的模式让责任变得更重。没有第二个客户来分走你的注意力，所以你为这个客户上线的东西几乎就是你接受考核的全部。CRV 准确地概括了这一点：FDE 把代码直接上线到客户的线上环境，再把经验反馈到核心产品中。

Perspective 的手册还补充了交付之后的情况：FDE 继续陪在客户身边，仍然留在客户的 Slack 里，此时要对一个真实运行的系统负责。上线到生产环境不是项目的终点，而是最难的部分的开始。

## 新人有安全网，高级工程师就是安全网

战略客户岗位的启事并没有让新人单打独斗。这个岗位以 Applied Engineer 的头衔招聘，处在从 Associate 到 Principal 的同一条职级体系上，而且工作在上线前会由一名高级 FDE 审查。

高级岗位的启事则把这个角色反了过来。卡尔加里的启事让高级工程师全面负责实施，处理线上部署的问题，并在需要时作为复杂技术事故的升级处理节点。Enterprise 的启事明确写道，你的影响力将超出任何单一客户。

把三份启事放进一张表，一条发展路径就显现出来：

| 方面 | FDE，战略客户 | 高级 FDE，战略客户（卡尔加里） | 高级 FDE，Enterprise |
|---|---|---|---|
| 客户对接 | 一次一个战略客户，不分摊时间 | 全面负责客户的实施 | 影响力超出任何单一客户 |
| 驻场时间 | 每月一到两次，高峰期最高 80% | 偶尔出差拜访客户 | 偶尔出差，参加关键现场会议 |
| 生产环境 | 第 60 天上线，第 90 天全面负责 | 处理线上部署的问题 | 启事未说明 |
| 谁为谁兜底 | 上线前由高级 FDE 审查 | 担任升级处理节点 | 启事未说明 |

最合理的解读是：新人在前辈的审查下，把全部精力投入一个客户，以此学会这门手艺。到了高级阶段，工作转向为他人提供支撑，把积累的经验带给更多客户，驻场时间也更少。

对担心 FDE 工作是死胡同的人来说，Applied Engineer 职级体系这个细节是值得留意的信号。在客户那里做的工作计入从 Associate 到 Principal 的同一条职级体系，而不是被拆到一条单独的通道上。

## 讲上线之后的故事，而不只是演示

如果你瞄准的是 Deepgram 描述的这类 FDE 岗位，简历和面试需要证明一件事：你曾为一个真实运行的系统负责，而不只是把它做了出来。启事里第 90 天的里程碑考的正是这一点。

在简历上，“搭建了一个集成语音 API 的 POC”这样的条目，远不如写清楚系统服务了真实用户、你如何监控它、调试过哪次事故有说服力。面试中，最好的故事是你在生产环境里找到根因，并在用户还在等待时修复了问题。

轮到你提问时，就问 Deepgram 启事里写清楚的那些事：高峰期驻场多少时间，第 60 天必须交付什么，谁审查你的代码。如果回答含糊，说明专注的代价很可能要由你一个人承担。

一次只对接一个客户的模式，奖励的不是擅长做幻灯片或擅长协调的人。它奖励的是愿意在一个运行中的系统上署名的人，而这项能力，今天就可以在你手上已有的服务上开始练习。

**本周动手试试:**

- 按生产责任的思路重写一条简历条目：写你上线了什么、之后如何监控、调试过哪次事故，而不只是“做了一个原型”。
- 挑一个你负责的服务，问自己第 90 天的那个问题：如果它在凌晨 2 点出故障，你有没有足够的日志、仪表盘和理解，能自己把它修好？缺什么就补什么。
- 如果你在申请 FDE 岗位，准备好三个问题：平时和高峰期的驻场比例，第 60 天必须交付什么，以及上线前谁审查你的代码。

## 信源

- [Forward-Deployed Engineer (FDE), Strategic Accounts @ Deepgram | Purpose Job Board](https://www.purpose.jobs/discover/companies/deepgram/jobs/90869471-forward-deployed-engineer-fde-strategic-accounts)

- [Forward-Deployed Engineer (FDE), Strategic Accounts (Deepgram, 4dayweek.io)](https://4dayweek.io/job/forward-deployed-engineer-fde-strategic-accounts-at-deepgram-4aaf3da4)

- [Senior Forward Deployed Engineer, Enterprise - Deepgram | Built In Los Angeles](https://www.builtinla.com/job/senior-forward-deployed-engineer-enterprise/10758019)

- [Senior Forward Deployed Engineer (FDE), Strategic Accounts - Deepgram | Built In Calgary](https://builtincalgary.org/job/senior-forward-deployed-engineer-strategic-accounts/10936834)

- [Forward Deployed Engineer Playbook](https://getperspective.ai/blog/the-forward-deployed-engineer-playbook-how-to-structure-run-and-scale-an-fde-function-in-2026)

- [Forward Deployed Engineer: When This Role Makes Sense](https://www.crv.com/content/forward-deployed-engineer)