Forward Deployed Engineers: What They Are, What They Earn, and Why the Hottest Job in Tech Is 60 Years Old

The hottest job title in tech right now is one your dad might have had in 1975.

Forward Deployed Engineer. FDE if you want to sound like you work at Palantir. Job postings for the role jumped a reported 800% between January and September 2025 according to Indeed's analysis. OpenAI is hiring hundreds of them. Google has them. Anthropic has them. Every agentic AI startup with a Series A and a dream is posting for one, including here in Australia.

And the comp is silly. We'll get to that.

But here's what almost nobody in the breathless LinkedIn commentary is saying: this role is not new. It's not even close to new. It's the oldest go-to-market motion in enterprise technology, wearing a military-sounding name. We just spent 20 years pretending we didn't need it, and AI made us remember that we do.

Let's cover everything. What the role actually is, where it came from, why it's suddenly everywhere, what it pays, how it's different from a sales engineer, and why anyone who sold mainframes is currently laughing into their retirement fund.

What a Forward Deployed Engineer Actually Is

A forward deployed engineer is a proper software engineer who works embedded inside a customer's business. Not visiting. Embedded. They sit with the customer's team, sometimes for weeks or months, learn the guts of the business, and then write real production code to make the vendor's product solve that customer's specific problem.

The key word is engineer. These people pass the same technical interviews as core product engineers. At Palantir, FDEs went through identical coding loops to the software engineering track. They merge code into production. They are not a demo jockey with a nice deck.

A typical FDE engagement looks something like this:

That last point is what separates FDEs from consultants. A consultant's work dies with the engagement. An FDE's work is supposed to compound into the product. Palantir calls their product engineers "Devs" and their forward deployed engineers "Deltas", and the whole model rests on Deltas discovering what to build and Devs generalising it.

One quote from First Round's excellent deep dive on the role nails it. Shilpa Balaji, who led FDE recruiting at Palantir: "You're not just setting up a user interview. You're embedding with them. You're prototyping what you hear one day and showing them something the next day."

Where the Role Came From

Palantir invented the title around the mid-2000s. The name is deliberately military. Forward deployed forces are the ones stationed in theatre, close to the action, rather than back at base. Fitting, given Palantir's early customers were intelligence agencies and defence departments with problems you could not solve from a Palo Alto office.

Palantir's insight was that their product, Gotham and later Foundry, was too powerful and too general to sell the normal way. No procurement team could look at it and know what it would do for them. So Palantir sent engineers into the customer to find out, build it, and prove it. The product roadmap was largely written in the field.

For years the rest of the industry thought this was a Palantir eccentricity. Services-heavy, margin-destroying, impossible to scale. Wall Street hated it. Then Palantir's revenue kept compounding, the stock went vertical, and suddenly everyone wanted a fleet of Deltas.

Why the FDE Role Is Exploding Now

One word. AI.

Modern AI platforms have the exact same problem Palantir's product had 20 years ago: enormous capability, zero obviousness. An LLM can theoretically do almost anything. Which means it does nothing by default. Jake Stauch, CEO of Serval, put it perfectly in that First Round piece: "Software platforms have become so powerful that their capabilities are no longer the rate-limiting step for the customer. But somebody has to steer the product."

Enterprises are being sold agents and copilots and automation platforms. What they actually have is 30 years of legacy systems, undocumented workflows, compliance requirements, and data in a state that would make you cry. The gap between "the model can do it" and "the business gets value from it" is a canyon. FDEs are the bridge.

So the buyers of FDE talent now include:

The logic for the startups is simple. FDEs recreate founder energy at scale. In the early days the CTO hears a customer complaint and fixes it that night. FDEs are a way of buying that loop back after the founders stop doing deployments themselves.

Forward Deployed Engineer Salary: What the Role Pays

Sit down.

Those top numbers are frontier-lab pricing, heavy on equity, and you should discount them accordingly. But even the boring median makes FDE one of the best paid engineering variants going. The premium exists because the intersection of "genuinely strong engineer" and "happy to sit in a client's office in a hi-vis vest asking questions about their supply chain" is a very small pool of humans.

In Australia the market is early but real. Glassdoor lists around 70 open FDE roles nationally, Indeed has a few hundred adjacent postings, and well-funded agentic AI companies are already recruiting FDEs in Sydney with top-of-market base plus equity. Expect local comp to land well above equivalent solutions engineering roles, because these hires are being benchmarked against product engineering, not pre-sales. For context on where technical pre-sales comp currently sits in the region, see our APAC sales compensation guide.

FDE vs Sales Engineer vs Implementation vs Customer Success

This is where most companies (and most job ads) get confused, so let's be blunt about it.

A sales engineer / solutions engineer supports deals. They demo, they scope, they answer security questionnaires, they make the technical sale. They rarely write production code and they disengage at contract signature. Comp is usually base plus variable tied to the deal.

An implementation consultant configures the existing product. Repeatable deployments, playbooks, go-lives. Valuable, but they work within what the product already does.

A customer success manager owns the relationship and the renewal. Not an engineer at all.

An FDE builds things that don't exist yet, inside the customer, and feeds them back into the product. They span pre-sales and post-sales. They might spend weeks winning a deal by hand-rolling a proof of concept on the customer's real data, then months making the deployment sing.

