Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE

AI Engineer · 17 min · 213 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:16All right.
00:16Thank you so much, Basil, for the introduction.
00:19Hello there.
00:19Those of you in the audience, thank you so much for joining us today.
00:22My name is Kevin.
00:23Uh, technically we don't really have titles.
00:26So I am member of technical staff at Anthropic working on the applied AI team.
00:31Uh before this I joined Ripling to help build their FTE function.
00:35I was the first person to join that team and we grew it to uh around 25 in a year.
00:40Um and so that's pretty cool.
00:42And then before that did a bunch of stuff at Palunteer.
00:45But you know list of companies is not really that interesting right because we're talking about a function.
00:50And what I I hope you're all here for is to hear about forward deployed engineering.
00:56Um 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.
01:03Uh I'm also not qualified to talk about those things.
01:06So I am trying to give a talk to you on for deployed engineering 101.
01:11So 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
01:23and then right extend that to maybe how you could apply it to your own organizations and businesses.
01:29Um and if possible at the end would love to take any and all questions.
01:34All right, does that sound good?
01:36Yeah.
01:36Okay, that's too low energy.
01:38Does that sound good?
01:40There we go.
01:40Oh my god, it's a conference, not a funeral.
01:42Let's go.
01:43Um, so, okay, high level, right?
01:47What does Palunteer do?
01:48Palunteer is a technology company that creates a technology platform, uh, a software platform called Foundry.
01:57What Foundry does is Foundry enables organizations of arbitrary size to centralize all of their data in one place to create an ontology.
02:08What that means is to create proper nouns out of their data.
02:11So 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.
02:19And then on top of that, Foundry enables companies to build applications.
02:24Okay.
02:25So 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?
02:36Right?
02:36And and so that's that's kind of where it falls short if you're just selling technology.
02:40Um 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.
02:52And so there's also a huge tax, right?
02:54Not only are customers paying to invest in this platform, they are also needing to train up their people to get effective on it.
03:00And then and only then are they able to build things.
03:03That is a terrible way to do business.
03:05And we soon realized that instead of selling just services or just products, you sell both.
03:12Um, so it's one combined thing where the customer is neither buying a piece of software nor are they buying the time of someone.
03:19They are buying an outcome, right?
03:21You are sending over really smart people who will go and understand the nature of the customer's business.
03:27Build 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
03:39you 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.
03:50So where does this notion come from?
03:52This 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.
04:03And so I want to make this like really really clear.
04:06Okay, you can imagine this as a punit square.
04:09Um it has to do with what it is you're selling and then who it is that's buying from you.
04:15So if you sell a very technical platform or product, right, let's forget Foundry for a second.
04:21If you sell a GitHub or if you sell um a data dog, it is a incredibly complicated piece of software.
04:29However, your ICP, right, are going to be CTO, CIOS, and then your users are going to be software engineers.
04:35They're going to be people who can take and absorb this complexity and use it because it's part of their job.
04:40The other situation is you are selling something that's not that complicated.
04:44Um, and your buyer is not that technical, which is also fine, right?
04:48Say 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.
04:56They're not meant to be developed upon.
04:58And so, it's fine to be selling to a non-technical buyer.
05:03You 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.
05:13Now, historically, why was that the case?
05:15You know, like, didn't Palanteer like to do things easier than that?
05:18Well, 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.
05:26Uh, Google, Meta, what have you, these days, the labs, they all have great software engineers and they can build whatever apps the organization needs.
05:33Um, 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?
05:43Their pipelines are not data pipelines.
05:45It's more going to be, you know, uh, fluorocarbons or something like that.
05:48So, 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.
06:00We will loan you some really good engineers that you don't have to hire, recruit, manage or retain.
06:06They 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
06:18and they will figure out how to solve you the problem and then build you the software.
06:22And 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?
06:31Because because there's no point in me just getting on stage saying, "Oh, this is so cool.
06:35You know, here's the details, blah, blah, blah."
06:37So, I'll give you some numbers.
06:39If 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?
06:52Balance is first at 4 million uh last I checked.
06:56Next biggest is Service Now at 1.2. Next biggest I want to say is workday at 600K.
07:02And then there is not a single public SAS company that even cracks half a million ACV.
07:07So just by these numbers I would say it works pretty well.
07:09Um Palunteer is at some ridiculous valuation now uh and only at a few thousand headcount.
07:15Um so okay what is this FTE thing?
07:19What is this model?
07:20What does this mean?
07:21Um do we have any startups in the audience or anybody working early stage?
07:24Yeah.
07:25Okay.
07:25Some hands.
07:26So I'm sure you're familiar with the concept of a design partnership.
07:30So 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.
07:37Let me figure out what it is you need.
07:39I will, you know, spend my time, my energy, my technology, my resources.
07:43You just give me the context on what your problem is and I'll build you a really good solution."
07:47That's generally how most startups at least in the B2B segment find product market fit.
07:53Um FDE is basically taking this concept of a design partnership and scaling it up into enterprise.
08:01Right?
08:01That was the core assertion of Palanteer was that who said who said that design partnerships were only for the beginning stages of a company.
08:10Why can you not just do that at scale at enterprise?
08:13Well, 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.
08:19If 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.
08:32And you would be totally right.
08:34If you were to implement an FTE function where each FTE is building entirely from scratch, my friends, you do not have an FTE function.
08:41You have a dev shop.
08:42Um, nothing wrong with that.
08:43Of course, those are really profitable businesses.
08:45But the thing that makes an FTE program different is that they are building on top of a platform.
08:52They are never writing software from scratch.
08:54Right?
08:54There 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.
09:06That 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
09:17um if your engineers don't all quit first.
09:20Okay.
09:20Uh I feel like I just said a lot of words.
09:22Do people have a general idea of what I'm talking about?
09:25Yeah, some hands.
09:27Okay, great.
09:28Great.
09:28Oh my gosh.
09:29Um I'm above where I thought I'd be.
09:32So, okay, you're now saying, Kevin, that's cool.
09:36You 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?
09:42I want to know how to apply this to my organization, to my business, how to bring this back to my team.
09:47Um, so how do you go about doing that?
09:50First 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?
10:01Like, do I need one?
10:03Not want, right?
10:04It's easy to want things that are in vogue.
10:06It's easy to want to do, you know, AI because that's what everyone else is doing.
10:09But like, do I need one?
10:11Do I have some corner case in my business where I must must GTM a technically complicated thing to a non-technical buyer?
10:21If I don't have a situation like this, probably FTE is not the right fit.
10:26There'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.
10:33There's a lot of great things you can do with an SLG salesled motion if you're doing more traditional SAS.
10:38Right?
10:38It's only in this situation where you need FTE.
10:41That's the first piece.
10:42So 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
11:00you are in for a very bad time.
11:02I 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.
11:10Um, never mind if you don't have one.
11:12And 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?
11:28Okay, now for the the AI piece because that's obviously happening in 2026.
11:33Um 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
11:52customizable software for customers.
11:55I mean, how many people in the audience are building agent for X, you know, insurance, legal, what have you, right?
12:00Um, I don't even need to see the hands for this one.
12:02But the thing 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.
12:10My 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.
12:25And that means nearly every platform is customizable.
12:28And 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.
12:35And 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
12:45motion as you try and sell either into the up market or try and expand horizontally or vertically.
12:51All right, I think that's enough words out of me.
12:54I would really like to hear some questions from the audience.
12:56Uh, anything and everything is on the table except my current work.
12:59Thank you.
13:02[applause]
13:08Hands.
13:09Yeah.
13:12Can you give a little more detail like how atomic should these primitives be?
13:17Yeah.
13:17Just some example.
13:19Yeah, that's that's a really good question.
13:21So,
13:22the question first.
13:23Oh yes.
13:23So the question was um talk about shared primitives.
13:26How atomic should those shared primitives be?
13:29What does that mean?
13:30Um 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.
13:47Um, 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.
13:54Um, there's a lot of industries and a lot of situations where you can get away with having very robust primitives, right?
14:02Where the app itself is like 60% built and then people are just customizing the other 40%.
14:06Uh 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.
14:18Um a good example of a platform that I think all of you should be familiar with is AWS, right?
14:24Um 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.
14:33But who's really done that since you know the 1990s?
14:36Um 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
15:05Yeah.
15:05So the question is on uh what is the collaboration mechanism?
15:09Uh you know if two FDES or multiple FDs work on a project I I would say that's really encouraged.
15:14Um 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?
15:23Where uh one person knows all the information, they go on vacation and then you're kind of screwed.
15:28And so
15:29two different companies,
15:30two different companies.
15:31Yeah.
15:31you go like let's just say to do a project you're going
15:37like 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
15:52um but that's kind of the mental model
15:55all right uh right there in the back that goes on That is a really good question.
16:12The question is uh what engineering changes go onto the platform versus what uh engineering changes go onto the forward deployed side.
16:21So anything that's bespoke and unique to a particular customer um is uh something that should really only exist for that one customer.
16:30Anything that can be generalizable should be generalized in the long term.
16:34Now, 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.
16:49Um, how we doing on time?
16:50Good.
16:51Oh, no, not good.
16:52All right.
16:53All right.
16:53Last question right there.
16:56What is the perfect profile?
16:59Oh, this is so good.
17:00What is the perfect profile of an FTE?
17:04So, the the tagline that I will leave you with is that a FTE is nothing more than a customerfacing software engineer.
17:14And 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.
17:25And then the rest you'll have to figure out as you go because we are capped.
17:28Thank you so much.
17:30[applause]
17:46[music]