Video summary
The Dirty Secret of Forward Deployed Engineering — Natalie Meurer, Sierra
Main summary
Key takeaways
Summary of Technological Concepts, Product Features, and Analysis
What “forward deployed engineering” is (and why the term is controversial)
- The speaker (Natalie Meurer, Sierra) argues that the “dirty secret” is that forward deployed engineering (FDE) doesn’t exist as a coherent, stable definition—the term has been stretched to cover many different roles.
- Despite this ambiguity, she frames FDE as one of the hottest job tracks in AI, with meaningful continuity across different eras.
Historical evolution (Palantir → modern practice)
The talk describes FDE as a timeline of expanding responsibilities, rather than discrete phases:
-
2008–2012: FDE resembles DevOps / platform stability
- Early deployments focused on keeping platforms stable in customer environments, including on-prem and cloud instance management.
- Example: her onboarding project at Palantir involved deploying software to an EC2 instance, where issues could be urgent (e.g., customer reports something unplugged at 2:00 a.m.).
-
2012–2016: Data integration becomes central
- Palantir develops data integration software, so FDE must help customers integrate data across many systems.
- Engineers model customer data using an “ontology” concept (Palantir terminology), essentially a taxonomy for data.
- Implementations often relied on older tech stacks (she mentions Java / Java Swing).
-
2016: Custom solutions and dashboard builders (Slate → dashboards that write back)
- FDE helps build custom solutions for known problems.
- Mentions Slate, a drag-and-drop builder mapping UI components to data sources (conceptually compared to tools like Retool).
- Emphasizes dashboards must write back to data sources; otherwise they decay and become less useful.
- This connects to Foundry, Palantir’s main platform, focused on moving data toward decision-making.
-
2020 onward: Enablement + scaling customer self-sufficiency
- Palantir shifts toward empowering customers to do more themselves (less dependence on shipping engineers onsite).
- Example: Airbus Skywise enabling thousands of engineers to use the Foundry platform.
- Mentions an AIFTE-style system using large language models to assist similar work.
- FDE also includes training/bootcamps (she references AIP bootcamp-style enablement).
Core continuity: “accountable to the customer”
Across DevOps, data integration, custom solutions, and enablement, the key thread is:
- Every deployed engineer is accountable to the customer for outcomes in some form.
This accountability becomes the lens for why FDE matters.
How FDE changes when code becomes cheaper (agents & product impact)
- With AI agents, code generation becomes faster and cheaper (e.g., “prompt → agent → good output”).
- The speaker argues FDE engineers can now do more than prototype:
- They can build end-to-end solutions using coding agents.
- They can translate customer-accountability signals into product improvements—such as stability improvements or better data integration.
Blurring boundaries: product engineering converges with customer-facing work
She claims role boundaries are blurring:
- Product engineering becomes more client-facing
- A strong product/infrastructure engineer should also understand deployment (DevOps) and customer needs
- FDE “gets larger” by stacking skills rather than remaining a single role
Pricing model analysis: toward outcome-based pricing
She connects FDE with changing approaches to software monetization:
- Sierra uses outcome-based pricing: pay based on value delivered.
- Contrast with older models:
- Seat-based pricing: harder to tie to measurable outcomes
- Usage-based pricing: common with foundation models (e.g., OpenAI/Anthropic), but outcomes are hard to attribute directly
- With AI agents, she predicts pricing will shift toward outcome-based because it’s outcomes (sales, solved inquiries, achieved customer goals) that matter most.
“Agent engineering” vs “FDE” (discipline stacking and renaming)
Earlier, while at Sierra, she wrote:
- Agent engineering should be treated as a subdiscipline of AI engineering
- It should have customer accountability similar to FDE, but remain a distinct domain
Now she revises the framing:
- Everything trends toward being forward deployed engineering, including:
- product engineering
- solutions engineering
- customer engineering / enablement
- building and deploying agents
Closing stance / hiring note
- The slogan: “Forward deployed engineering is dead. Long live forward deployed engineering.”
- Meaning: the term is incoherent, but the underlying customer-outcome practice is expanding.
- Sierra is hiring across forward deployed engineering roles.
Main speakers / sources
- Speaker: Natalie Meurer (Head of Agent Engineering, Sierra)
- Sources mentioned:
- Palantir (historical reference and platform concepts like Foundry, Slate, “ontology”)
- Emergence Capital (referenced in discussion of code becoming cheap / market shift)
- Elliot Greenwald (Sierra head of go-to-market ops; mentioned via a blog post reference)
- Companies/figures mentioned:
- Google (GCP)
- OpenAI
- Anthropic
- Aaron Levie
- Airbus Skywise
- AIFTE (Sierra internal/follow-on work mentioned by name)
Rate this summary
Your feedback will help improve summaries.
Improve this summary
Reprocess with a stronger model when the summary feels incomplete or inaccurate.
Translate summary in another language
Ask questions to this video
Chat for follow-up questions, clarifications, and source-backed answers.