0:18 - 1:47
Scope, speaker context, and the FDE 101 roadmap
Video section: 0:18–1:47
The idea this lesson will build
Forward-deployed engineering (FDE) is a way to deliver software value when a customer needs more than access to a product. In this model, customer-facing software engineers work closely with the customer and build a solution using the vendor's technical platform. The intended result is a customer business outcome, not just a license or a completed software feature.
That short definition contains an important tension. The work must be specific enough to solve a real customer's problem. But it must also use reusable platform foundations. Otherwise, the company is simply doing separate custom development for every customer. Later chapters explain why this distinction matters.
Terminology note: The transcript sometimes renders the abbreviation as “FTE.” This lesson uses FDE, which is supported by the video metadata and later context.
What the speaker establishes
In this opening, Kevin Bai introduces himself as a technical-staff member on Anthropic's applied AI team. He also describes earlier experience building a first forward-deployed function at Rippling and working at Palantir.
This background explains the perspective of the talk. It does not by itself prove that FDE works for every company, product, or customer. The argument for the model comes later, through the kind of product being sold, the kind of buyer involved, and the presence of a platform that engineers can build on.
Do not confuse FDE with nearby roles
An FDE is easiest to understand by comparing it with roles that overlap with it.
| Role or model | Main emphasis | Why it is not the full FDE idea |
|---|---|---|
| Internal software engineer | Builds for the company, often away from a specific customer engagement | FDE work is directly connected to a customer's context and outcome. |
| Consultant | Advises a customer | Advice alone does not necessarily include building a solution on a technical platform. |
| Implementation team | Helps a customer set up or adopt a product | The later model emphasizes engineers who can build customer-specific software solutions, not only configure or train. |
| Custom development shop | Builds separate software for each client | FDE is meant to rely on shared platform capabilities, rather than recreate everything from scratch. |
These are contrasts for understanding, not rigid job categories. The talk's core claim is about the combination: customer proximity, software engineering, and a reusable platform.
A simple example (teaching context, not a video case)
Imagine a company sells a powerful platform to a large logistics business. The platform can organize operational data and support applications. The logistics buyer wants a concrete result: fewer delayed shipments.
An ordinary product sale gives the customer access to the platform. A pure consulting engagement might recommend a better process. In an FDE-style engagement, an engineer works with the customer, understands the shipping workflow, and builds a solution on the shared platform that helps the customer act on delays.
The important point is not that every logistics company needs FDE. The point is why the role can exist: the customer wants an operational result, while realizing that result requires both customer context and technical implementation.
The roadmap for the talk
The opening promises a progression rather than a single definition:
- History and role definition: What forward-deployed engineering is and where the model came from.
- Palantir's model: Why a technical platform can be paired with engineers to deliver a customer outcome.
- Go-to-market reasoning: Why this can be a way to sell and deliver to enterprise customers, rather than only a post-sale service.
- Adoption test: When another organization should consider this model—and when it should not.
- AI-era implications: Why more customizable, agentic software may increase customer implementation challenges. This is presented later as the speaker's hypothesis, not as a universal conclusion.
- Practical questions: How reusable platform building blocks, collaboration, and the boundary between bespoke and generalizable work affect the model.
The vocabulary to carry forward
The later chapters use several connected ideas:
- Technical platform: Shared technology that engineers can use as a base for solutions.
- Customer business outcome: The operational result the customer actually wants, such as improving a business workflow. It is different from merely owning software.
- Enterprise buyer: The organization or decision-maker purchasing the offering. A buyer is not always the same person as the eventual user.
- Shared primitives: Reusable technical building blocks on the platform. They are central to avoiding one-off codebases for every account.
- Go-to-market motion: The repeatable way a company sells and delivers its offering.
The rest of the lesson connects these terms in a causal chain: a complex platform may be difficult for some customers to turn into value; customer-facing engineers can help close that gap; reusable platform foundations are what keep this help from becoming unlimited custom work.
What to listen for next
The next chapter starts with the platform side of the model. It asks why organizing data and providing technical capability may still be insufficient from the customer's point of view. Keep this question in mind: if a platform is powerful, who does the work of turning that power into a specific business result?