LinkedIn has decided that “Forward Deployed Engineer” is the hottest job title of the AI boom. Startups are hiring for it. Recruiters are DMing about it. Someone is already writing about “Forward Deployed Executives” as the next rung on the ladder. If you’ve spent any time in enterprise software, sales engineering, or IT consulting, none of this should feel new. It isn’t.
That doesn’t mean the role is fake or the demand isn’t real. It means the industry has relabeled a job that’s existed since at least the 1990s and is now selling it back to engineers as a novel career path. Worth understanding what’s actually different, and what’s just repackaging.
What is a Forward Deployed Engineer, actually?#
A Forward Deployed Engineer, or FDE, is an engineer who works directly inside a customer’s environment to customize, implement, and often help sell a piece of software. Palantir popularized the title and the model. Their engineers didn’t sit in a building writing generic product code. They flew to a customer site, sat with analysts and operators, learned the customer’s specific workflow, and wrote the integration and configuration code needed to make Palantir’s platform actually solve that customer’s problem.
The job blends three things that are usually separate roles: software engineering, solutions consulting, and pre-sales. You write code, but you also scope requirements, manage stakeholder expectations, and frequently participate in the sales cycle by proving the product can do what the sales deck promised.
A wave of AI startups has adopted this model wholesale. If you look at the job postings, you’ll see language about “embedding with customers,” “rapid prototyping in production environments,” and “owning the customer outcome.” That’s FDE branding, and it’s spreading fast through applied AI companies that sell complex, unproven products to enterprises that don’t trust self-serve SaaS to solve their problems.
This job title is not new#
Here’s the part nobody wants to say out loud: solutions architects have done this job for decades. So have sales engineers. So have implementation consultants at firms like Accenture, Deloitte, and every systems integrator that’s ever sold enterprise software.
Anyone who’s carried the title “Solutions Architect” at AWS , Cisco, or Oracle has done FDE work. You get embedded with a customer. You learn their environment. You build a proof of concept that has to survive contact with their actual infrastructure, not a sanitized demo environment. You manage the tension between what sales promised and what engineering can deliver. You sit in rooms with executives who don’t know the difference between a container and a VM but need to be convinced the solution won’t blow up their compliance posture.
Sales engineers have done this job. Implementation consultants at every ERP and CRM vendor since the 1990s have done this job. The title changes. The mechanics of the job, remarkably, do not: technical depth plus relationship management plus the ability to translate between engineering reality and business expectation.
What’s genuinely different this time is the product category. AI systems, especially agentic and LLM-based ones, are harder to demo convincingly and harder to trust out of the box than a traditional SaaS platform. That’s the actual novelty. The role wrapped around it isn’t novel at all.
Why AI startups are reviving this model now#
Self-serve SaaS works when the product is predictable and the customer can evaluate it without much hand-holding. You sign up, you plug in your data, it does the thing. AI products, particularly ones built on LLMs, don’t behave that way yet. They’re probabilistic, they fail in unpredictable ways, and enterprise buyers know it. Nobody at a bank or a hospital system is going to sign a seven-figure contract based on a self-serve trial and a sales deck.
So AI startups need people who can go on-site, understand the customer’s actual data and workflows, and build something that works well enough to earn trust before the broader platform matures. That’s expensive. It doesn’t scale the way SaaS is supposed to scale. But it’s the only way to sell a product that isn’t fully baked yet to a risk-averse enterprise buyer.
This is exactly the problem solutions architects and implementation consultants have solved for every immature or highly configurable enterprise product going back to client-server ERP rollouts. AI just happens to be the current category where the product-market fit gap is widest, so the FDE model is having a moment.
The tension between building and selling#
Here’s where a lot of engineers considering this path get it wrong. They read “Forward Deployed Engineer” and hear “I get to write code at the customer site instead of in an office.” What they don’t hear, because job postings rarely say it plainly, is how much of the job is scoping, negotiating, and managing expectations before you ever open an editor.
You’ll spend real time figuring out what the customer actually needs versus what they say they need, which are frequently different things. You’ll sit through stakeholder meetings where half the room doesn’t understand the technology and the other half is worried about their own job security if the project succeeds. You’ll have to say no to feature requests that would blow the timeline, and you’ll have to do it in a way that doesn’t torch the account.
Engineers who come up through pure engineering tracks often underestimate this. They assume the hard part is the technical build. In practice, the hard part is usually the ambiguity: an undocumented legacy system, a stakeholder who won’t commit to requirements, a sales team that oversold the timeline. The coding is frequently the easy part once you’ve actually pinned down what needs to be built.
If you can’t sit in a room with a skeptical VP of Operations and calmly explain why the six-week estimate is actually twelve weeks, the FDE role is going to grind you down regardless of how good your code is.
Forward Deployed Executive: real evolution or resume inflation?#
Some recent commentary has floated “Forward Deployed Executive” as the natural next step for FDEs, the idea being that engineers who’ve proven they can manage enterprise relationships eventually graduate into a quasi-executive role overseeing multiple accounts or a whole practice.
Treat this skeptically. Strip away the title and what you’re describing is an engagement manager, a practice lead, or a client partner, roles that have existed at every consulting firm for as long as consulting firms have existed. Calling it “Forward Deployed Executive” doesn’t describe new responsibilities. It borrows the credibility of the FDE brand and slaps “executive” on it for a resume that needs to sound more senior than “consulting manager.”
That’s not to say the underlying career progression isn’t real. Engineers who are good at both the technical and relationship sides of FDE work absolutely do move into leadership roles managing bigger accounts or bigger teams. That trajectory has always existed in consulting and pre-sales. The new label doesn’t change the substance of the job. It changes how it reads on LinkedIn.
What to actually build if you’re considering this path#
If the FDE role appeals to you, the skills that matter aren’t primarily technical, even though the job postings lead with tech stack requirements.
Build your ability to scope ambiguous problems. Practice taking a vague customer complaint and turning it into a concrete, testable requirement. This is a learnable skill, and it’s the one that separates engineers who thrive in customer-facing technical roles from ones who burn out in them.
Build domain expertise in whatever vertical you’re targeting. An FDE who understands how claims processing actually works at an insurance company is worth more than one who only knows the AI stack. The technology is usually the easy half of the job. The domain is where trust gets built.
Build communication skills specifically around setting expectations with non-technical stakeholders. You need to be able to say “that’s not possible in the timeline you want” without sounding like you’re making excuses, and you need to be able to do it in a room with executives watching.
Expect travel. Expect blurred hours, because customer emergencies don’t respect your calendar. Expect office politics that have nothing to do with the technology and everything to do with who gets credit internally at the customer if the project succeeds.
Watch for red flags in job postings. If a listing is heavy on buzzwords like “embedding with customers to unlock transformative outcomes” and light on specifics about team structure, reporting lines, or what “success” is measured against, that’s a company that hasn’t figured out what it actually wants from the role. A well-defined FDE posting tells you the product, the customer segment, the technical stack, and roughly what a typical engagement looks like. A vague one is asking you to define the job while you do it, which might be fine if you’re senior enough to want that, but it’s a real cost if you’re expecting a structured onboarding.
Compensation and where it actually leads#
FDE roles at well-funded AI startups tend to pay well, often blending a base salary with equity that assumes the company’s growth trajectory holds. That’s the same bet every early-stage hire makes, and the FDE title doesn’t change the risk profile of startup equity.
The more useful question is where the role leads. For some engineers, FDE work is a stepping stone toward founder or executive tracks, because the job forces you to develop the customer-facing and business judgment skills that pure engineering roles don’t. That’s a real and legitimate path, and it mirrors how plenty of solutions architects and sales engineers eventually moved into VP of Customer Success or even CTO roles at smaller companies.
For others, it becomes a specialized track that’s hard to exit from. If you spend five years doing nothing but customer implementations, you may find your hands-on engineering skills atrophy relative to peers who stayed in core product development. Hiring managers at product-focused companies sometimes view heavy FDE experience as “not a real engineer” even when the technical bar for the work was plenty high. That bias is unfair, but it exists, and you should factor it in before committing years to the track.
The honest answer is that FDE work can go either direction depending on the company, the engagements you get assigned, and how deliberately you manage your own skill development alongside the client work. Nobody is going to manage that for you. It’s on you to keep building things outside the customer engagements so your technical skills don’t quietly erode.
So is this a real role or just consulting with a new coat of paint?#
Both. The work is real, valuable, and hard. Companies genuinely need people who can bridge the gap between an immature AI product and a skeptical enterprise buyer, and that person needs both engineering chops and consulting instincts. That’s not marketing fluff, it’s an actual operational need.
But the title itself isn’t a new category of work. It’s solutions architecture and implementation consulting, rebranded for a hiring market that wants to sound more technical and more startup-native than “consultant” or “sales engineer” ever did. If you’ve done pre-sales engineering, technical account management, or systems integration work, you already have the core skill set. Don’t let a shinier job title convince you that you’re starting from zero, and don’t let it convince you the job is purely technical either. It never was, under any name.
Featured image by Fabian Centeno on Unsplash
Recommended Reading#
- AWS Certified Solutions Architect Study Guide: Associate SAA-C03 Exam, 4th Edition by Ben Piper & David Clinton
- AWS Certified Cloud Practitioner Study Guide: CLF-C01 Exam by Ben Piper & David Clinton
- CCNP Enterprise Certification Study Guide: 350-401 ENCOR by Ben Piper & David Clinton