Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE
频道: AI Engineer
视频: https://www.youtube.com/watch?v=KwhgfwOSToQ
原文语言: en
统计: 共 23 轮 · Kevin Bai 19 · 观众提问 3
[0:16] Kevin Bai
All right. Thank you so much, Basil, for the introduction. Hello there. Those of you in the audience, thank you so much for joining us today. My name is Kevin. Uh, technically we don't really have titles. So I am member of technical staff at Anthropic working on the applied AI team. Uh before this I joined Ripling to help build their FTE function. I was the first person to join that team and we grew it to uh around 25 in a year. Um and so that's pretty cool. And then before that did a bunch of stuff at Palunteer. But you know list of companies is not really that interesting right because we're talking about a function. And what I I hope you're all here for is to hear about forward deployed engineering. Um if you are here for for evals or if you're here for I don't know videos of kittens that's probably one room over. Uh I'm also not qualified to talk about those things. So I am trying to give a talk to you on for deployed engineering 101. So what I want to do is walk you through the history of the role, the nature of the function, why Palunteer chose to adopt FTE as its go to market motion and then right extend that to maybe how you could apply it to your own organizations and businesses. Um and if possible at the end would love to take any and all questions. All right, does that sound good?
好的，非常感谢 Basil 的介绍。大家好，在座的各位，非常感谢今天来听这场分享。我叫 Kevin。严格来说我们公司其实没有职级头衔，所以我就是 Anthropic 的 member of technical staff，在 applied AI 团队。在这之前我加入了 Rippling，帮他们把 FDE 这个职能从零搭起来——我是这个团队的第一个人，一年之内我们做到了大概 25 人的规模。这还挺酷的。再往前，我在 Palantir 做过一堆事情。不过说实话，罗列公司名单没什么意思，因为我们今天要聊的是一个「职能」。我希望大家来这儿，是为了听 forward deployed engineering（前置部署工程）这件事。如果你是冲着 evals 来的，或者你是冲着……我也不知道，小猫视频来的，那大概是隔壁那个房间。而且那些东西我也没资格讲。所以我今天想给大家讲的是「Forward Deployed Engineering 101」。我想带大家过一遍：这个角色的历史、这个职能的本质、Palantir 为什么选择把 FDE 当作自己的 go-to-market（进入市场）打法，然后再延伸一下——你可能怎么把它用到你自己的组织和业务里。如果时间允许，最后我很想回答大家任何问题。好，这个安排听起来行吗？
[1:36] Kevin Bai
Yeah. Okay, that's too low energy. Does that sound good?
嗯……行吧。这也太没精神了。我再问一遍：听起来行吗？
[1:40] Kevin Bai
There we go. Oh my god, it's a conference, not a funeral. Let's go. Um, so, okay, high level, right? What does Palunteer do? Palunteer is a technology company that creates a technology platform, uh, a software platform called Foundry. What Foundry does is Foundry enables organizations of arbitrary size to centralize all of their data in one place to create an ontology. What that means is to create proper nouns out of their data. So that instead of having, you know, table one, table two, table three, if you have warehouses, you have a single table that's the source of truth for warehouses. And then on top of that, Foundry enables companies to build applications. Okay. So if I was to explain that to some industry leader or other, they would be like, cool, you've made my data organized, but what does that do for my actual business? Right? And and so that's that's kind of where it falls short if you're just selling technology. Um and then the other piece that's kind of interesting, right, is that you as a app building platform Foundry, your success is determined by how well your customers can use your particular piece of software. And so there's also a huge tax, right? Not only are customers paying to invest in this platform, they are also needing to train up their people to get effective on it.
这就对了。天哪，这是个大会，不是葬礼，来点劲儿。好，那我们从最高层讲起：Palantir 到底是干什么的？Palantir 是一家科技公司，做了一个技术平台，一个叫 Foundry 的软件平台。Foundry 干的事情是：让任意规模的组织把自己所有的数据集中到一处，然后建立一套 ontology（本体）。什么意思呢？就是把数据变成「专有名词」。这样一来，你手里就不再是「表一、表二、表三」，而是——如果你有仓库这个概念，你就有一张表，它就是「仓库」这个东西的唯一事实来源。在这之上，Foundry 还让企业能够构建应用。好。但如果我这么去跟某个行业的高管解释，他大概会说：不错啊，你把我的数据整理干净了，可这对我的实际业务有什么用？对吧。这就是纯卖技术会露怯的地方。另外还有一个挺有意思的点：作为 Foundry 这样一个「搭应用的平台」，你的成败取决于客户到底能把你这套软件用得多好。所以这里还有一笔巨大的隐性税——客户不光要花钱买这个平台，还得再花钱把自己的人培训到能熟练使用它。
[3:00] Kevin Bai
And then and only then are they able to build things. That is a terrible way to do business. And we soon realized that instead of selling just services or just products, you sell both. Um, so it's one combined thing where the customer is neither buying a piece of software nor are they buying the time of someone. They are buying an outcome, right? You are sending over really smart people who will go and understand the nature of the customer's business. Build them a solution on top of this platform foundry and then the thing that you get in the end is that outcome because if you are a a leader of industry right if you're working in CPG you care about you know getting more placement on the shelves or you care about higher throughput of sales you don't really care how the data is organized and nor should you care right that's more of an implementation detail. So where does this notion come from?
然后，只有到了那一步，他们才终于能开始做东西。这种做生意的方式糟透了。我们很快意识到：与其只卖服务，或者只卖产品，不如两个一起卖。把它们捏成一个东西——客户买的既不是一套软件，也不是某个人的工时，他们买的是一个 outcome（结果）。你派过去的是一批非常聪明的人，他们会去真正搞懂客户业务的本质，在 Foundry 这个平台之上给客户搭出解决方案，而客户最后拿到的就是那个结果。因为如果你是一个行业里的领导者，比如你做的是 CPG（快消品），你关心的是能不能在货架上拿到更多陈列位，或者销售额的吞吐能不能更高——你根本不关心数据是怎么组织的，你也不该关心，那更像是实现细节。那么，这个说法到底是从哪儿来的？
[3:52] Kevin Bai
This ridiculous idea of like sending engineers to the forefront because I'm pretty sure of all the folks in the audience, you know, if you're familiar with software engineers, myself included, where we're some of the last people that should be customerf facing. And so I want to make this like really really clear. Okay, you can imagine this as a punit square. Um it has to do with what it is you're selling and then who it is that's buying from you. So if you sell a very technical platform or product, right, let's forget Foundry for a second. If you sell a GitHub or if you sell um a data dog, it is a incredibly complicated piece of software. However, your ICP, right, are going to be CTO, CIOS, and then your users are going to be software engineers. They're going to be people who can take and absorb this complexity and use it because it's part of their job. The other situation is you are selling something that's not that complicated. Um, and your buyer is not that technical, which is also fine, right? Say you have a tool, uh, something like a Rippling or something like a Jira or like a Slack, and those tools might be complicated, but they're configurable. They're not meant to be developed upon. And so, it's fine to be selling to a non-technical buyer.
「把工程师派到最前线」这个听起来很离谱的想法是怎么来的？因为我敢肯定，在座各位只要接触过软件工程师——包括我自己在内——都知道我们大概是最不该直接面对客户的一群人。所以我想把这件事讲得非常非常清楚。你可以把它想象成一个二乘二的矩阵（Punnett square），两个维度是：你卖的是什么东西，以及买你东西的是谁。第一种情况：你卖的是一个技术性非常强的平台或产品。我们先把 Foundry 放一边——比如你卖的是 GitHub，或者你卖的是 Datadog，这都是极其复杂的软件。但是你的 ICP（理想客户画像）是 CTO、CIO，你的用户是软件工程师。他们是有能力吸收这种复杂度并且真正把它用起来的人，因为这本来就是他们工作的一部分。另一种情况是：你卖的东西没那么复杂，而你的买家也不太懂技术——这也完全没问题。比如你有一个工具，像 Rippling，或者像 Jira、Slack，这些工具可能是有点复杂，但它们是「可配置」的，不是让你在上面做二次开发的。所以卖给一个不懂技术的买家，也没什么毛病。
[5:03] Kevin Bai
You only need FTE if you are in this weird unique situation of Palunteer where you are having to sell something very technical to a non-technical buyer. Now, historically, why was that the case? You know, like, didn't Palanteer like to do things easier than that? Well, it's because the nature of Foundry, right, which is an app building platform, makes it inherently not as interesting to the large tech companies. Uh, Google, Meta, what have you, these days, the labs, they all have great software engineers and they can build whatever apps the organization needs. Um, but when you're selling to say uh, you know, Fortune 500 client that works in oil and gas, they're not really going to have that kind of engineering depth, right? Their pipelines are not data pipelines. It's more going to be, you know, uh, fluorocarbons or something like that. So, for them to really get full value of your platform, you could either trust that they'll spend the time to, you know, not only buy your platform and use it, or you could just say, "Hey, here's the setup. We will loan you some really good engineers that you don't have to hire, recruit, manage or retain.
只有当你处在 Palantir 那种诡异又特殊的处境里——你必须把一个技术性极强的东西，卖给一个完全不懂技术的买家——你才需要 FDE。那么从历史上看，为什么会变成这样？你可能会问：Palantir 就不能找条更好走的路吗？原因在于 Foundry 的本质——它是一个「搭应用的平台」，而这天然让它对大型科技公司没那么有吸引力。Google、Meta 这些公司，包括现在的各家 AI 实验室，他们都有非常优秀的软件工程师，组织需要什么应用他们自己就能搭出来。但当你卖的对象是，比如一家做油气的世界 500 强客户，他们就不会有那种工程深度。他们说的「管道」不是数据管道，更可能是输送碳氟化合物之类的东西。所以，要让他们真正吃到你平台的全部价值，你要么就赌他们愿意花时间——不光买下你的平台，还得把它用起来；要么你就直接说：喂，方案我给你摆好了，我借给你一批非常优秀的工程师，你不用去招、不用去挖、不用管理、也不用操心怎么留住他们。
[6:06] Kevin Bai
They will be trained in not only how to use this platform, but they will also, you know, work really closely with you in the same way that if you were at a fine dining restaurant, right, the waiter is there to cater to your every need and they will figure out how to solve you the problem and then build you the software. And so that ended up being the way that Palunteer went to market with the Fortune 500 um with the global Fortune 500 and and how has that turned out, right? Because because there's no point in me just getting on stage saying, "Oh, this is so cool. You know, here's the details, blah, blah, blah." So, I'll give you some numbers. If you look at the public SAS companies in the Fortune 500 and you measure them by ACV, average contract value, so uh you know of any given customer, how much money is that customer spending with that particular vendor? Balance is first at 4 million uh last I checked. Next biggest is Service Now at 1.2. Next biggest I want to say is workday at 600K. And then there is not a single public SAS company that even cracks half a million ACV. So just by these numbers I would say it works pretty well. Um Palunteer is at some ridiculous valuation now uh and only at a few thousand headcount. Um so okay what is this FTE thing? What is this model? What does this mean? Um do we have any startups in the audience or anybody working early stage? Yeah. Okay.
这些人不仅受过训练、知道怎么用这个平台，而且会跟你贴身协作——就像你在一家高级餐厅里，服务员会照顾到你的每一个需求那样。他们会想办法帮你把问题解决掉，然后把软件给你搭出来。这最后就成了 Palantir 攻打世界 500 强、全球 500 强的 go-to-market 方式。那效果怎么样呢？毕竟我不能就这么站在台上说「这太酷了，细节如此这般，balabala」。所以给大家几个数字。你去看 Fortune 500 里那些上市的 SaaS 公司，按 ACV（average contract value，平均合同价值）来衡量——也就是任意一个客户，一年在这个供应商身上花多少钱——Palantir 排第一，上次我查是 400 万美元。第二是 ServiceNow，120 万。第三我印象里是 Workday，60 万。然后，再往下就没有任何一家上市 SaaS 公司的 ACV 能突破 50 万了。所以光看这几个数字，我会说这套打法效果相当不错。Palantir 现在的估值已经离谱到某个程度了，而团队规模也就几千人。好，那么 FDE 到底是个什么东西？这个模型是什么？它意味着什么？在座有创业公司的朋友吗？或者在早期阶段公司干活的？有。好的。
[7:25] Kevin Bai
Some hands. So I'm sure you're familiar with the concept of a design partnership. So in the early days of a startup when you don't know what your product is and your customers don't know what they're buying, you say, "Hey, let me work with you really closely. Let me figure out what it is you need. I will, you know, spend my time, my energy, my technology, my resources. You just give me the context on what your problem is and I'll build you a really good solution." That's generally how most startups at least in the B2B segment find product market fit. Um FDE is basically taking this concept of a design partnership and scaling it up into enterprise. Right? That was the core assertion of Palanteer was that who said who said that design partnerships were only for the beginning stages of a company. Why can you not just do that at scale at enterprise? Well, some of you in the audience who are very smart and observant might say, Kevin, you can't do that in the enterprise because you can't maintain it. If you build something custom for every single customer, you are going to be hurting a whole bunch of cats and you're going to have, you know, a a bunch of really shitty code and and no engineer is ever going to work for me because they can't maintain it and no one wants to learn 55 repos. And you would be totally right. If you were to implement an FTE function where each FTE is building entirely from scratch, my friends, you do not have an FTE function. You have a dev shop. Um, nothing wrong with that. Of course, those are really profitable businesses.
有几只手。那我相信大家对 design partnership（设计合作伙伴）这个概念不陌生。在一家创业公司的早期，你自己还不知道产品该是什么样，你的客户也不知道他们到底在买什么，于是你说：来，让我跟你贴身一起干，让我搞清楚你到底需要什么。我出时间、出精力、出技术、出资源，你只要把你问题的上下文给我，我就给你搭一个真正好用的方案。至少在 B2B 领域，大多数创业公司就是这么找到 PMF（产品市场契合）的。而 FDE 本质上就是把 design partnership 这个概念拿过来，放大到企业级规模。这就是 Palantir 最核心的一个断言：谁说 design partnership 只能用在公司最初那个阶段？为什么不能在企业级、在规模上照样这么干？当然，在座有些非常聪明、观察力很强的人可能会说：Kevin，这在企业级做不了，因为你维护不过来。如果你给每一个客户都定制一套东西，那你就等着像赶一群猫一样疲于奔命吧，你会攒下一堆烂到家的代码，再也不会有工程师愿意为你工作——因为根本没法维护，没人想去搞懂 55 个代码仓库。你说得完全没错。如果你搭出来的 FDE 职能是每个 FDE 都从零开始造轮子，那么朋友们，你根本没有 FDE 职能，你有的是一家外包开发公司（dev shop）。当然，这没什么不好，那也是很赚钱的生意。
[8:45] Kevin Bai
But the thing that makes an FTE program different is that they are building on top of a platform. They are never writing software from scratch. Right? There is already a set of primitives on top of which they could assemble them into some application, some workflow, some solution that is arbitrarily valuable to their customers. That is kind of the really key ingredient here because otherwise you are reinventing the wheel from scratch again and again and before you know it your P&L will eat you alive from the maintenance costs um if your engineers don't all quit first. Okay. Uh I feel like I just said a lot of words. Do people have a general idea of what I'm talking about? Yeah, some hands. Okay, great. Great. Oh my gosh. Um I'm above where I thought I'd be. So, okay, you're now saying, Kevin, that's cool. You know, you've just told the story, you've given some frameworks, but then I I'm not here to to listen to you talk, right? I want to know how to apply this to my organization, to my business, how to bring this back to my team. Um, so how do you go about doing that? First and foremost, and this is the thing that I advise to everyone who's thinking through the concept of forward deployed engineering is really ask yourselves, do I need an FTE function? Like, do I need one? Not want, right? It's easy to want things that are in vogue. It's easy to want to do, you know, AI because that's what everyone else is doing. But like, do I need one? Do I have some corner case in my business where I must must GTM a technically complicated thing to a non-technical buyer? If I don't have a situation like this, probably FTE is not
但让一个 FDE 项目真正不一样的地方在于：他们是在一个平台之上做东西的。他们从来不从零写软件。平台上已经有一整套 primitives（原语/基础构件），他们只需要把这些东西组装成某个应用、某条工作流、某个解决方案，而这个方案对客户来说价值可以高到没有上限。这才是这里真正关键的那味配料。否则你就是在一遍又一遍地重新发明轮子，等你回过神来，光维护成本就能把你的 P&L（损益表）吃干抹净——如果你的工程师还没先集体跑光的话。好，我感觉我一口气讲了一大堆。大家大致听懂我在说什么了吗？嗯，有几只手，太好了太好了。天哪，我进度比预想的还超前。那么现在你可能会说：Kevin，这挺酷的，你讲了故事，也给了几个框架，但我来这儿不是听你讲的，我想知道的是怎么把它用到我的组织、我的业务里，怎么把它带回我的团队。那具体该怎么做？第一件事，也是我给每一个在琢磨 forward deployed engineering 的人的建议：真的去问问你自己——我需要一个 FDE 职能吗？是「需要」，不是「想要」。想要一个当下正流行的东西太容易了，想要搞 AI 也太容易了，因为别人都在搞。但问题是：我需要吗？我的业务里是不是真有那么一个特殊角落，让我不得不把一个技术上很复杂的东西，GTM 给一个不懂技术的买家？如果没有这种处境，那 FDE 大概率
[10:25] Kevin Bai
the right fit. There's a lot of great things you could do uh with Devril and building a great developer engagement uh team if you're having a technical go to market motion. There's a lot of great things you can do with an SLG salesled motion if you're doing more traditional SAS. Right? It's only in this situation where you need FTE. That's the first piece. So the second piece is do I have a platform or phrased another way am I willing to invest in building one because I assure you right no matter how tempting it is to uh have these engineers that can make you money if they are not building on top of a platform with some number of shared primitives you are in for a very bad time. I I just I could not begin to stress the amount of maintenance burden that will be on your team even if you have a robust platform. Um, never mind if you don't have one. And so these are the questions that I would really encourage you to think about from an FDE 101 perspective of do I have to sell something complicated to a non-technical buyer and do I have a platform on top of which my FTEEs can build? Okay, now for the the AI piece because that's obviously happening in 2026. Um what's changed since Palanteer uh came onto the market which I think was like 2004 or 2005 um and now is that uh artificial intelligence has made it really really easy to build really really easy to write code and also really easy to build sophisticated customizable software for customers. I mean, how many people in the audience are building agent for X, you know, insurance, legal, what have you, right? Um, I don't even need to see the hands for this one. But the thing
并不适合你。如果你走的是技术型的 go-to-market，那你可以在 DevRel 上、在做一支优秀的开发者互动团队上做很多很棒的事。如果你做的是更传统的 SaaS，那你可以在 SLG（sales-led growth，销售驱动）打法上做很多很棒的事。只有在刚才那种特定处境下，你才需要 FDE。这是第一条。第二条是：我有平台吗？换个说法——我愿不愿意投入去建一个平台？因为我可以向你保证，不管「养一批能替我赚钱的工程师」这件事听起来多诱人，只要他们不是构建在一个有一定数量共享 primitives 的平台之上，你就有得受了。即便你已经有一个足够健壮的平台，那份维护负担有多重我都没法跟你形容——更别说你根本没有平台的情况。所以从 FDE 101 的角度，我真心建议你想清楚这两个问题：我是不是必须把一个复杂的东西卖给一个不懂技术的买家？我有没有一个能让我的 FDE 在上面搭东西的平台？好，接下来讲 AI 这块，毕竟现在是 2026 年，这事儿绕不开。从 Palantir 进入市场——我记得大概是 2004 或 2005 年——到今天，变化在于：人工智能让「写代码」变得非常非常容易，也让「为客户构建复杂的、可定制的软件」变得非常非常容易。我是说，在座有多少人是在做「某某领域的 agent」？保险的、法务的、随便什么领域，对吧？这个我都不用看举手。但真正变了的东西是——
[12:03] Kevin Bai
that's changed is not that the world has suddenly realized Palunteer's FTE motion is a really good idea and they should do that. My personal hypothesis is that the thing which has changed is that the nature of doing business in the software industry itself is what's changed because now nearly every platform is agentic. And that means nearly every platform is customizable. And that also means nearly all of you are going to have a situation where your customers have no idea what the heck it is that you actually do. And if you leave the success or failure of your product to their hands and to their ability to implement, I I assure you this is not uh you know like going to be an easy motion as you try and sell either into the up market or try and expand horizontally or vertically. All right, I think that's enough words out of me. I would really like to hear some questions from the audience. Uh, anything and everything is on the table except my current work.
并不是全世界突然醒悟过来，觉得 Palantir 那套 FDE 打法真是个好主意、大家都该照着做。我个人的假说是：真正变了的，是软件行业做生意这件事本身的性质。因为现在几乎每一个平台都是 agentic（智能体化）的。这意味着几乎每一个平台都是可定制的。这也意味着，你们几乎所有人都会遇到这样一种局面：你的客户压根不知道你到底是干什么的。而如果你把产品的成败交到他们手上、交给他们自己去实现的能力，我可以向你保证，当你想往上打大客户市场（up market）、想横向或纵向扩张的时候，这条路绝对不会好走。好，我觉得我说得够多了。我非常想听听现场的问题。什么都可以问，除了我现在手上做的工作。
[12:59] Kevin Bai
Thank you. [applause] Hands. Yeah.
谢谢大家。[掌声] 举手吧。好，你请。
[13:12] 观众提问
Can you give a little more detail like how atomic should these primitives be? Yeah. Just some example.
能再展开讲讲吗？这些 primitive（基础组件）应该拆到多细的粒度？对，最好举几个例子。
[13:19] Kevin Bai
Yeah, that's that's a really good question. So,
嗯，这个问题问得非常好。那么——
[13:22] Kevin Bai
the question first. Oh yes. So the question was um talk about shared primitives. How atomic should those shared primitives be? What does that mean? Um so okay if you are trying to sell a uh a a platform where you're building you know something that involves data models right um perhaps one place to start is is not having to you know define a data model from scratch. Um, but I would say, you know, um, and this is a very lawyerly answer is that it depends on what it is that you're getting into. Um, there's a lot of industries and a lot of situations where you can get away with having very robust primitives, right? Where the app itself is like 60% built and then people are just customizing the other 40%. Uh and then there are certain use cases in certain industries and spaces where that's really not appropriate and you you need extremely granular uh configur configurations and like extremely granular tooling. Um a good example of a platform that I think all of you should be familiar with is AWS, right? Um I'm sure you know many of the folks in the audience are really great engineers and if you wanted to you could you know buy your own server racks and then get them online and then maintain them. But who's really done that since you know the 1990s? Um but like within AWS right they give you a shared set of primitives uh like DynamoB so you don't have to you know invent a database from scratch uh but that's because they're trying to serve an extremely broad swath of customers so it depends on your user base anyone else yes right there Yeah. So the question is on uh what is the collaboration mechanism? Uh you know
我先复述一下问题。哦对。问题是：刚才讲到共享的 primitive，那这些共享 primitive 应该做到多原子、多细的粒度？这到底意味着什么？好，假设你要卖的是一个平台，你在上面搭的东西涉及数据模型，那一个可以考虑的起点，就是让用户不必从零开始定义数据模型。不过我要说——这是个特别像律师的答案——这取决于你做的是什么。有很多行业、很多场景下，你完全可以提供非常厚实的 primitive，应用本身相当于已经搭好了 60%，客户只需要自己定制剩下的 40%。但也有一些行业和场景，这么做根本不合适，你必须提供极其细粒度的配置能力和极其细粒度的工具。一个我觉得在座各位都很熟悉的平台例子就是 AWS。我相信台下很多人都是很厉害的工程师，你们真想干的话，完全可以自己买一堆服务器机架、接上网、自己维护。但从 90 年代以后，还有几个人真这么干？而在 AWS 里，它给你一套共享的 primitive，比如 DynamoDB，你就不用从零发明一个数据库。但那是因为它要服务的客户面极其广。所以说，粒度取决于你的用户群体。还有别的问题吗？好，那边那位。嗯，这个问题是关于协作机制的。就是说——
[15:10] Kevin Bai
if two FDES or multiple FDs work on a project I I would say that's really encouraged. Um that's a really good pattern because uh especially when you're doing custom work for a customer, the last thing you want is like a single point of failure, right? Where uh one person knows all the information, they go on vacation and then you're kind of screwed. And so
如果两个 FDE、或者多个 FDE 一起做一个项目会怎样。我会说这是非常值得鼓励的。这是个很好的模式，尤其是当你在给客户做定制工作的时候，你最不想要的就是出现单点故障——所有信息都只有一个人知道，他一休假你就抓瞎了。所以——
[15:29] 观众提问
two different companies,
我是说来自两家不同公司的。
[15:30] Kevin Bai
two different companies.
哦，两家不同的公司。
[15:31] 观众提问
Yeah. you go like let's just say to do a project you're going
对。比如说要做一个项目，你会——
[15:37] Kevin Bai
like working on the same project like a bake off okay or like collaboration like like a partner uh yeah yeah that model exists as well um it's just no different than having a contractor right uh you you have to figure out who the contractor is in that situation um but that's kind of the mental model
（观众补充：是在同一个项目上一起做，比如像比稿那种 bake off，还是像合作伙伴一样协作？）好，明白。嗯，这种模式也是存在的。它其实跟你请一个外包承包商没什么区别——你得先搞清楚在这种局面里谁是承包商的角色。大体上就是这么个心智模型。
[15:55] Kevin Bai
all right uh right there in the back that goes on That is a really good question. The question is uh what engineering changes go onto the platform versus what uh engineering changes go onto the forward deployed side. So anything that's bespoke and unique to a particular customer um is uh something that should really only exist for that one customer. Anything that can be generalizable should be generalized in the long term. Now, when you begin uh your FTEing, right, probably you're not going to have a lot of different primitives, but that's okay because FD is also a great way to scout ahead and to find what additional product services you can build upon to further enable the success of your business. Um, how we doing on time? Good. Oh, no, not good. All right. All right. Last question right there. What is the perfect profile?
好，后面那位。这个问题非常好。问题是：哪些工程改动应该沉淀进平台，哪些工程改动应该留在前置部署（forward deployed）这一侧？答案是：凡是为某个客户量身定做、只对他独有的东西，就应该只存在于那一个客户那里；凡是可以泛化的东西，长期都应该被沉淀成通用能力。刚开始做 FDE 的时候，你手上大概率没多少现成的 primitive，但这没关系——因为 FDE 本身就是一种很好的「探路」方式，帮你发现还可以补哪些产品能力和服务，来进一步支撑业务成功。时间还剩多少？还行。哦不，不太行。好，最后一个问题，那边那位。什么样的人是最合适的 FDE？
[16:59] Kevin Bai
Oh, this is so good. What is the perfect profile of an FTE? So, the the tagline that I will leave you with is that a FTE is nothing more than a customerfacing software engineer. And so, um it is a person who you would hire as a software engineer on your team, but at the same time, you would trust them in front of a customer in some shape or capacity. And then the rest you'll have to figure out as you go because we are capped. Thank you so much. [applause]
哦，这个问题太好了。什么样的画像最适合做 FDE？我想留给大家的那句总结是：FDE 无非就是一个「面向客户的软件工程师」。也就是说，这个人你愿意把他当软件工程师招进团队，同时你又敢让他以某种形式直接站到客户面前。剩下的就得你自己边做边摸索了，因为我们时间到了。非常感谢大家。［掌声］
[17:46]
[music]
［音乐］