First Round's Head of Talent has a great tell for founders who think they want an FDE but don't: "If a founder says, 'I want this forward deployed engineer to have closed X deals or run X number of demos,' they probably want someone closer to sales, not an FDE."

And the reverse tell for candidates: if the role is really just configuring the product from a playbook, that's an implementation job with a fancier title and it should not command FDE money. Title inflation is already rampant here. Ask what you'd actually be shipping.

Now the Fun Part. None of This Is New.

Anyone who worked in enterprise tech before the cloud is reading all of this with one eyebrow up.

Because in the 1960s and 70s, IBM did not just sell you a mainframe. The machine arrived with people. IBM Systems Engineers were assigned to customer accounts, worked on site, wrote and adapted software, trained staff, and effectively lived inside the customer's business. The hardware, software and engineering came as one bundled price. Buying computing meant buying resident engineers. That was the model. IBM only unbundled software and services from hardware in 1969, and mostly because antitrust pressure forced them to.

It didn't stop there. Through the 80s and 90s, DEC had field service engineers stationed at customer sites. The big ERP wave of the 90s put literal armies of SAP and Oracle engineers inside enterprises for years at a time. Cisco, EMC and the storage vendors had "resident engineers", a vendor employee with a desk in your building, badge and all. If you ran serious on-premise infrastructure, some vendor's engineer knew where your server room's good coffee was.

Why? Same reason as today. The technology was powerful, immature, and general purpose. The gap between what the machine could do and what the business needed was enormous, and the only way to close it was to put an engineer physically next to the problem. On-prem servers made it literal. The product was in your building, so the vendor's people were too.

Then SaaS killed the whole motion. Multi-tenant cloud software meant one codebase for everyone. Customisation became configuration. Configuration became a settings page. The vendor's engineers retreated to head office, the on-site role got downgraded into customer success, and "we don't do services" became a badge of honour because pure software margins looked prettier in the board deck. For a certain generation of SaaS founders, sending engineers into customers was the thing you specifically did not do.

That worked because SaaS products were narrow. A CRM does CRM things. There's not much of a canyon to bridge.

AI broke that assumption. We're back to selling general-purpose capability into messy specific businesses, which is exactly the mainframe-era problem. So the mainframe-era solution came back, with a Palantir name and a frontier-lab pay packet. The pendulum that swung from bundled on-site engineering to self-serve software has swung back.

History doesn't repeat. But in enterprise tech it absolutely rhymes.

Should Your Company Hire One?

Honest answer: probably not, unless a few specific things are true. The First Round panel is worth reading in full here, but the diagnostic distils to three questions.

Are you selling big, hairy enterprise deals? FDE is definitionally an upmarket motion. If your end state is product-led growth and freemium, don't. The unit economics only work when the contract is large enough to carry an engineer's full attention.

Is your product genuinely open-ended? If you have a strong, fixed opinion about what your product should be, you don't need FDEs, you need customer discovery. FDEs are for products that can shapeshift, where the roadmap is legitimately discovered in the field.

Is your customer base heterogeneous? If every customer looks the same, systematise the deployment instead. FDEs earn their cost when every account is a different problem.

And even then, don't send them everywhere. Ironclad learnt to reserve their version of FDEs for the highest-value customers and run cookie-cutter implementations downmarket. Sprinkle the expensive humans on the deals that deserve them.

What to Look For If You Do Hire One

The profile is unusual, which is exactly why it's expensive. The consistent traits from people who've built these teams:

Interview for open-ended problem solving, not just algorithms. Palantir's FDE interviews posed real customer problems: here's insider trading, design a system to detect it, what data do you need, what would you ask the customer. The engineers who light up at that prompt are your people. The ones who ask for a ticket with acceptance criteria are not.

What This Means for ANZ Sales and GTM Teams

Three things worth acting on.

Your solutions engineers just got a new competitor for talent. The best SEs, the ones who can actually code, are precisely the pool FDE roles recruit from, and FDE comp is set against product engineering. If you employ strong technical pre-sales people and haven't reviewed their package this year, someone else is about to do it for you.

Watch the title inflation. We're already seeing "forward deployed engineer" ads in Australia that are implementation or support roles wearing a hype title. If you're hiring, don't slap FDE on a config job, you'll pay a premium and churn the hire. If you're a candidate, ask one question: will I merge code into the production product? That's the whole test.

The buyers of AI need this muscle too. The FDE conversation is framed around vendors, but the same logic says enterprises adopting AI need embedded engineers who understand the business, not just an innovation team producing decks. The organisations getting real value from AI in 2026 have people playing the FDE role internally, whatever they call them.

The forward deployed engineer isn't a new job. It's the return of the oldest truth in enterprise technology: powerful, general-purpose technology doesn't sell itself and doesn't deploy itself. Somebody has to sit next to the problem.

IBM knew that in 1965. Palantir bet a company on it in 2005. The AI industry just spent billions rediscovering it.

Hire Technical GTM Talent That Actually Ships

The line between engineering and go-to-market is blurring fast, and the companies winning enterprise deals in ANZ are the ones staffing that boundary properly. Whether you need a sales engineer who can survive a technical evaluation, a commercially sharp customer success hire, or help thinking through how an FDE-shaped role fits your team, Pointer's recruiters have carried quotas and built these functions themselves.

We vet for the things a CV can't show, and our pay-as-they-perform model means you're not betting $25K upfront on a hybrid role that's hard to get right.

Book a Discovery Call