Show notes: Forward Deployed Engineering 101

Video: Forward Deployed Engineering 101, Kevin Bai (Anthropic, ex-Palantir, founding Rippling FDE), AI Engineer conference.

Also drawing on: What is a Forward Deployed Engineer? (with Founding Rippling FDE), Kevin Bai on Exponent, which goes deeper on the craft of the role and the shape of the career.

Kevin Bai has run the same function at three companies: Palantir, then as the first hire building Rippling's forward-deployed team (to about 25 people in a year), now on Anthropic's applied AI team. His framing is that the list of companies is the boring part. Forward deployed engineering is not a job title, it is a go-to-market motion, invented at Palantir for one specific and awkward situation: selling something deeply technical to a buyer who cannot operate it. The talk is the history of the role, the single test for whether you need one, the trap that quietly turns the whole thing into a dev shop, and the reason 2026's agentic software puts almost everyone in Palantir's old position.

Sell the outcome, not the software or the services

Start with what Palantir actually sells. Foundry lets an organization of any size centralize its data in one place and build an ontology, which Bai defines plainly as turning your data into proper nouns: instead of table one, table two, table three, you get a single source-of-truth table called "warehouses," and then you build applications on top of it. The trouble is that a technology sale stops there. An industry leader hears "you organized my data" and asks the fair question: what does that do for my business? And there is a second cost hiding underneath, a tax. The customer pays to buy the platform and then pays again to train their people to be effective on it before they can build a single thing. Bai calls that a terrible way to do business.

The move that fixes it is to stop choosing between selling a product and selling a service, and sell both fused into one thing. The customer is not buying software and not buying someone's hours. They are buying an outcome. You send in smart people who learn the shape of the customer's business, assemble a solution on the platform, and hand back the result. A consumer-goods executive cares about shelf placement and sales throughput, not how the data is modeled, and Bai's point is that they are right not to care: the data model is an implementation detail.

Put simply: the customer is not buying your platform or your engineers' time. They are buying the outcome those two produce together, and everything under it is an implementation detail they are right to ignore.

The one quadrant that needs a forward deployed engineer

Bai is blunt that software engineers are some of the last people who should be customer-facing, so you only put them there in one narrow case. Draw a two-by-two: what you sell runs from simple to deeply technical, and who buys runs from technical to non-technical. Three of the four squares do not need forward deployed engineers. Sell a technical product to a technical buyer, a GitHub or a Datadog bought by a CTO and used by engineers, and the users absorb the complexity because that is their job. Sell a simple, configurable product to a non-technical buyer, a Slack or a Jira, and it is meant to be configured, not developed on, so a non-technical buyer is fine. The forward-deployed motion exists for the one strange corner Palantir lived in: a deeply technical thing sold to a buyer who is not technical at all.

Why was Palantir stuck there? Foundry, as an app-building platform, is not that interesting to the big technology companies, because Google, Meta, and the labs already have engineers who can build whatever apps they need. But sell to a Fortune 500 firm in oil and gas and there is no such depth, since, as Bai puts it, their pipelines are fluorocarbons, not data pipelines. So rather than trust that customer to learn and operate the platform, you loan them excellent engineers they never have to hire, recruit, manage, or retain, trained on the platform and working shoulder to shoulder, the way a fine-dining waiter caters to every need: figure out the problem, then build the software that solves it.

Put simply: you only need forward deployed engineers in one specific situation, when the thing you sell is too technical for the person who has to buy it, and no amount of documentation closes that gap. Everywhere else, a lighter motion does the job.

There is a wrinkle worth naming, because Bai embodies it. He puts Rippling in the configurable, no-FDE cell, yet he is the founding forward deployed engineer at Rippling. In the second interview he quietly drops Rippling from the example and lists only a Slack or a Jira, which suggests he noticed the awkwardness himself. The resolution is that the quadrant tells you when a product forces you to run forward deployed engineers, not when a company may choose the motion anyway. A simple, configurable product sold up-market into large, messy enterprises can still run the forward deployed play on purpose, to win hard accounts and discover the next product, which is exactly what Rippling did, and why Bai was there to build the team.

