The Rise of the Forward Deployed Engineer — and How To Do the Job Right

Latent Space published a deep-dive on the forward-deployed engineer (FDE) role, written by Vinoo Ganesh, CEO of Kepler and former head of compute at Palantir. Ganesh argues that while FDEs have become "the hottest job in AI"—with labs, startups, and PE firms all hiring engineers to embed inside customer operations—there is almost no agreement on what they actually accomplish or why the role exists. The confusion cuts deep: Ganesh sat at a dinner with FDEs from Snowflake, Anthropic, and several startups, and discovered that the same title described jobs that had "almost nothing in common." Some were sales engineers jumping on second calls. Others were quota-carrying reps who could code. Still others looked closer to consultants with laptops and statements of work.

The problem, Ganesh explains, is that the low-hanging fruit in software is gone. For decades, the model was a repeatable SaaS motion—the same product sold identically to a thousand companies. That battle has largely been won. What remains is the messy, undocumented work that sits inside customer walls: workflows so specific and contingent that no product can anticipate them from the outside. Per Ganesh, the value has migrated to customization, to the last mile—the twenty percent of a workflow that no product could have anticipated and which determines whether the other eighty percent gets used at all. That is why everyone suddenly claims to be forward-deployed. But solving the last mile is only half the job. The other half is sending the signal home.

Ganesh draws the distinction sharply: an FDE function that solves last miles without ever feeding that signal back to the platform is a services or consulting team with a better title. He illustrates this with a story from his time at Palantir. A transaction store called Phoenix was designed cleanly against secondhand requirements. When deployed at a bank against real financial data, the system encountered timestamps so malformed that the retention logic broke: it requested 2.3 million keyspaces and would have required 14 terabytes of RAM to start up. The root cause was not a lack of user research—it was that nobody on the team had stood inside the building while the system ran against production data. Ganesh ended up flying out to fix Phoenix across Palantir's fleet, which turned him into an FDE and taught him to recognize the gap between design and reality. But the key turn came later: as FDEs started building on top of Phoenix across multiple use cases (cybersecurity, KYC, AML), the platform had to expand to support them. An FDE solves customer problems in order to earn the insight that informs what gets built next. The role is an extension of the product team, not the sales function.

At Kepler, Ganesh structured the FDE function to report to product rather than sales from day one. The firm works with hedge funds, investment banks, and PE shops—institutions where numbers must be provably correct. That constraint forces the operating model into the open and gives the platform a bedrock to execute against. When Kepler misunderstands how a firm defines something, the system fails rather than producing a plausible wrong answer. That feedback loop is where the platform learns what to extend. The moat is not the model, which is rented and depreciating, nor the talent, nor the map of any one customer. Per Ganesh, the draft of how a firm operates is not the asset; knowing which parts of it are wrong is the asset, and that only comes from having been corrected. Each cycle of being wrong inside a customer, getting corrected, and folding the correction into the platform makes the next deployment cheaper. That compounding is what competitors cannot shortcut. Hiring FDEs buys exactly one thing: the right to identify which problems are worth solving. Most companies, Ganesh concludes, never get that far.