Explore Founder OS: AI tools to help you build faster
Founder OS Founder OS
By Neta Geva
By Neta Geva
The Forward Deployed Engineer has grown mainly within AI companies selling to enterprise organizations, and understanding what the role actually does, and what it demands from the rest of the company, matters before any startup decides to build one.
Summary
The Forward Deployed Engineer (FDE) is a relatively new role that has grown mainly within AI companies selling to enterprise organizations, sending an engineer on-site with the customer, often for several weeks, to personally handle the integrations and implementation that make the product work inside that organization. Sitting at the intersection of Product, Engineering, and Customer, the role shortens the loop between those three functions but also blurs boundaries that used to be clear. Building an FDE team raises four organizational dilemmas: who to hire, how much autonomy to grant, how to retain the knowledge an FDE accumulates, and who gets credit for expansion revenue an FDE surfaces.
There are stories of companies increasing revenue 5x in a single quarter, and there’s a real sense of promise around the FDE model. At the same time, it’s worth remembering that new roles don’t appear in a vacuum. They create shifts, tensions, and organizational questions that are worth thinking through before falling in love with the idea.
At first, FDE looks like it could be another overhyped title for roles we already had in the pre-AI world: Solution Engineer, Technical Account Manager, Integration Engineer.But speaking with managers who had started hiring for this role, and with companies considering building FDE teams,I realized that this was a deeper shift than the title alone suggests.
The role is not just different in what it does. It gives this function a much broader scope and a very different position within the organization. And perhaps more interestingly, it raises a bigger question: what does the very existence of this role tell us about how the organization itself is changing?
An FDE is a function that sits at the intersection of Product, Engineering, and Customer: an engineer is sent to work on-site with the customer, often for several weeks, and personally handles the connections, integrations, and implementation needed to make the product work within that organization.
Unlike onboarding a SaaS product over Zoom, the FDE is actually there. This allows them to learn how the customer really works, develop a deep understanding of their needs, and tailor the integration much more closely to the organization.
Being on-site also means being part of the informal conversations: the coffee breaks, hallway chats, and everyday interactions where problems often come up that would never make it into a formal meeting. Sometimes these are challenges the customer hasn’t documented, and sometimes ones they haven’t even fully recognized yet.
Instead of every change going through a chain of meetings, documents, and prioritization discussions, there is someone who can understand the problem and move toward a solution almost in real time. This significantly shortens the loop between the customer, Product, and Engineering.
The FDE model was created to bridge a growing gap between the high expectations enterprise organizations have from AI technologies and their actual ability to adopt them.
That gap exists because real adoption of an AI-based product inside a large enterprise creates friction: large organizations already have established workflows supporting entire departments. They have legacy systems, often heavier and more complex by design, built to meet enterprise standards and regulatory requirements. And that’s before accounting for organizational politics.
The FDE was created to help bridge that gap.
The role doesn’t exist in a vacuum. To give FDEs the freedom they need to do what they were hired to do, the organization often needs to change its own ways of working. If a startup is building its revenue forecast around an FDE team, is the startup itself set up to help that team succeed?
Companies hear that FDEs increased revenue 5x in one quarter and naturally think: we want that too. They tend to focus on the big external change: what FDEs can do at the customer interface. But what about the internal change?
Until recently, the boundaries were relatively clear: Product defined, Engineering built, Sales sold. Today, those boundaries are becoming much less clear, because a role that stretches across three, and sometimes four, different functions inevitably challenges some organizational status quo. That shift surfaces four specific dilemmas.
The challenge is that a startup needs someone technically strong enough to deeply understand the product and make meaningful changes, while at the same time being able to sit with a VP at an enterprise organization, read between the lines, set boundaries when needed, and make decisions even when the answer isn’t written in any playbook. In other words, you’re looking for people who are comfortable constantly moving between code, product, people, and business.
Hiring managers I speak with describe this as a hire that is heavily driven by personality and soft skills: the ability to read people and situations, resilience, adaptability, creativity, strong communication, and the ability to get others on board. The open question is how to screen for that on a CV, identify it in an interview, and scale a hiring process that feels this individual and selective.
But how do you screen for that on a CV?
How do you actually identify it in an interview?
And if you want to build an entire FDE team, how do you scale a hiring process that feels so highly selective and individual?
For an FDE to be effective, they need authority that in other companies is spread across Product, Engineering, and Customer Success.
So where do you draw the line?
Can they make commitments on behalf of the company, make decisions independently,
say “no” to a customer, or hange code without Product or Engineering approval?
Where the team sits in the organization, and who it reports to, is also unresolved.
Give an FDE complete freedom, and they can move much faster, drive higher customer satisfaction, and potentially shorten the path to cross-sell. Set clearer boundaries and keep more traditional ownership structures, and the company maintains greater control and consistency, with less risk of spaghetti code or damage to critical product infrastructure. Most companies are still trying to find the right balance.
A strong FDE can accumulate, within a few months, knowledge that no one else in the company has: the customers, the implementations, the objections, the shortcuts, and all the things that never make it into an onboarding document.The question is whether that knowledge stays with one person, or becomes a repeatable organizational capability. If every time an FDE goes on vacation there’s no one who can cover for them, and if every implementation starts from scratch with no way to formalize and replicate what was learned , scaling the model becomes complicated.
When a strong FDE identifies additional needs at the customer, or discovers that other departments want a similar discovery and implementation process, the original deal grows, either through expansion or through additional purchases. Who gets credit for that?
How involved should Sales be at this stage? How does the handoff work? And should we even think of FDE as part of the sales process, or should the FDE remain a trusted advisor?
Maybe there isn’t even one type of FDE?
Perhaps companies will eventually need different FDE profiles, some leaning more commercial, others more toward Engineering and Product.
It’s possible that in a few months we won’t even talk about FDE as a unique role. Maybe we’ll simply expect every engineer to be a little more product-minded, a little more business-minded, and a little closer to the customer, a shift already visible across many roles, with a growing preference for people with broader, more rounded profiles.
Ultimately, the interesting part isn’t whether one specific new role survives the AI revolution.
It’s the broader shift: roles in this new world are challenging the boundaries between teams, changing organizational structures, and forcing startups to rethink how they work.
FAQs
Q: What does a Forward Deployed Engineer (FDE) do?
A: An FDE works on-site with a customer and personally handles the connections, integrations, and implementation needed to make an AI product work inside that organization. The role sits at the intersection of Product, Engineering, and Customer, which lets the FDE understand a problem and move toward a solution in near real time.
Q: Is FDE just a new name for Solution Engineer or Technical Account Manager?
A: Not entirely. FDE shares surface similarities with Solution Engineer, Technical Account Manager, and Integration Engineer roles, but its scope is broader and its position in the organization is different. It spans Product, Engineering, and Customer functions at once and it typically involves working on-site.
Q: Why are AI companies hiring for this role now?
A: The FDE model emerged to bridge a gap between enterprise organizations’ high expectations of AI technology and their actual ability to adopt it. That gap comes from legacy systems, established workflows, regulatory and enterprise standards, and organizational politics that slow real adoption inside large companies.
Q: How much decision-making authority should an FDE have?
A: There’s no settled answer. Granting full autonomy lets the team move faster and potentially shortens the path to cross-sell. Keeping more traditional ownership boundaries gives the company more control and consistency, with less risk to product infrastructure. Most companies building FDE teams are still working out where to draw that line.
Q: Will the FDE role still exist in a few years?
A: It’s uncertain. One plausible path is that the specific title fades as its underlying expectations spread into how engineering roles are defined more broadly, a pattern already visible across other functions.
