← Back to Blog

How forward deployed engineers are reshaping the CS org

By Jay Nathan, Jonathan Huhn|

Beyond The Click · Vol. 35 · June 11, 2026

Two years ago, almost nobody outside of Palantir used the term “forward-deployed engineer” (FDE). Today it might be the hottest job title in tech, and it’s also rewriting what customer success means looks like at AI-first companies.

Welcome to Beyond The Click by Balboa. We’ve been talking to leaders who are rebuilding their customer orgs from the ground up, and a lot of it means evolution in teams and roles. In today’s issue we’re getting into:

  1. Where the FDE came from 🗺️
  2. This is not your grandpa’s services team 🚀
  3. The new org chart has three lanes 🛣️
  4. The hardest part is hiring 🎯

Let’s dive in.

Where the FDE came from 🗺️

The FDE role was pioneered at Palantir, where engineers were embedded directly with customers (often governments and large enterprises) to turn messy, real-world problems into working software. The idea was simple but radical: instead of selling a product and hoping the customer figures it out, send technical experts into the field and let the customer’s problems shape what gets built.

For years, that model was viewed as a quirk specific to one company. But that all changed with the rise of AI. Today, many high-profile organizations like OpenAI describe their FDEs as the critical people who help customers move AI from an unrealized opportunity to production systems with measurable results. Put another way: helping customers achieve their desired outcomes.

That’s right, the FDE of today is achieving the same goal CS has been chasing for fifteen years, just with a code editor open.

This is not your grandpa’s services team 🚀

This shift might be hard to wrap your head around if you started your career in traditional (aka pre-AI) SaaS. FDEs at AI-native companies are deploying core product code, in the field, while working directly with customers. They’re not just doing configurations or customizations on a static platform. It’s actual product development, in real time, driven by what the customer needs today.

For CS leaders, that changes the job in front of you. The old CSM playbook assumed problems got logged, prioritized, and roadmapped. But when a team member sitting next to the customer can fix the problem that afternoon, “stuck in the roadmap” stops being an excuse, and “reactive mode” becomes not just painful, but completely infeasible. Value realization becomes something your team is expected to deliver now, not in two quarters.

Diagram of the three lanes in an AI-native customer org: forward-deployed engineers, value management, and sales

The new org chart has three lanes 🛣️

So what does the customer-facing org look like when FDEs enter the picture? The pattern emerging at AI-native companies has three distinct lanes:

First, FDEs own the build. They find use cases, remove technical bottlenecks, and get customers into production. Their work has a kickoff, a middle, and a ship date.

Next, value management (call the role a TAM, a CSM, etc.) owns the ongoing relationship. They diagnose whether a problem is a bug, a config issue, or a model hallucination, and they make sure value keeps compounding after the FDE moves on.

And finally, sales owns the number. Renewals, expansions, and quota live in a dedicated commercial function, because asking one person to go deep technically AND carry a revenue number is often how you get mediocrity at both.

Three lanes, but one goal, because in a consumption-billed world, the vendor doesn’t get paid unless the customer gets value.

The hardest part is hiring 🎯

Defining the roles is the easy part. But any leader in this space will tell you that filling them is tough.

FDEs and TAMs are different creatures. An FDE needs to be a legitimate builder who also thrives in front of customers, which cuts against how most engineers have spent their careers. Meanwhile a strong TAM needs enough technical fluency to diagnose whether a problem is a bug, a config issue, or a model hallucination, but also the customer instincts to own outcomes over time. Both roles need to be comfortable operating at a pace where the product changes by the minute.

Those skill combinations are rare, and the leaders we talk to are being deliberately picky, because a bad hire in these roles breaks the model.

But if you’re a CS professional reading this, that’s your opportunity. The demand for people who bridge technical depth and customer outcomes is only going up. While the job descriptions are still being figured out, the people who can do the work today are getting hired regardless.