Palantir的CTO有句名言：「FDE的工作是吸收痛苦,然后排泄出产品。」
如果你还在按照「需求-设计-开发-交付」的流程做软件,你可能正在用工业时代的方式做信息时代的产品。真正的颠覆发生在:先到现场把问题解决了,再反推出产品该长什么样。
Ash Krishnaswami,Palantir首席架构师,做了13年Forward Deployed Engineer(FDE)。
2012年,他从生物医学工程转行进入硅谷。那年是Groupon、Uber的黄金时代,消费互联网公司四处招人。但Ash在做的事情——脑机接口的神经信号处理、混乱数据的清洗——几乎没人感兴趣。
只有Palantir例外。
「Palantir基本是唯一对我这种怪异数据处理经验感兴趣的公司,」Ash说,「里面是一群非常奇怪但非常有趣的人,背景包括物理、反恐、计算机科学,都专注于当时的国防任务,但眼光放在全球健康、金融等更广的领域。」
他停了一下。
「公式很简单:有趣的人+雄心勃勃的问题+雄心勃勃的技术。这个公式到现在都没变。」
现在,所有人都在谈论FDE。
从OpenAI到机器人公司到国防科技公司,「每家我遇到的公司都在拼命寻找和招聘这个Palantir发明的神秘角色,」Aaron Price(a16z合伙人,访谈主持人)说。
但很少人真正理解它是什么。
Ash笑了:「很有意思,因为它曾经是最丑的丑小鸭。人们说『你们只是把服务重新包装了』,『你们就是在给政府打工』,『你们到底在干嘛』。但后来大家承认,它确实产出了形状非常不同的软件或硬件。」
他给出的定义是:「你是在通过反向传播来构建产品。」
这是什么意思？
「这是一种基于信念的产品开发方式,」Ash说,「你说:没有现成的产品。所以你要激进地围绕结果来设计——无论是找路边炸弹还是帮助石油工程师——你问自己『我们必须构建什么才能实现这个特定结果』,然后从那里倒推,并能够泛化。」
关键差异是:它是传统软件公司结构的倒置。
传统模式:硅谷的核心团队是「高级祭司」,构建产品;现场的解决方案工程师或销售人员有一定自主权,但本质上是「读Confluence页面,然后照着实施」。
FDE模式:你必须在现场搞清楚什么有效,因为我们没有现成解决方案,然后再搞清楚怎么泛化它。这是一个持续的辩证过程:「如何让它在这个特定场景下工作」和「如何泛化它」,像波浪一样来回推进,每一次循环都是摩擦和调和。
「我觉得这基本上是倒着归纳式地构建东西,但眼睛盯着分类效用。」
Aaron说:「我记得我加入Palantir时,你不能直接加入开发团队。」
「对,」Ash说,「你必须在现场轮岗至少6到12个月,才能进产品团队。这很独特。」
「所有产品负责人,包括你后来在产品团队工作的人,都当过FDE。如果你没有在现场留下战斗伤疤,你根本没有资格做核心产品。」
Aaron笑:「那确实有战斗伤疤。」
FDE和解决方案架构师、现场PM有什么区别？
Ash说有几个关键不同。
第一,激励结构。
很多类似角色是按小时计费的,或者严格绑定合同交付物。但FDE是给你一个声明式的任务范围——比如「你需要搞清楚如何改进油井审查流程」或「帮助A350飞机产能爬坡」——至于怎么填细节,我们不会告诉你,而且我们会把合同结构设计成让你可以让客户达成那个结果,按需填补空白。
第二,你被赋权去做什么。
「你的工作定义是为了创收,还是为了推进产品？」Ash说。
Palantir的CTO Shyam有个笑话:「FDE的工作是吸收痛苦,然后排泄出产品。」
Aaron说:「我在邮件里读到过这句话很多次。」
「有时这感觉荒谬和不可能,因为你想『我必须让这个客户或这个结果成功,但真正的元目标是搞清楚如何让产品以更好的方式工作,为了下一次』。所以是那种分层的雄心,跟『我只是在某个账户上干活』完全不同。」
什么样的人能做好FDE？
「老实说,我不确定你能不能在把人放到现场之前真正知道,」Ash说,「这需要一点认识论上的谦卑。」
但他总结了几点。
第一,你能不能在蜂巢思维下工作。
「FDE团队像蜂巢思维一样运作。你能不能接受相当松散的声明式指令,然后去搞清楚如何在特定场景成功,如何建设性地、有时尖锐地反驳现有产品,跟核心开发团队对抗？」
「这结合了硬技术技能——你能做那些工作,而且经常是非常琐碎的工作,比如连接这些数据系统、迭代应用、被IT部门吼——能不能反复做这些事情？」
Aaron插话:「老实说,你忍受被客户吼好几个小时的能力是真实存在的……」
「这是个大点,」Ash说,「痛苦容忍度是个大点。痛苦就是护城河。」
第二,你能不能把痛苦转化成更高阶的东西。
「我觉得痛苦会把你带到低级自我,但关键是:它能不能转化成想要让东西变得更好？」
Ash说他这13年里,很多人纸面上应该能成为优秀的FDE,也确实会是优秀的FDE,但「你真的不知道,直到你看到他们在现场表现。有些人会让你惊讶,因为他们的投入程度是你从简历数据看不出来的。」
有什么典型人格特征吗？
「有几个突出的,」Ash说。
「一种是某种有趣的跨功能人格。比如某人是物理学家,现在想做这个;某人是电气工程师,但现在想做这个。有某个理由让他们想在这个领域工作,想做这些客户结果,而且他们对为什么要走这条路而不是常规路径有自己的看法。」
「所以有点像『我需要向自己、向世界证明,这个结果应该发生,而且我能做到』。有点肩膀上扛着芯片,有点thumos(古希腊哲学中的激情/斗志)。如果只是『哦,这挺好的,我去做,打个勾』,没有那种思想里的刺,我觉得很难每天出现去做那些你不得不做的事情,而不是陷进去。」
Aaron说:「我加入时,Palantir大量招聘的一种原型——我属于这一类——是研究生辍学者。」
「对。」
「我甚至都没读到研究生。」
Ash笑:「对,就是那些在某个技术领域很深,但受不了学术环境的节奏或其他东西的人。」
Aaron说:「我开玩笑说,我觉得我能进Palantir是因为跟联合创始人Stefan Cohen面试时,他问我为什么不读研,我觉得那个回答是转折点。我其他答案可能都一般般,但他听到『没去读研,有意思』。我记得我面试时还跟一个面试官吵起来了,我不点名是谁。我因为他对一个问题做了错误的基础假设跟他争论,离开时我想『完了,我永远不会被录用了,为什么我要跟那个人吵架』。」
「我觉得这太常见了,」Ash说,「早期的笑话是:我们现在有很棒的招聘团队,但早期都是工程师自己招人。笑话是『如果你的招聘体验不混乱,可能就不是真实的』。而且如果你面试时没有某个紧张时刻,觉得自己搞砸了,那可能就不是真的进去了的标志。」
如果你是创始人,该如何组织FDE团队？
「我觉得专注真的很重要,尤其在早期,」Ash说。
「很诱人的做法是有几个小分队,都聚焦略微不同的客户结果,试图通过这种反向传播FDE方法做某种复杂优化,但最后就是太难把东西整合在一起。」
「斯巴达式的专注在于:能够说FDE团队基本上是产品团队的延伸,他们几乎是一体的。」
他强调:「这不太关于forward deployed engineer这个人,而是关于forward deployed engineering这个动词。这是在说:我们承诺以这种方式构建产品。」
「这可能给了一定程度的专注,比如早期做Gotham时,就是『这是我们构建Gotham的方式』。有很多东西会让我们绊倒,必须修改和改变,但没有真正的硬界限。要构建产品,我们就必须以这种方式运作。」
「所以创始人可以问自己的一个问题是:这是构建这个产品的正确方法吗？它不总是正确方法,但我觉得对于很多非常具体的、技术性的、颗粒度的场景,forward deployed engineering是一种说法,表示『我们要真正地持续索引环境,在那里,对结果负责』,这有时意味着像你说的,开发人员实际上跟我们一起在现场,因为这是对模式的承诺,而不只是让人去做某件事。」
但这会不会让公司变成咨询公司？
「我觉得部分答案是:反复承诺荒谬的结果,」Ash说。
「你知道,我们上次财报上,Karp博士说『我们要大规模增长,同时保持员工人数基本持平』。所有人内部都想『我们怎么做到这个』,但这就是过去一切运作的方式——」
「宏大宣言,然后我们自己搞清楚怎么做。」
「对客户也一样,『我们要交付这个,这很史诗很大,但我还不太清楚怎么实现』。我觉得只要我们总是感觉自己在建设性地超出能力范围(over our skis),那种感觉就会强制要求严格执行、产品开发、招聘的纪律。」
「任何时候,如果我们感觉——希望这一天永远不会到来——你在松油门,感觉允许浪潮达到顶峰,那时你可能会看到事情改变。」
但产品成熟后呢？
Aaron问:「10年前,特别是Foundry(Palantir商业产品)这边,Foundry都不存在。我们必须在现场跟客户一起构建它,但现在有相当强的现有产品,客户也多得多。FDE模式怎么随着Palantir规模化而改变的？有哪些早期做法现在不灵了？」
Ash说有两种看法。
「一种是规范性的方式:随着你积累更多产品,有种借口或痛苦解脱,说『我不用再做那么多FDE了,因为我有可用的数据集成解决方案、本体构建器、应用构建器』。但这是一种退化结果,不会继续推进雄心的边界。」
「有个IT人员曾对我说『你们这帮人眼睛比胃大』。我希望我们永远如此。」
「重要的是向新人展示:这不意味着东西已经造好了,或者这是放纵的借口,而是:它给了你更多杠杆去构建。现在我们有开发者平台,有各种构建方式,以前要花大量时间做的事,现在他们能以相对较少的边际努力做到。」
「所以更像是:确保人们知道,任务跟以前一样,甚至更大,而你现在拥有的技术平台应该是你做到这一点的更多杠杆,而不是不去做的借口。」
两个字:进化。
Aaron问最后一个问题:「FDE部署的失败模式有哪些？有什么对策？」
Ash说:「一个是:整个组织真的是为支持forward deployed engineering模式而构建的,还是只是一个分支或重新包装的东西？如果是后者,你可能看不到预期的成果,或者可以理解地会遇到动荡。」
「另一个是:你知道,要让它工作,是很多不同类型人的协作。有做实施的人,但也有战略合作伙伴方的人——他们在Palantir不总是被喊出来——帮助关系管理,还有产品负责人要整合所有东西。所有这些人都必须是forward deployed流程的一部分。如果你没有那个共享团队,你可能有世界上最好的FDE,他们也无法真正接触到问题,或者得不到保护,无法建设性地打破一些规则来达成结果。」
Aaron说:「是的,上层掩护,无论是客户侧还是内部公司侧。」
「没错。这些东西你拥有时可能会忘记,但当你没有时就会非常清楚。」
这背后的理论,是产品哲学的根本性反转。
传统软件开发遵循「需求工程」范式:收集需求 → 设计架构 → 编码实现 → 测试部署。这假设你能在开始前就知道要构建什么。
但在复杂、模糊、快速变化的领域——国防、情报、能源、金融——你不可能提前知道。需求本身就是未知的。
FDE的本质是「涌现式设计」:先解决一个具体问题,再从解决方案中提取模式,再泛化成产品。这不是「用户说什么我就做什么」,而是「我去现场看用户到底在解决什么问题,然后构建一个能泛化到其他用户的解决方案」。
Ash说的「反向传播」是深度学习的比喻。在神经网络训练中,你先有输出(结果),然后反向计算每一层需要什么权重才能产生那个输出。FDE也一样:你先定义结果(找到路边炸弹、提升油井效率),然后反推产品需要什么功能。
这要求你的组织结构也反转。传统公司的权力在硅谷总部的产品团队;FDE公司的权力在现场,总部是支持系统。
但这有成本。
它需要极高的人才密度——不是每个工程师都能在混乱中找到秩序。它需要持续的整合工作——高自主权意味着碎片化。它需要创始人或高层持续做「本体论化」(ontologizing)工作——把各地经验整合成统一视野。
Palantir的CEO Alex Karp花大量时间做这个。Ash说「你几乎像Karp博士在顶层,基本上花很多时间做这个——哪个组在做什么,怎么连接起来」。
这也是为什么不是所有公司都适合FDE。如果你的产品需求相对清晰、市场相对成熟,传统模式可能更高效。但如果你在解决前所未有的问题,在监管严密的行业,在快速变化的环境,FDE可能是唯一可行的路径。
Ash最后说:「一旦是FDE,永远是FDE。」
Aaron笑:「当然。」
屏幕上,Palantir的股价在上涨。2024年,公司市值突破1500亿美元,成为美国市值最高的软件公司之一。
那些当年质疑「你们只是服务公司」的人,现在在学习Forward Deployed Engineering。