What a Forward Deployed Engineer actually does, and why your team can’t hire one fast enough

FULLSTACK FIELD NOTES · PART 2 OF 7

The Forward Deployed Engineer (FDE) role, pioneered by Palantir about fifteen years ago and recently adopted by companies like OpenAI and Anthropic, is now essential for nearly every enterprise tech team. Yet, filling this critical position has proven challenging. 

Crucially, an FDE is fundamentally different from a Solutions Architect. While a Solutions Architect aligns a product with a customer's specified requirements, the FDE takes a more active, hands-on approach. They embed directly within the customer's operations to observe processes firsthand and use the new platform's capabilities to restructure the existing workflow. 

The necessity of the FDE stems from the nature of the challenge: bridging the gap between platform features and tangible business results is a challenge of operational translation, not just a lack of documentation. This translation can only be achieved through close proximity to the work.

What does an FDE actually do? 

An FDE does three things, in this order:

First, they shadow. They sit with the adjuster, the underwriter, the support engineer, the procurement analyst. They watch where the days go. They notice the things the business owner stopped noticing years ago because the workflow has been broken for so long. This part of the job cannot be done over Zoom. It goes beyond preparing a presentation deck with a strategy.

Second, they prototype against real data to create a working prototype that calls real APIs, reads real documents, produces a real output. The prototype is the artifact that aligns the technology roadmap with ground realities. Once a business owner sees the new workflow running on their own data, the discussion changes character. The question stops being “will this work” and becomes “how do my human employees and AI agents collaborate? What are the “seams”?”

Third, they ship the seam, the easiest way to understand which is the explicit boundary between what the agent does and what the human does. Agentic projects fail because this seam was never explicitly designed with the business context in mind.

You will know you have a real FDE on your team when they say something like: “Stage three of this process should be agent-led, but stage four has to stay human because of the regulatory exposure, and stage seven needs the human seam tuned by work type.” You will know you have a solutions architect when they say: “Here is how our platform supports stages three through seven.” While both sentences are useful, they are not the same! And without the former, AI-powered success remains theoretical.

If you fund one new role on your AI team this quarter, fund this one. Start with one. Pair them with one business owner who knows their process inside and out. Give them ninety days. Then look at what they produce and ask whether it changes any of your assumptions about how the work could run.

I am confident that it will.