Every AI lab, startup, and private equity firm seems to be hiring “Forward Deployed Engineers” right now. Almost none of them agree on what the job is actually supposed to produce, and one founder who has built the role three times says most companies are getting it wrong.
What he said
A Forward Deployed Engineer, or FDE, is an engineer who sits inside a customer’s own operations, embedded with their team, to build and adapt software directly against that customer’s specific problems, rather than working from a company’s own office on a generic product. Vinoo Ganesh argues, in an essay on Latent Space, that most companies hiring for this role are actually just rebranding consulting work: “Most current FDEs are actually consultants with better titles.” His sharpest line on what failure looks like: “An FDE engagement that ends with one delighted account and nothing changed upstream has failed.”
His argument is that the point of an FDE isn’t to make one customer happy. It’s to take what’s learned from that customer’s specific problem and turn it into something the whole product gets better at handling, so the next customer’s version of the same problem gets solved faster. If nothing generalizes, he says, the company has just paid an engineer’s salary to do work a contractor could have done.
Who he is
Ganesh is the CEO and co-founder of Kepler, which he describes as building “deterministic infrastructure for AI,” meaning infrastructure built to produce the same, predictable result every time, in contrast to the variable outputs typical of AI models themselves. Before Kepler, he built pieces of the forward deployed function at Palantir, the data analytics company that popularized the FDE role, where he says he ran a program that trained around 250 engineers who went on to lead forward-deployed teams at companies including OpenAI, Anthropic, and xAI. He later ran business engineering at the hedge fund Citadel. That’s three separate companies where he’s had to define what this specific role is supposed to accomplish, which is the direct basis for his critique.
What he gets right, and where it’s incomplete
Ganesh’s distinction between an FDE and a consultant is concrete enough to actually check against a real hire: does the work only ever solve the customer in front of you, or does it change what the product can do for every customer after that. That’s a useful test, and it explains a real pattern builders can watch for: teams that add headcount for “customer-facing engineering” without any process for feeding what those engineers learn back into the core product.
His other structural point, that FDEs should report into product rather than sales, is a stronger claim than the essay fully defends. It follows logically from his generalization argument: a function measured on deal-closing will optimize for the specific customer in the room, not for what should ship broadly. But it’s also a prescription drawn from his own three companies, not a comparison against firms that route FDEs through sales and still generalize the work well. Readers should treat it as a strong, experience-based recommendation rather than a demonstrated rule.
Why it’s notable
The FDE title has spread fast across AI labs and AI infrastructure startups over the past two years, largely because AI systems now need more hands-on tuning against messy, real-world customer data than a typical software sale requires. Ganesh’s essay is less about that trend and more about a warning that the label is being used loosely enough to cover very different jobs, which makes it a bad signal for job seekers and hiring managers trying to compare roles across companies.
What it means for builders
If you’re hiring for this role, Ganesh’s test is worth applying literally: ask what the last three FDE engagements changed in the actual product, not just what they delivered to the customer. If the honest answer is “nothing changed upstream,” you’re paying engineer salaries for contractor-shaped work, and you should either change how the role reports and is measured, or call it consulting and staff it accordingly.
If you’re a builder considering an FDE role yourself, ask the hiring team directly who the function reports to and how its work gets fed back into the product roadmap. Ganesh’s argument suggests that answer predicts more about whether the job will feel like building something durable, versus repeatedly solving the same problem for a new customer, than the title on the job posting does.
End of article