Insights · Field Notes 03
FDE or not?
Last year, I wrote the Forward Deployed Engineer playbook. Since then, we have tested it with mid-size and enterprise clients. My view has not changed that much, but it has gotten sharper.
In 2026, startup FDEs wear four hats:
1. Problem “scoper”
Enterprises rarely come with a well-defined business problem. The FDE has to define the exact problem, quantify it, and decide what is actually worth solving.
2. Problem solver
The FDE architects the solution — deterministic software, non-deterministic agents, or a combination of both. The goal is to get to value.
3. Product / agent builder
Once #1 and #2 are done well, building software is becoming much easier. Building production agents is still hard. The FDE has to define the job to be done, build evals, define rules and access controls, set human approval points, design continuous learning, and keep improving the agent from production feedback.
4. Momentum generator
FDE is an active role. You are in the arena. The FDE has to force decisions, push adoption, remove blockers, and continuously find opportunities to expand within the account.
FDE-driven businesses have high CAC by default. The FDE therefore has to create enough value to justify the model. You can only do that by creating momentum inside your account.
The biggest assumption behind all of this: The startup needs its own software / agent factory underneath the FDE. Every deployment should make the next deployment easier.
If every customer starts from scratch — or your entire delivery system is Claude Code / Managed Agents plus humans — good luck compounding. We believe you need a production runtime for your coding agents to control loops, unit economics, and competitive advantage.
Originally published on LinkedIn.