Forward Deployed Engineer(前线部署工程师)的崛起与正确做法

前方程式(FDE)是人工智能领域最热门的职位。实验室、初创公司和私募股权公司都在招聘工程师坐在客户运营中,解决他们的问题.几乎没有人能就这些工程师应该完成什么,或者招聘背后的策略到底是什么达成共识。
我是维努, 首席执行官开普勒,人工智能的确定性基础设施。十多年来,我在三个不同的机构三次构建了前沿部署功能的部分。以下是我看到的有效、失败的部分,以及我认为未来会走向何方。
第一个是Palantir。我在那里做产品开发,构建存储和检索系统,后来作为FDE被部署到商业、国防部和国家安全、医疗以及石油天然气领域。
我还领导了Project Frontline,这个轮岗将我们的软件工程师培养成前沿部署的工程师。大约有250人参加过这个项目,其中很多人现在在OpenAI、Anthropic、xAI和Anduril等公司运营前置部署团队。
第二个是Citadel,我负责业务工程。我们的客户是投资组合经理,唯一重要的问题是我们构建的数据和软件产品是否帮助他们实现了alpha。
第三个是开普勒,其中前置部署功能位于产品内部,而非销售内部,在一个可能错误的答案比没有答案更糟糕的领域。
联邦发展局的误解
几个月前,A16Z 推出了前沿部署工程师奖学金我被提名为研究员之一,和一些我以前共事过的人一起。这是一个很棒的项目,我很享受很多交流。
上周我参加了在旧金山的第一次奖学金晚宴。
桌子周围聚集了Snowflake、Anthropic的FDE以及我之前读过的多家初创公司,随着晚上的进行,我逐渐明白了我们都用同样的两个词(前沿部署)来描述几乎没有共同点的工作。
在对话的某一环节,FDE是加入“第二轮电话”的销售工程师,在其他地方是能写Python的配额代表,而在几个座位之外,更像是带着笔记本电脑和工作说明书的顾问,负责交付产品无法完成的东西。
几天后,有人真诚地联系了我们的WhatsApp群组他们的FDE团队应该如何与已经在账户中的咨询公司分摊业务范围。这是一个合理的问题,但至少基于我自己对FDE构成的看法,这个问题却有些奇怪。
明确说,我不想给一个术语设门槛;而且意义变化比大多数词都快。但有趣的是,这个群体中的人们,也就是FDE的现任专家,正在描述根本上是不同的工作,有不同的报告渠道和不同的激励措施。
难怪任何关于FDE的YouTube视频评论里,一半都是“这不就是在重新定义咨询吗?”的版本。
所以在接下来的文章中,我将讲述Project Frontline的故事通过我自己参与犯的一个错误的狭隘视角,这个错误如何让我变成了FDE,以及最终是如何实现的通知了轮岗,使我们的软件工程师成为了FDE。
前线计划的历史
首先,先说点背景。从几乎一开始,Palantir 就被拆分为两个独立的功能。第一个,产品开发(PD),建造了平台。第二个是业务发展(BD)尽管名字如此,但该组织既包含了技术型业务开发人员(也称为FDE)和非工程型客户导向人员(我们称他们为嵌入式分析师或部署战略家)。
在绝大多数情况下,PD并未直接与客户互动;而BD在绝大多数情况下,也没有直接参与构建核心、通用的平台。PD倾向于通过与BD聊天或将成功现场内置的功能整合进核心产品来进行二手客户发现。
不过,这一切都不是一个过程。它建立在关系之上——比如哪个FDE恰好足够了解哪个PD工程师,从而获得这些信息。因此,现场的良好见解会进入平台(或被放弃),取决于现场是谁。
2013年,在我刚加入Palantir的时候我参与了一个名为Phoenix的交易商店。这家商店由我合作过的一些最优秀的工程师设计,设计非常简洁,明确符合客户的使用场景。
不过,这些使用场景是二手传述给我们的。我们了解并理解设计需求,重点关注商业中的保留期需求,并有巧妙的桶数据解决方案,能够存储滚动窗口的数据。
它在我们控制的每个环境中都完全按照规定表现。
然后我们把它部署到银行,然后真实的金融数据中存在我们测试数据从未出现的漏洞。一个空白时间戳会跳转到纪元,因此保留逻辑按时要求从1970年1月1日到现在的每个窗口都用十分钟的桶。
这相当于约230万个密钥空间,而Cassandra(后备技术)每个文件句柄大约需要五兆字节。服务器理所当然地出现了(内存不足),重新启动需要14TB的内存。
这意味着这个过程实际上一到就死了。
这里的根本原因并非缺乏用户调研,正如你可能猜到的那样。我们有规格说明书,了解使用场景,并且读过大量关于此类机构如何存储数据的资料。
我们从未做过的,就是站在大楼里,让系统对他们的生产数据进行测试。这意味着我们这边没有人拥有设计与日常现实之间的差距。我们对那家银行的所有了解都是二手传述的,而且是由那些善意的人转述的,对他们来说,错误的数据只是常态。
这就是我成为联邦飞行员的原因,这对实际发生的事情来说是宽容的描述。当Phoenix在Palantir的商业车队中陆续推出时,我发现自己飞过去修理我们发货的东西,这让我第一次见到了我们的实际用户。
这次用户是Palantir自己的FDE,这对我来说很幸运,因为他们能告诉我我已经会说的语言出了什么问题。我开始构建和扩展系统,以满足他们的需求。
这也是我是如何直观地学会了FDE的思维方式而不是理智上的。
这就是普通版本故事的结尾,讲述了要关注用户的教训。凤凰变成了一个更有趣的东西。它成为了一个平台,Palantir的FDE开始在网络安全、KYC、反洗钱以及许多没人预料到的使用场景上构建。
最终,我们(产品开发)不得不考虑如何扩展Phoenix平台以支持所有这些用例。
当时我没看到,但这个迭代循环就是整个理念。FDE解决客户问题,是为了获得洞察力,从而指导下一步的建设。该职位是产品团队的延伸。
现今的FDE
现实是,这些都不是你今天看到的绝大多数FDE的心态。该词已被挪用为“做某某与客户有关的事情的人”的含义。这就是为什么你会看到前沿部署的股票研究员或前沿部署销售工程师的职位。
这种“被”收购“背后的直觉是正确的,尽管头衔很傻,因为客户现在比五年前更重要,而且它们有特定原因更重要。
那些容易实现的目标已经消失。通过一款设计良好的产品,向一千家公司销售,本可解决的问题大多已被解决。剩下的就是那些坐在墙内的工作,工作流程混乱且无文档,几乎无法从外部代理。
这就是为什么大家突然都被“前置部署”了。你不能从证据开示电话推断出某家公司是如何结账的,现在,问题中抗拒推断的部分变成了剩下的部分。
这意味着圣杯悄然移动了。很长一段时间里,这一直是可重复的运动,同样的SaaS产品以同样的方式反复销售;如果你卖的是代币、字节或实体物品,这仍然是正确的目标。
对其他人来说,价值已经转移到了定制化,甚至到了最后一公里,这也决定了工作流中任何产品都无法预见的20%,而这也决定了剩下的80%是否会被使用。
前沿部署已成为解决最后一公里问题的代名词。
但解决它只是这个职位职责的一半。你在某个客户处解决的最后一公里问题,就是告诉你平台哪个部分需要变得可通用的信号。一个能解决最后一公里问题而不把信号发回去的FDE职能,是拥有更好头衔的服务/咨询团队。
那么,今天的FDE应该做什么?
我认为你作为FDE的职责应该是收集名词和动词.我们来详细讲解一下。
在一家公司待一周,你会发现同一个概念通常至少有四个不同的名称。销售代表客户,运营代表客户,财务预订计费实体,工程部门写org_id作,而这些团队之间的每一个缝隙都隐藏着一种翻译,一旦有人改变定义就会破解。
这些名字只是表面,下面是运营模型。也就是说,你可以通过学习公司的名词和动词来代理他们的运作方式。
名词是企业中人们视为真实的词。通常是“某件事”。一个仓位,或者一笔交易,或者一个交易对手方。通常,按每个团队计算,整个操作会启动少数几个对象,并且它们的定义都不像教科书那样。
那是因为两家公司在幻灯片上描述职位的方式完全相同,代码中却完全不同。这不是漏洞,这正是公司独特之处。我的意思是,如果每家公司都有完全相同的名词集合,那你真的只需要一家公司。
动词是名词的移动方式。比如交易如何被预订,或者在结账前必须成立的事,晚上十一点谁签字批准例外,以及当那个人休假时会发生什么。
几乎没有这些被写下来——而是亲身经历的。它是组织赖以生存的运作体系。它是文化。它活在那六个已经足够久、不再注意它的人脑海中,也存在着一个四年前某个人建立的电子表格里,整个团队现在默默依赖它。
这就是为什么它如此珍贵,也正是你无法开口要求它的原因。
通常,掌握这些知识的人并不知道自己拥有它。在我最近的初创公司之一,我们花了将近一年时间试图将客户从CSV迁移到Parquet,但每次都有一位数据质量工程师阻挠。
我们永远无法理解原因,原因总是在变化但总是会有“镶花更糟”、“它行不通”、“我觉得不合理”等等的变体。我们用了客户存储减少论证、计算最小化论证、流水线优化论证......但这些都没能打动她,因为这些都不是针对实际问题。
然后我们请了一位FDE进去观察这位特定的数据质量工程师的工作。她正在从S3拉取CSV到Windows笔记本上,双击打开,然后凭目测数据行。
这就是数据质量检查。当时Parquet没有原生查看器,所以我们提出的方案会剥夺她唯一的数据质量工具,什么都不还给她。她并不是在为难,她只是保护着那个让她能完成工作的唯一东西。
那天晚上我们搭建了一个Parquet显示器,她两天后批准了迁移,管道执行时间从大约17小时缩短到2小时。她绝不会在采访中说这些。从她坐的位置看,原因显而易见,无需多言。
理解并定义了这位分析师的操作系统,也就是名词和动词,使我们不仅理解了问题本身,还构建一个解决方案,然后我们可以在一个有相同问题的客户车队中提供。
输出必须是产品
理解名词和动词有助于理解问题,但输出必须是产品,而不仅仅是一个满意的客户。
名词和动词告诉你问题到底是什么。它们不会告诉你该怎么做;而且这就是大多数FDE函数默默出错的地方因为解决眼前的问题令人满意且清晰,而且那周一定会有人感谢你。
让客户满意是一项真正的工作,而且是一项好工作。这属于解决方案架构师,他们正当地被衡量。前线部署的工程师负责将该领域所学转化为未来客户都能获得的东西。
一个FDE的合作如果最终只收到一个满意的账户,上游没有任何变化,那就是在该职位存在的唯一目的上失败了。你得到了上下文,并且花在了本地。
我花了不少钱才学到这个。有一次客户需要数据保留工作,我就编了一个很酷的脚本叫“vinoo.groovy”来支撑他们——一个本来就没打算撑过一周的工作下午。
一年后,它遇到了一个近十万客户,名字还和我合并了。这故事荒谬到我的团队开始叫我vinoo.groovy。我们修复了问题,但从未将其转化为产品——所以我们花了多年时间维护一个本该立刻消失的黑客。
你发布的每一条捷径都成了你拥有的东西。纪律在于知道哪些修复应该放在平台上,哪些是你在完成任务后故意丢弃的。
分叉
这就是整个问题的分裂点。做工作时底下什么都没有,你会学到一家公司的模式,交付完全符合它的产品,但一旦合作结束,所有东西都丢失了。
下一个客户从零开始,再下一个客户也是如此。这就是咨询。薪水不错,员工很棒,而且不会叠加。
在同样的工作基础上放一个平台,每家公司都能让下一次部署更快,产品更精准,因为工程师带回家的东西有地方可以住。这就是卖工时和建立资产的区别我对这场淘金热的真实理解是,大多数公司都在建造第一个,并向董事会介绍第二个。
这就是你的工作:构建平台。
我们在开普勒所做的事情以及你可以从中获得什么。
在开普勒,我们从第一天起就这样设置了这个功能,甚至在客户支持之前就已经如此。另一种情况是,在第十四个月发现你的工程师一直在为错误的方向优化。
从一开始,我们的FDE就作为产品团队的延伸;这就是所有其他一切的结构性决定。
我们向对冲基金、投资银行、私募股权公司及其他金融机构销售。这些机构本质上不同,使命不同,但它们共享一个不可妥协的原则:数字必须正确,且有人能够证明它们为何正确。
这就是我们设计时所面临的限制,而且它很有用,因为它迫使操作模型变得开放。我们合作的任何公司都无法在没有清晰来源的数字后产出作品。
这个不变性定义了我们的平台,也为我们提供了执行的基石。
这些问题是普遍存在的。词汇却不是。
这些公司都在运行某种版本的同一本体论,且每个公司对其描述都不同。在同一银行,一个头寸在信用台上是同一个,在股票台上则是相邻的。
两个基金在回报计算时会用完全相同的语言,并且对分母的成分存在分歧。这些差异大多是因为某人在(比如说)2011年做出了一个合理的决定,并且这个决定比那个人还长;而且,你能找到的任何地方都没有明确记录。
识别并填补这一空白是FDE的工作。模式告诉你存储了什么。它不告诉你真正含义,而两者之间的距离恰恰是系统听起来正确的数字,结果却是错误的。
来源是我们客户的正确性要求但对我们来说,它还起到了其他作用:这让实地工作变得复杂。一个能在糟糕编码中即兴发挥的系统永远不会告诉你编码本身就是错误的。
我们的系统不会即兴发挥。当我们误解公司如何定义某事时,这种误解会显现为失败,而不仅仅是看似合理的答案。错的工程师是从系统中得知的,而不是六周后在客户会议中得知。
部署随后告诉我们平台中需要扩展什么,这其实是一个比听起来更狭窄的问题。我们并不是想了解某个基金想要具备哪些功能。我们试图找到平台太窄,无法容纳我们不断遇到的物体的地方。
三家公司要求相同的功能很容易被注意到,而且价值相对较低。三家公司需要来源层无法表达的东西,是我们真正关心的信号;而且通常会悄然出现,表现为工程师第三次绕过同一限制。
如果你在别的地方建造,以下是我会从中总结的部分。
产品杠杆是你获得尝试权利的关键。平台中每一项功能都让下一次部署更便宜,而小公司快速学习任何东西的方式,正是廉价尝试。没有这种筹码,每个客户只能有一次昂贵的猜测。
你仔细观察,构建数月,如果猜错了,就得花一个账户和四分之一时间去验证。我们宁愿一个月错四次,因为每次尝试的成本都低于前一次。
这就是为什么举报热线不是行政细节。把职能指向销售,激励就变成了关闭你面前的账户——这是一项真正的工作,公司里应该有人去做。
但这不是这个。将函数指向产品,每次部署都会被要求生成下一次部署可以从中开始的东西。
护城河所在
所以这就是我会在这个时代设置护城河的地方。不是模型的问题而且你无论如何都是从别人那里租的,租金会逐月变便宜。也不是天赋的问题因为每个实验室都在竞标同样的几百人,而这个价格已经被发现了。
I它也不是任何一个客户的地图。几年前也是如此,现在也是如此,因为提取几乎免费,任何人都能在下午内起草公司运作方式。
选秀不是资产。知道选秀哪部分错了才是资产,这仅仅是因为被纠正了。
所以,对我们来说,护城河是对垂直领域企业实际运作方式的积累、当前且经过验证的理解,被保存在一个保持其最新性并能够证明其价值的平台上。
这些词都是负重的。累积,因为一次部署是一个轶事,第十个字母是一个模式.当前,因为操作漂移,陈旧模型在AI系统下默默失败,而这在分析师面前从未发生过。
验证,因为合理的编码和正确的编码看起来完全相同直到某样东西坏了坚持来源的意义就是你知道你拥有的是哪一辆。
那是买不到的。竞争对手可以雇佣你的工程师,复制你的界面,然后阅读这篇文章(我们的公司会尽量做到这三者!)。他们无法简化的,是客户内部犯错、被纠正、再把纠正融入平台的顺序,并且在到达下一个公司时,已经知道哪些问题是承重的。
每进行一次这样的循环,下一个周期都会更便宜,且复利就是你拥有的东西。
我看过这个函数被构建了三次,每次都保持了这个模式。重要的工程师不是那些为客户出货最多的人,而是那些回来修改我们构建内容的工程师。
雇佣前置部署工程师只能让你获得一件事,那就是有权识别哪些问题值得解决。大多数公司从未走到那一步。但关键是报名费,不是奖品。
我是开普勒公司的CEO Vinoo Ganesh,我们正在构建这篇文章的核心层面,那就是让AI产品能够追溯所有数字源的真实信息。在开普勒之前,我在Palantir领导Spark,创建了Project Frontline,后来在Citadel负责业务工程。
如果你在这里构建,或者觉得我理解错了,你可以和我争辩在LinkedIn上.