Video summary

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

Main summary

Key takeaways

Business

Forward Deployed Engineering (FDE) 101 — Business Summary

What Palantir / FDE is (and why it exists)

  • Palantir sells a software platform (“Foundry”) used to centralize data into an ontology (e.g., turning many tables into a single source of truth per domain object such as “warehouses”).
  • The platform’s value depends on the customer’s ability to successfully build applications on top of it.
  • This creates a classic SaaS/platform problem:
    • Customers don’t just pay for software—they must train people and implement correctly to get outcomes.
    • Selling only software or only services creates a bad business equation because neither side owns the end-to-end outcome.

Solution: Product + services (outcome-selling via “forward” engineering)

  • Palantir combines product + services by deploying highly skilled “forward” engineers to build on the customer’s behalf using the platform.
  • The thing being sold is an outcome, not “software implementation labor.”

The core strategic positioning (when FDE is the right GTM motion)

FDE is framed as a specific go-to-market corner case, not a universal strategy.

Use FDE if:

  • You must sell a technically complicated platform/workflow to a non-technical buyer (or a buyer lacking deep domain/engineering implementation capacity).

Avoid FDE if:

  • Your buyer is technical enough to absorb platform complexity (then standard tech-led selling works).
  • Your product is “complicated but configurable”—e.g., Slack/Jira/Rippling—then you likely don’t need FDE.

Why this matters

  • FDE is expensive operationally, but it closes the gap between:
    • platform complexity
    • customer implementation capability

Why Palantir adopted FDE (rationale)

  • Large tech companies (Google/Meta/etc.) can build internal apps, so Palantir’s platform is less compelling “as-is.”
  • For Fortune 500 non-tech-domain engineering environments (e.g., industries where workflows aren’t “data engineering”):
    • Customers often lack the engineering depth to realize the platform’s value.

How FDE bridges the gap

FDE “loans” skilled engineers who:

  • Get trained on the platform,
  • Work closely with customers (positioned differently than a fine dining waiter model),
  • Build the needed applications/workflows so customers see business outcomes.

Evidence cited: contract size / ACV (proxy for success)

Using public SaaS companies in Fortune 500 as a benchmark (ACV = average contract value):

  • Palantir is described as:
    • ~$4M+ ACV (largest public SaaS example cited; “last I checked”)
    • Next largest examples:
      • ServiceNow ~ $1.2M
      • Workday ~ $600K
  • Claim: no other public SaaS company breaks ~$500K ACV in that comparison set.
  • Also stated (anecdotally): Palantir has grown to a few thousand headcount with a “ridiculous” valuation.

Note: No explicit time horizon is provided beyond “last I checked,” and the Palantir era.

What FDE actually is (framework)

FDE is described as:

  • Scaling a “design partnership” approach (early-stage startup product/PMF practice) into enterprise.

Design partnership (startup analogy)

  • Early startup teams work closely with customers to understand needs and build solutions.

Enterprise concern (classic objection)

  • You can’t do “custom from scratch” for everyone.
  • The objection is maintenance burden and unmaintainable code, which turns the motion into a dev shop rather than an FDE-scalable model.

What makes FDE different

  • FDE teams build on top of a platform using shared building blocks (“primitives”).
  • They assemble solutions rather than invent everything from scratch.
  • If you build from scratch per customer, you can make a profitable dev shop, but not an FDE-scalable platform motion.

How to apply FDE internally (practical checklist)

The talk provides an “FDE 101” decision process:

  1. Do you need FDE (or just want it)?

    • Ask: Do you have a “must” scenario where you need to GTM a technically complicated thing to a non-technical buyer?
    • If not, consider alternatives:
      • Developer engagement team / SLG-style motions for technical GTM
      • Sales-led motion for traditional SaaS

  2. Do you have (or will you build) a platform?

    • If you don’t invest in platform shared primitives, FDE becomes unmanageable due to:
      • maintenance burden
      • engineers leaving
      • operational unsustainability

  3. AI-era implication (2026 hypothesis)

    • The change isn’t “everyone learned FDE is good.”
    • Hypothesis: platforms are becoming more agentic/customizable, so customers may not understand what the product does.
    • Therefore outcome delivery becomes harder to fully delegate to customers → more FDE-like support may be needed for adoption/expansion.

Platform “primitives” guidance (Q&A extracted rules of thumb)

How atomic should primitives be?

  • It depends (domain and use-case breadth).
  • Two patterns:
    • Some platforms can rely on robust primitives with heavy customization on top.
    • Others need very granular tooling/configuration.
  • AWS example: shared primitives like DynamoDB prevent reinvention of core components because AWS serves a broad customer base.

Engineering changes: platform vs FDE side

  • Bespoke/unique to a single customer → keep customer-specific.
  • Generalizable improvements → add to the platform over time.
  • FDE is also positioned as a way to “scout ahead” for new product services that should become platform capabilities.

Operating model questions (collaboration, engineering ownership)

If multiple FDEs collaborate on one project

  • Encouraged to avoid single points of failure (e.g., vacation/knowledge concentration).
  • The mental model is “like a contractor” / “like a partner,” but within the FDE function.

Team profile definition (talent playbook)

Perfect profile of an FDE

  • Defined as: a customer-facing software engineer.
    • Someone you’d hire as a software engineer on your team,
    • But you can also trust in front of customers (in some capacity).
  • The remaining specifics are left to “figure out as you go” (no detailed hiring rubric provided).

Key frameworks / playbooks explicitly referenced

  • Design partnership → scaled to enterprise (core conceptual framework)
  • Product + services → outcome-based selling (GTM/monetization model)
  • Platform primitives + assembly (avoid writing from scratch) (operating principle)
  • Decision criteria for needing FDE vs alternatives (“do I need it?” “do I have a platform?”)

Key metrics / targets mentioned

  • ACV benchmarks (Fortune 500 public SaaS comparison):
    • Palantir: ~$4M ACV (largest)
    • ServiceNow: ~$1.2M
    • Workday: ~$600K
    • Claim: none else cracks ~$500K ACV
  • Team growth anecdote (Kevin’s experience at Rippling):
    • Built a function from the first hire to ~25 people in ~1 year
  • No explicit CAC/LTV/churn targets were stated.

Concrete examples / comparisons used

  • Foundry ontology example: multiple tables → single source of truth (e.g., “warehouses”)
  • AWS primitives example: DynamoDB as a shared primitive preventing customers from reinventing databases
  • Fine dining waiter metaphor: engineers as “waiters” catering closely to customer needs
  • “Don’t need FDE” product categories: Slack/Jira/Rippling as configurable tools

Presenters / sources

  • Presenter: Kevin Bai (Anthropic; previously Rippling founding FDE function; previously Palantir)
  • Company referenced: Palantir (Foundry and FDE go-to-market motion)
  • Additional individuals mentioned only as context: Basil (introduced the speaker)

No other named presenters.

Original video