Why FDE is the Fastest-Growing Job in AI Enterprise Software
Why FDE is the Fastest-Growing Job in Enterprise Software
Forward Deployed Engineers are growing 1,000%+ year-over-year. Here’s what they actually do, why Customer Success can’t replace them, and what the hiring explosion tells you about where enterprise AI
Last week I wrote about Palantir’s Forward Deployed Engineering model — why it worked, what made it structurally different, and why so many companies trying to imitate it are doing it wrong. The engagement from the readers made me understand I should probably write more about it.
So, in this article I’m approaching: what FDEs actually own, why the role exists, how it’s being structured inside SaaS companies today, and what the numbers say about where enterprise software is heading. At the end, I also approach what this means for people building consulting practices outside of these companies.
FDE job postings grew 12x in twelve months
ICONIQ Capital’s 2025 State of Software report — drawing on 127 software companies — found that monthly FDE job postings went from around 30 in early 2024 to 375 by April 2025, a 12x increase in roughly twelve months. An independent analysis by Bloomberry of 1,000 FDE job postings put the year-over-year growth figure at 1,165%.
An analysis by Indeed cited by the Financial Times tracked growth at over 800% between January and September 2025 alone.
They all agree in one thing: FDE is the fastest-growing job in enterprise software.
The companies driving this growth are not niche players. Salesforce has committed to building a team of 1,000 FDEs. OpenAI, Anthropic, Cohere, Datadog, Ramp, and Intercom are all actively building FDE functions. These are deliberate organizational investments, not experimental hiring.
On compensation: the salary data is heavily US-centric, and needs to be read that way. Based on the Bloomberry analysis of 1,000 US job postings, the median base salary sits at $173,816. At Palantir specifically, total compensation averages $238,000, with a range of $205,000 to $486,000 and staff-level engineers clearing $630,000+. 70% of FDE roles include equity, and exactly zero percent carry a quota — these are compensated as engineering roles, not as sales roles.
For Europe and APAC, the data is thinner. The role is growing in both regions — in many conversations with practitioners and hiring managers across European markets, the intent to recruit this profile is clear — but structured public compensation data doesn’t yet exist at the same scale. What’s available suggests a wide range: European FDE salaries are reported in the €70,000-€100,000 band for most markets, with Germany and the Netherlands on the higher end, and London in the £65,000-£110,000 range for AI-focused roles. APAC is similarly data-sparse, with Sydney and Singapore emerging as hubs for enterprise deployments in financial services, government, and logistics. These figures should be treated as directional, not definitive — the market is moving too quickly for the data to stabilize.
The compensation structure matters less than what it reveals. FDEs earn 25–40% more than traditional software engineers at equivalent levels. That premium reflects one thing: the combination of production-grade engineering capability and the ability to operate inside complex customer environments simultaneously is rare and hard to hire for. Companies are paying to close that gap because these profiles are helping them to reduce customer churn and by ensuring product adoption.
If you are a new reader, my name is Diogo Santos. I write about how you can build and scale a sucessfull Consulting Business that outcompete the Big Consulting Firms.
Please consider subscribing to my weekly newsletter if you haven’t already. Reach out on LinkedIn if you ever want to connect or propose ideas for new articles
FDEs carry a scope no single role held before
The role is usually described as “ embedded engineers” or “ customer-facing technical experts”, terms that don’t clarify how broad the mandate of the role actually is. An FDE is involved in functions that most organizations split across multiple distinct roles.
PRE-SALES TECHNICAL SCOPING
Before a contract is signed, the FDE is already working. They’re in discovery calls, mapping the customer’s existing stack, identifying integration points, and producing a realistic deployment architecture. Sales can close the deal. The FDE determines whether the deal is closeable at the stated scope and timeline. This is where the role starts earning value by preventing the company from signing contracts it can’t deliver.
DEPLOYMENT ARCHITECTURE
Once the contract exists, the FDE owns the technical design of how the product fits into the customer’s environment. This involves real engineering decisions: data pipelines, authentication flows, legacy system interfaces, rollout sequencing across business units. The environment they’re walking into is almost never what the product was designed for. It’s older, messier, and has accumulated a decade of undocumented workarounds.
CLIENT-SPECIFIC CONFIGURATION AND CUSTOM DEVELOPMENT
FDEs write production code. This is the sharpest dividing line between the role and anything that came before it. They’re not adjusting settings in a UI. They’re building custom connectors, writing integrations against undocumented internal APIs, and creating workflow automation that fills the gap between what the product does and what the customer’s operation actually requires. Reducto’s job description puts it plainly: “ Work within customer systems to build production applications. “
WORKFLOW REDESIGN
The harder part of deployment is rarely technical. A product that replaces a broken manual process doesn’t succeed by dropping into the same sequence that was already failing. FDEs often end up redesigning the operational flow around the product — which means working directly with the people whose jobs are changing, not just the IT team that owns the integration. This requires a kind of presence and organizational credibility that no purely technical role can carry.
TRAINING AND ADOPTION ENGINEERING
Getting users to use the product is its own discipline. FDEs design the training architecture, run initial sessions, and track usage patterns to identify where adoption breaks down. The FDE stays accountable for whether the product is working in practice, not just in the deployment diagram.
FEEDBACK LOOP TO CENTRAL PRODUCT TEAM
Every FDE engagement is a live R&D operation. The edge cases, integration failures, undocumented requirements, and workflow gaps that surface in a real deployment are the most valuable product intelligence a company can collect. FDEs who do this right are feeding structured insights back to product teams continuously, shaping the roadmap based on what actually happens when the product meets the real world.
RENEWAL DEFENSE
By the time a renewal conversation arrives, the FDE has often been the primary technical relationship for twelve months. They know what worked, what didn’t, and what the customer actually needed versus what they thought they needed at signing. They’re not defending a contract. They’re in a position to propose an expansion grounded in demonstrated value.
One person rarely executes all of this equally well. In practice, when two FDEs are assigned to a strategic account, they distribute. One tends to carry more of the engineering weight — architecture decisions, integration code, production deployment. The other tends to carry more of the organizational weight — workflow redesign, stakeholder alignment, training design, renewal conversations. Both can touch every function; the distribution reflects where each person’s depth actually lies. The mandate is singular. The execution is collaborative.
Why Customer Success Fails at This Job
Customer Success was built for a legitimate problem. Once SaaS companies realized that revenue was earned through retention and expansion, not just acquisition, CS became the function that owned the post-sale relationship. In a well-run CS organization, this means managing onboarding, driving adoption, tracking health metrics, coordinating escalations, running regular business reviews, and building the kind of executive relationship that survives turnover on the customer side. That is genuinely complex work, and companies that underinvest in it see it in their churn rates.
The structural limitation is not that CS managers aren’t capable. It’s that the function it’s note designed to carry a technical mandate of the depth that complex AI deployments require. CS is architected around relationship management, structured check-ins, escalation routing, and success planning. When a deployment requires custom code, the CS model escalates — to professional services, to engineering, to a solutions architect — and introduces handoff costs that compound at every stage. The customer re-explains context. The new person re-maps the environment. The momentum breaks.
For products that are relatively contained, where deployment means configuration and adoption means habit formation, the CS model holds. Enterprise AI products break that assumption. They require read/write access to systems companies are protective of. They need context that can’t be configured through a setup wizard. They often require eliminating workflows that have been running for years, which means navigating organizational politics, not just technical integration.
The FDE removes the handoff. One person carries the technical mandate from pre-sales through renewal. The context that would otherwise be lost across four transitions stays in a single head, and the relationship has the depth that comes from having built something together rather than inherited a ticket queue.
How FDE Teams Are Actually Structured
The role is young enough that organizational structures vary significantly. But patterns have emerged.
Reporting lines. The most important structural decision is where FDEs sit. Around 45% of companies have built FDE as a dedicated team outside of sales and customer success. Around 38% keep FDEs inside the engineering organization. Both configurations are defensible. Placing them in sales generally isn’t.
The case for engineering runs deeper than incentive alignment, though that matters too. FDEs who report to engineering are expected to participate in product feedback loops — surfacing deployment patterns, edge cases, and workflow gaps to product managers, attending product reviews, and contributing to backlog prioritization, even if with less intensity than core software engineers. They’re part of the product intelligence system. That relationship requires organizational proximity. An FDE who reports to sales will optimize for pipeline metrics, because that’s what their manager measures. An FDE who reports to engineering optimizes for whether the product works, which is the right optimization.
The person running an FDE team carries a correspondingly hybrid profile. Managing FDEs requires understanding the engineering craft, but also the organizational dynamics of customer environments. The fact that FDE work is structurally less stable than product development, that relationships with customers shift and require constant recalibration, and that the value of the role can’t be measured by the same metrics applied to engineers who ship features on a roadmap needs to be considered. The best FDE team leads tend to have backgrounds that span engineering, consulting/transformation, and product — people who’ve built things, sold things, and lived inside messy client environments. That combination is as hard to find in management as it is in the individual contributors.
Team models. At growth-stage companies, the most common structure is a pod: one FDE per strategic account, or a small team of FDE plus product manager plus data engineer, focused entirely on one client for three to twelve months. Salesforce runs pods focused on a single client for roughly three months per use case deployment. Palantir expects FDEs to spend around 25% of their time onsite, companies in more operationally intensive sectors push that toward 50%.
Tiers by client size. Most companies with mature FDE functions tier their deployment by account size and complexity. The largest, most complex accounts get dedicated FDE coverage. Mid-market accounts get shared coverage with defined engagement windows. Smaller accounts get productized onboarding without FDE involvement. The mistake is assigning FDE coverage based on which customers complain loudest rather than which accounts represent the highest expansion and retention value.
Product team interaction. The FDE-to-product feedback loop is the most structurally underdeveloped part of most FDE functions. Companies that get this right build formal mechanisms: structured insight capture after each deployment milestone, recurring syncs between field engineers and product managers, and a shared system for distinguishing between two things, the gaps that are unique to one customer’s setup, and the gaps that reveal a recurring flaw in the product itself. Companies that don’t build this end up with FDEs solving the same problem twelve times at twelve different customers, which is expensive and opaque to the people who could fix it.
The FDE model reflects where enterprise AI actually is right now: past the hype phase, deep into the harder problem of making it work inside real organizations. The products exist. The use cases are validated. The budgets are moving. What’s failing is the last mile — the translation from “ this product can do this” to “ this product is doing this, reliably, inside your operation. “
That last mile a hybrid problem that requires engineering depth, domain fluency, and the organizational credibility to drive change inside a customer environment without formal authority. The companies that understood this earliest are building the largest FDE organizations. The companies that haven’t are watching pilots succeed in controlled conditions and fail at scale, which remains the dominant outcome for enterprise AI deployments.
What This Tells You About Enterprise AI
The FDE role is not transitional. Products will get easier to deploy. Customer environments will not. As long as enterprises run on fragmented legacy stacks, operating with decades of accumulated workflow complexity and asking AI products to integrate into systems they were never designed for — which is every enterprise, indefinitely — there will be a mandate for people who can live in that gap.
The role pays like engineering because it requires engineering. It’s structured like a field operation because the problem lives in the field. And it exists because the alternative — handing deployment to a function not built to carry the technical weight — has failed at too large a scale for the industry to keep pretending otherwise.
Originally published at https://aiverticaladvantage.substack.com.
Why FDE is the Fastest-Growing Job in AI Enterprise Software was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
