Stop treating Forward Deployed Engineers as glorified consultants if you actually want

Why FDEs are not just consultants

The common mistake is hiring an FDE to deliver a Statement of Work (SOW). A consultant is paid to make the customer happy with a specific deliverable; an FDE is paid to make the product viable for a specific market. If your FDE is spending 40 hours a week writing custom Python scripts that will never be merged into the main codebase, you don't have an FDE—you have a contractor with a fancy title.

In my experience, the "pure" FDE role should focus on the gap between a general-purpose platform and a high-value use case. For example, at Citadel, the only metric that mattered was whether the software actually helped portfolio managers generate alpha. If the FDE spent three weeks building a dashboard that looked great but didn't move the needle on PnL, it was a failure, regardless of whether the customer "liked" the dashboard.

The Project Frontline approach to training

At Palantir, we ran a rotation called Project Frontline to pivot software engineers into FDEs. We put about 250 engineers through this. The goal wasn't to teach them how to "talk to customers," but to show them how their code broke in the wild.

The transition usually follows this pattern of failure:
1. The "It works on my machine" phase: The engineer deploys a feature and it fails immediately due to customer data being messier than the synthetic sets used in dev.
2. The "Custom Request" trap: The customer asks for a specific button or a niche integration. The engineer builds it manually to be "helpful."
3. The Scaling Wall: The engineer realizes that if they have to manually build this for 10 more customers, they will never actually write platform code again.

The "Aha!" moment happens when the engineer stops thinking about the specific customer's request and starts thinking about the class of problem that request represents. That is the shift from consulting to engineering.

Where the role usually breaks

If you are setting up an FDE team, watch out for these three red flags:

• Quota-carrying FDEs: If an engineer's bonus is tied to a sales quota, they will promise the customer features that don't exist just to close the deal. This creates massive technical debt for the core product team.
• The "Second Call" Syndrome: When an FDE is used as a technical ornament for a sales rep to look "engineering-heavy" during a demo, they aren't doing engineering.
• Siloed Feedback: If the FDE finds a critical bug or a massive product gap but has no direct line to the Product Manager (PM), the insight dies in a Slack thread.

For this to work, the FDE needs to be embedded in the customer's operations—literally sitting in their office or on their daily stand-ups—but reporting back to the product org. The cost of this is high; you're taking your most expensive talent away from the core build, but the trade-off is a product that actually solves a real-world problem instead of a theoretical one.