Put simply: the quadrant says when a product leaves you no choice but to embed engineers. It does not say a configurable product can never use the motion. Rippling is the proof: fine to configure, and running a forward deployed team anyway to crack the enterprise.

The proof is in the contract value

Bai refuses to leave it at "this is cool," so he reaches for numbers. Rank the public SaaS companies serving the Fortune 500 by average contract value, how much a single customer spends with a single vendor, and Palantir sits first at about four million dollars. ServiceNow is next at roughly one and a quarter million. Workday follows near six hundred thousand. After that, no public SaaS company even clears half a million in ACV. Palantir carries a famous valuation on only a few thousand people. The forward-deployed motion is expensive to run, and it buys contracts several times larger than anyone selling software the ordinary way.

Put simply: the model is expensive, and the contracts it wins are a multiple of what ordinary software sales bring in, which is why a labor-heavy company with a few thousand people can out-earn per customer everyone selling seats.

A design partnership, scaled to the enterprise

Underneath the jargon, Bai says, forward deployed engineering is a familiar thing done at an unfamiliar size. Early-stage founders know the design partnership: you do not yet know your product and the customer does not yet know what they are buying, so you work closely, spend your own time and energy and technology, take their context on the problem, and build them a genuinely good solution. That is how most B2B startups find product-market fit. Palantir's core assertion was to ask who decided that design partnerships were only for the beginning of a company. Why not run one at scale, at enterprise, as the permanent go-to-market motion rather than a phase you grow out of.

Put simply: the whole model is a design partnership that never graduates, the intimate early-stage way of finding what a customer needs, deliberately kept as the permanent motion into the largest accounts.

A platform, or you just built a dev shop

Here is the caveat Bai stresses hardest, because it is where the model quietly dies. If every forward deployed engineer builds each customer's solution from scratch, you do not have a forward-deployed function, you have a dev shop. He is careful that dev shops are fine and often profitable, but they are a different business, and the difference is a platform. A real forward-deployed engineer never writes software from scratch; they assemble a set of existing primitives into the application or workflow that is valuable to this particular customer. Skip the platform and you are reinventing the wheel every engagement, and, in his words, your P&L gets eaten alive by maintenance costs, assuming your engineers do not all quit first from being asked to maintain fifty-five bespoke repos.

Put simply: forward deployed engineers must build on a platform of shared primitives, never from scratch, because the version that writes bespoke code for every customer is not a scalable motion, it is a dev shop with a maintenance bill that compounds until it kills you.

Two questions before you build one

Bai turns the talk into advice with two gating questions, and he wants them asked in order. First, do you need a forward-deployed function, not want one. It is easy to want what is in vogue, easy to want to "do AI" because everyone else is, but the real test is whether you have a corner case where you must take a technically complicated thing to market in front of a non-technical buyer. If you do not, forward deployed engineering is the wrong tool, and a developer-relations team or a traditional sales-led motion will serve you better. Second, do you have a platform, or are you willing to invest in building one, because without shared primitives the maintenance burden will bury even a strong team, and a team without a platform never stood a chance.

Put simply: run two gates before hiring a single forward deployed engineer, do I truly need one and do I have a platform to build on, and failing either means the honest answer is DevRel, sales-led, or a dev shop, not FDE.

Why 2026 puts almost everyone in Palantir's shoes

The last move is the one that makes a niche Palantir motion suddenly everyone's problem. Palantir came to market around 2004, and Bai's read on 2026 is not that the world finally recognized the forward-deployed motion as clever. His hypothesis is subtler: the nature of software itself has changed, because nearly every platform is now agentic, and an agentic platform is by definition customizable. That means a growing share of companies are shipping products their customers cannot fully grasp, the exact condition that put Palantir in its awkward quadrant. Leave the success or failure of an agentic product to the customer's ability to implement it, and moving up-market or expanding across a customer base gets very hard. The awkward corner is spreading to cover the whole room.

Put simply: AI did not make people admire Palantir's model, it made every platform agentic and therefore customizable, which drops a rising share of companies into the same quadrant Palantir was stuck in, selling something the buyer cannot fully operate.

What a forward deployed engineer actually is

