Where Does the FDE Role Belong?
Finding the Right Home for the FDE (Forward Deployed Engineers) Team
Hey, Prasad here 👋 I’m the voice behind the weekly newsletter “Big Tech Careers.”
This week I bring you another guest post from Jove Zhong, Head of FDE @ Cresta! In this article, he shares his insights on where the FDE (Forward Deployed Engineering) teams should be placed in an organization.
If you are looking to get hired as an AI FDE, check his last week’s article - Breaking Into AI FDE roles Through a Hiring Manager’s Lens.
If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.
Over to you, Jove!
The $10 Million Question
Your company is building AI products. Customers need help deploying them. You’re hiring Forward-Deployed Engineers. (Check my blog to learn more about the FDE role)
One question will shape everything that follows: Where do they report?
Engineering? (Build better products)
Sales/GTM? (Close more deals)
Customer Success/Professional Services? (Keep customers happy)
The answer isn’t obvious. And it matters more than you think.
The Three Models (And Why Two Are Wrong)
Model 1: FDE in Sales/GTM
The Logic: FDEs help close deals. They do demos. They’re customer-facing. Put them in sales.
The Reality: This creates the wrong incentives.
In the first episode of Forward Deployed Caffeine podcast, Milos from Leverage asked me “If you look at some decisions... would any of these decisions be different if you were a part of sales organization?”
I am not good at answering hypothetical questions. I am not a big fan of having FDEs report into the sales org, otherwise:
Success = closed deals, not necessarily high-quality, successful deployments
Incentive = say “yes” to everything to close the deal
Focus = new logos over making existing customers successful
Career path = sales engineer, not technical leadership
For early-stage companies (<20 people) where everyone wears multiple hats anyway, maybe this can work. Or companies selling simple products that don’t require deep customization.
Model 2: FDE in Customer Success or Professional Services
The Logic: FDEs make Customers Successful. That’s literally CS’s job. Perfect fit.
The Reality: FDEs become glorified support engineers.
The problems:
FDEs could be charged by hours/days if they are part of Professional Services, then FDEs may not want to build automation to improve their productivity, and customers may want to keep the conversations/collaborations with FDEs as short as possible to save money.
Engineering team sees FDEs as “not real engineers”
FDE cannot take the learnings and update the product code. No direct line to product roadmap decisions. Feature requests go through multiple layers
FDE builds the AI agent, not just configure in the web console, edit yaml file, or push the deploy button. There is a lot of engineering effort and expertise for prompt engineering, context engineering, model tuning, test/evaluation, mocking, security hardening.
In the second episode of Forward Deployed Caffeine podcast, as Anthony, one of the founding FDE at Cresta, puts it: “We act as that bridge between the customer and our product team and those standard software engineers.”
That bridge is structural, not just metaphorical. If FDEs sit in CS/PS, the bridge collapses.
Who this works for: Companies with simple products where “deployment” means configuration, not code. Or mature products where most work is troubleshooting existing features.
Model 3: FDE in Engineering ✓
The Logic: FDEs write code. They build products. They’re engineers.
The Reality: This is where the magic happens.
Why did Cresta choose engineering? As I keep saying in my podcast/blog/LinkedIn: “FDE stands for engineer, right? So we write a lot of code. I don’t really write many slides. Most of the time, all my team members, we write the code, we write the prompt, we refine the test framework, and we wire things together.”
Why Engineering Org Is the Right Answer (For AI)
Reason 1: You’re Part of the Product
In AI, the line between “platform” and “deployment” is blurry.
At least for Cresta, our current AI agent platform is primarily designed for FDEs (maybe FDPM and Sales Engineers) so that we can deliver in a high-quality, efficient, and time-sensitive way. There are too many myths, black magic, and surprises in AI, and most customers cannot handle this by themselves.
Think about what an FDE actually does:
Writes production code
Designs prompts (which are code in AI systems)
Builds test frameworks
Integrates with APIs
Handles edge cases
Ensures security and compliance
This isn’t just a configuration. This is software engineering.
Reason 2: Direct Feedback Loop to Product
Anthony describes the workflow: “When I’m telling the customer, let me go talk to our platform team and get back to you. And then we come back to them and we’re going to build this for you. We’re going to prioritize this for you.”
This only works when:
FDEs have technical credibility with platform engineers
FDE input carries weight in roadmap decisions
The communication path is short (not through multiple managers)
I’m explicit about this: The company’s direction for AI is driven by these FDEs. We’re the ones who interact with these customers every day, understand what their wishes are, what things we want to bring back to the platform.
Reason 3: The Iterative Development Cycle
Traditional SaaS: Build → Ship → Support → Learn → Build
AI deployment: Build → Deploy → Learn → Fix → Test → Deploy → Learn (repeat daily)
Milos shares an example: “Initially building a solution on top of our platform that was suiting the needs of the customer took 12 weeks. Then based on that solution, we figured out what were the biggest sort of components that the platform is missing... that allowed us to get to the next customer and build the same solution in eight weeks and then the third customer in about six weeks.”
This rapid improvement cycle only works when FDEs can:
Push code to the platform
Propose architectural changes
Participate in technical design reviews
Have peer relationships with platform engineers
Reason 4: Career Path and Hiring
If you want to hire strong engineers, they need to see a technical career path.
FDEs at AI agent companies like ours are almost like the new McKinsey. In the past, people sent a bunch of money to let those people from McKinsey come to your office... Now, because we are building agents for those airline companies, for healthcare, for those FinTech companies... we need to build a working solution.
But here’s the key difference from consultants: FDEs are building technical platforms, not PowerPoint decks.
The engineers you want to hire care about:
Technical growth
Learning from senior engineers
Working on hard problems
Building real systems
Anthony explains why he joined: “I was really looking to learn from more experienced developers, to get in a space where it’s more fast moving, where we’ve got a lot of people with great experience, great engineers.”
If FDE reports to sales, you’ll get sales engineers. If you want actual engineers, put them in engineering.
The Structure at Cresta: A Case Study
Here’s how it actually works at Cresta:
I am the Head of FDE, reporting to VP of Engineering
VP of Engineering reports to CEO
Today, there are 15 FDEs report to me. There will be 20 to 40 more FDEs to hire this year and I am hiring FDE managers too.
The FDE team and I work closely with Platform engineering teams, ML/AI research teams, Infrastructure teams
As an engineering lead, I join product roadmap prioritization and weekly/monthly check-ins.
Collaboration:
FDPMs (Forward-Deployed Product Managers) work with FDEs
Solution engineers help with pre-sales
CSMs handle ongoing relationships
I’m not just a FDE manager. I also contribute individually, but I don’t spend as much time as my engineers. But I observe and I try to see whether there’s any room you can improve in the process. So I would say it’s 50/50, half IC, half manager/leader.
The Counter-Argument: “But Sales Needs Them!”
Fair point. FDEs do help close deals. Anthony describes his impact: “By nature, our product is exposed to thousands of callers, thousands of customers. And so we need to build resilient AI agents, resilient prompts that are ready to handle any scenario.”
Customers see this value. They buy because of it.
But here’s the thing: FDEs help sales as a side effect of doing good engineering work.
The value chain:
FDE builds great deployment for Customer A
Learns lessons, feeds back to platform
Platform gets better
Next deployment is faster/better
Sales can show better demos, faster time-to-value
More deals close
If FDEs report to sales, you optimize for step 5 at the expense of steps 1-4.
The AI-Specific Factor: Why This Matters More for AI
Traditional software has clear boundaries:
Platform team: builds the product
Sales engineers: demo the product
Implementation consultants: deploy the product
Support engineers: fix the product
AI breaks all these boundaries.
Anthony explains: “We work on client-specific implementation. So instead of going for generalization, we’re going for specificity. We’re identifying patterns among those client deployments that we can then bring back to the platform and reuse in a meaningful way.”
Every deployment is:
Partially custom code
Partially platform features
Partially prompt engineering
Partially test framework
Partially integration work
You can’t hand this off between teams. It has to be one person who can do it all.
And that person needs to be an engineer.
The Practical Test: Ask These Questions
Still not sure where FDEs should sit? Ask:
Can FDEs submit PRs to the core platform?
Yes → probably engineering
No → definitely not engineering (and that’s a problem)
Do FDEs participate in platform architecture reviews?
Yes → engineering
No → they’re isolated (bad sign)
When FDEs find a platform bug, what happens?
File ticket → sales/CS org
Fix it themselves or work directly with platform team → engineering org
How is FDE success measured?
Deals closed → sales org
Customer health scores → CS org
Platform improvements and customer success → engineering org
What’s the career path for senior FDEs?
Account executive → sales org
CSM manager → CS org
Staff engineer or engineering manager → engineering org
The Bottom Line
If you’re building AI products, your FDEs should report to engineering.
Not because of ideology or title prestige, but because the job requires:
Writing production code
Deep technical expertise
Direct influence on product roadmap
Peer relationships with platform engineers
A culture of iterating and improving
As Milos puts it: “FDE is the person in the middle to wire things together. But we are not really part of the pre-sales or go-to-market because we are part of the product.”
The product. Not product marketing. Not product success. The actual product.
The Future: Will This Change?
As AI products mature, will we need FDEs at all?
Anthony shares the vision: “Something that is really important to an FDE role is that I’m always trying to make my job easier and make my job faster so I can take on more customers.”
The goal is self-service. Eventually.
But I’m realistic: In the near term, it is FDEs who make sure we can quickly build something enterprise-grade with all the security, with all the performance, business logic.
The near term might be 5 to 10 years. Maybe longer.
Until then, put your FDEs in engineering. They’ll thank you. Your platform engineers will thank you. And most importantly, your customers will thank you.
Because they’ll actually get working AI systems, not just promising demos.
I would like to extend a big thank you to Jove for sharing his insights with Big Tech Careers readers.
Want to discuss FDE org structures? You can call (888) 390-9595 to ask questions to the virtual version of Jove
I would also encourage you to subscribe to his Forward-Deployed Caffeine podcast for more conversations about FDE roles, career paths, and the future of AI deployment.
Big Tech Interview Preparation Course
While I share everything for free here in this newsletter, if you need all the material in a structured course format with a deep dive into preparation methodology for behavioral interviews, I have a self-paced course for you.
 | A guest post by
|