What Forward Deployed Engineers Actually Do

Every few years, tech invents a new job title that makes people in their 40s squint at the job description and think: I've been doing this for fifteen years. It just had a different name.

Forward Deployed Engineer — FDE — is the current candidate for that experience. It's showing up in job postings at AI startups and enterprise software companies with enough frequency that it's crossed from niche to buzzy. And if you've spent any time in tech, you've probably watched enough buzzy roles calcify into something unremarkable, or vanish entirely, to have earned some skepticism.

So what's actually here, and what's noise? Kevin Bai — who built the FDE function at Rippling after years at Palantir — sat down with Exponent recently to explain the role from the inside. His account is worth taking seriously. It's also worth reading critically.

---

What FDE Actually Is (and Isn't)

Bai's clearest contribution to the conversation is a taxonomy of what FDE is not. It is not sales engineering, which ends when the deal closes. It's not a developer on the front lines building scalable product. It's not consulting, even though it borrows from consulting's playbook. The end output of an FDE engagement, Bai insists, is software — not a slide deck, not a recommendation, not a roadmap. Code that runs, delivered to a specific customer, solving a specific problem.

The role, as he describes it, wears three hats: consultant, product manager, and software engineer. The consultant hat goes on first — your job in any new engagement is to listen until you understand the real problem, which is almost never the problem the customer leads with. Bai demonstrated this with a quick live example in the Exponent conversation. A customer complains about dashboard latency. An FDE's job isn't to make the dashboard faster — it's to ask why the latency matters. In the example, the answer turned out to be conversion rates on a sales page. The actual goal was revenue, not load time. Latency was the symptom. Revenue was the problem worth solving.

That reframe is the consultant hat. Then the PM hat: once a customer starts listing problems, they don't stop, so you have to prioritize ruthlessly. Bai's heuristic is highest customer impact against lowest lift for your team, within a realistic time window. "I know for a fact that you're going to hate the first version and then we're going to have to iterate," he said — which means your job is to scope down until you can ship something imperfect quickly, not to build the best possible thing in the time available. The engineer hat comes last, and it comes with a specific requirement: completeness, not just quality. Your customer will never read your code. What they'll notice is whether it works, whether they understand how to use it, and whether it moved the business outcome they hired you to move.

That's the job. Whether it's new is a separate question.

---

Where FDE Makes Sense (and Where It Doesn't)

Bai is refreshingly blunt about this: not every company needs an FDE function, and chasing the model because it's fashionable or investor-friendly is, in his word, "dumb." The specific condition that creates demand for FDE is a technically complex product being sold to buyers who aren't technical. If both sides of that equation are sophisticated — say, a developer tool sold to CTOs — you don't need FDE. If your product is simple and so are your buyers, you don't need it either. The gap that FDE fills is precisely the one between hard software and non-technical decision-makers: manufacturing companies trying to use AI platforms they can't internally support, or financial institutions buying enterprise tools their teams can't configure.

Agentic AI, Bai argues, has widened that gap considerably. The more powerful AI tooling becomes, the more complex it is to implement — which means the more customers need someone who can translate between what the software can do and what the business actually needs. That's a reasonable structural argument, not just hype.

---

Who Should Actually Want This Job

Here's where things get worth scrutinizing.

Bai's ideal candidate is a former or future founder. The logic is sound on its face: founders are used to ambiguity, to building before they know what they're building, to talking to customers and then coding what they asked for. FDE work, he says, has the same shape as early design partnership work. That tracks.

But "founder energy" as a hiring signal has a real pattern attached to it — one that tends to favor a specific demographic and penalize people who built the same skills through different paths. If you spent fifteen years as a senior engineer who happened to run client relationships, or as a PM who could always get into the code when the team needed it, or as a consultant who ended every engagement by actually shipping something — you might have every competency Bai describes, and still get filtered out before the first call because you don't carry the founder narrative. That's a real tension in how this role gets hired, and it's worth naming even if Bai isn't wrong about what the work itself requires.

What he's actually describing — and what he eventually lands on — is someone who is "really excited to do three jobs in one." Not excited about the title. Not chasing the hot thing. Excited about the specific combination of showing up to a customer conversation without a script, figuring out what they actually need, committing to a scope smaller than anyone would prefer, building it, and owning the outcome. Bai is direct that this means three times the failure surface of a single-discipline role. You can fail as a listener, as a prioritizer, or as a builder — and you're on the hook for all three.

That's the version of the "who should want this" question that matters for anyone mid-career who's considering a pivot. The question isn't whether your background fits a template. It's whether that specific combination of accountability — in a room with a VP who doesn't understand what you're building, then alone with a codebase at 10pm — sounds like something you'd choose rather than something you'd endure.

---

How the Career Works

If you're used to reading job descriptions and mapping them to a clear promotion ladder, FDE will feel deliberately resistant. At Palantir, Bai explains, FDE is a terminal title — not a starting point. Senior leaders running significant commercial operations carry the same "FDE" designation as someone in their first year. Growth isn't tracked by title change; it's tracked by scope. You start working on one slice of one customer's problem. Over time, you own the whole account. Then accounts in an industry. Then a sector. Then a geography.

The Palantir model, as Bai describes it: you are given one customer. You are the CEO and CTO of a company that has exactly one client and cannot acquire more. Your only path to growth is making that client successful enough that someone trusts you with another one.

That framing is either clarifying or alarming depending on where you sit. For someone who thrives on defined scope and visible milestones, FDE at a company following the Palantir model will feel like floating. For someone who finds conventional promotion ladders bureaucratic and frustrating, it might feel like finally being evaluated on the thing that actually matters.

Other companies have layered senior and staff titles onto FDE, which is fine — it's their call. But the underlying mechanics of growth in the role don't really change: you are evaluated by how much business you're supporting and how directly you can be credited with its success.

---

What to Take Seriously in an Interview

Three dimensions, according to Bai, and they're roughly equal in weight.

Communication — but specifically preparation, not charisma. "The difference between clarity and maybe muddled communication," Bai said, "really is the amount of preparation that someone has put into the words that they're going to say." Introverts who prepare rigorously beat extroverts who wing it. What interviewers are looking for, functionally, is whether you can carry yourself with the kind of presence that would make a VP feel like their problem is in capable hands. That's what "executive presence" actually means in this context — not polish, not confidence, not a loud personality. Readiness.

Product judgment — which Bai says is genuinely hard to develop quickly. His shortcut for the interview-prep timeline: make decisions, write them down, then check whether someone with no context can read your reasoning and follow it. That's the skill. The judgment underneath it takes years.

Engineering completeness — not elegance. Can you anticipate the ways your solution breaks? Can you hand it off to someone who isn't technical and have them not break it? Do you think past the code to the user who will actually touch it?

---

Bai's closing note is the one that sticks: "It is just another job." There are FDEs at good companies who are miserable. The title won't fix anything structural about your career or your relationship to your work. What it will do, if the role genuinely fits, is give you a context where all three of the disciplines you've been splitting across different roles can live in the same seat.

Whether that sounds like relief or like too much — that's probably the answer to whether you should pursue it.

---

By Vanessa Torres