In the Q&A Bai fills in the practical edges. On how atomic the shared primitives should be, his honest answer is that it depends: some industries let an app arrive sixty percent built with the last forty percent configured, while others demand extremely granular tooling, and the reference point he offers is AWS, which hands you primitives like a managed database so you never invent one from scratch, precisely because it must serve an enormous range of customers. On what belongs where, anything bespoke to a single customer should stay with that customer, and anything generalizable should be generalized over time, which is also why the forward-deployed team doubles as a scout that finds the next product worth building. And on the perfect profile, the tagline he leaves the room with is that a forward deployed engineer is nothing more than a customer-facing software engineer: someone you would hire onto your engineering team and also trust in front of a customer.

Put simply: a forward deployed engineer is a customer-facing software engineer, an ordinary engineering hire you would also put in front of a customer, and everything else, the primitives, the bespoke-versus-general split, the scouting, follows from holding both of those at once.

Three hats, and the skill under them

In the second conversation Bai sharpens the profile from a one-liner into something more useful. The role, he says, is about wearing three hats at once: consultant, product manager, and software engineer. The best forward deployed engineers hold all three in one person, though some organizations split them across a small team. It is not a software job with a twist; it sits at the intersection of three disciplines, which is why you carry, in his words, three times the failure surface of someone who just did one of those jobs well. Under the three hats, the skill that matters most is not coding, it is listening. You have to get someone to tell you the things they do not want to tell anybody, because the problem they report is almost never the real problem, it is the symptom. And on the engineering hat he draws a line most engineers miss, between quality and completeness. Completeness is handling the totality of the problem, the ways it can be used and the ways it can be misused. His example: write a function that adds two numbers, forget to mention it cannot take strings, and the customer decides the whole app is broken. There is no QA team and no operations team to hand off to. You are everything, end to end.

Put simply: a forward deployed engineer is a consultant, a product manager, and a software engineer fused into one person, and the rarest of those skills is listening well enough to hear the real problem under the one the customer reports. You own the outcome end to end, so completeness, not just quality, is the job.

A terminal title: the CEO of a one-customer company

Bai's last reframe is about the career, and it is unusual. At Palantir, forward deployed engineer is a terminal title: you are hired as one on day one, and ten years later you are still one. The person running the commercial business, moving nine figures of revenue, still carries the title FDE. You do not get promoted out of it, you grow by scope. The model he offers is that you are the CEO of a one-customer company. You are not allowed to get more customers, so your only way to make revenue is to make your single customer more and more successful, and as you do, your remit widens: from a slice of one customer, to the whole customer, to an industry, to a sector, to a geography. The title stays fixed while the scope compounds underneath it.

Put simply: forward deployed engineer is a terminal title you grow inside, not out of. You run your account like the CEO of a company with exactly one customer you can never trade, so the only lever is making that customer succeed, and your scope widens from a slice of them to a whole geography.

Takeaways

• Sell the outcome, not the software or the services. The customer buys the result; the platform and the engineers' hours are folded into the price, and the data model is an implementation detail they are right to ignore.
• You need forward deployed engineers in exactly one quadrant: a deeply technical product sold to a non-technical buyer. Everywhere else, DevRel or a sales-led motion is the better tool.
• The ACV is the proof. Palantir's ~$4M average contract value against ServiceNow's $1.2M and Workday's $0.6M shows an expensive motion winning contracts several times larger.
• Forward deployed engineering is a design partnership scaled to the enterprise and never allowed to graduate.
• Build on a platform of shared primitives, or you have a dev shop whose maintenance bill compounds until it kills you.
• Ask two gates in order: do I need it, and do I have a platform. Fail either and the answer is not FDE.
• 2026's twist: agentic products are customizable by default, so a rising share of companies land in Palantir's old quadrant whether they planned to or not.
• The profile in one line: a customer-facing software engineer. In more detail, three hats in one person, consultant, product manager, and engineer, where the rarest skill is listening for the real problem under the symptom, and you own the outcome end to end, so completeness matters as much as quality.
• Forward deployed engineer is a terminal title you grow inside, not out of: run your account like the CEO of a company with one customer you can never trade, and your scope widens from a slice of them to a whole geography.
• The quadrant is a heuristic, not a law. A configurable product can still choose the forward deployed motion to crack the enterprise, which is why Bai, who cites Rippling as a no-FDE example, went and built Rippling's FDE team.