The FDE boom has a definition problem. “FDEs have the hottest job in AI,” says Vinoo Ganesh, CEO of Kepler, but the title now covers several jobs with little in common. Labs, startups, and PE firms are hiring engineers to sit inside customer operations and solve problems—without agreeing on what those engineers should accomplish.
Ganesh has built pieces of the forward deployed function three times, at three different institutions, over the course of over a decade. His experience at Palantir, Citadel, and Kepler gives him a useful vantage point: the role can connect product development to real customer needs, or become a vague label attached to almost any technical work near a sale.
“Almost none of them agree on what those engineers are supposed to accomplish, or what the strategy underneath the hiring actually is,” Ganesh says. That uncertainty is not a minor naming dispute. It affects reporting lines, incentives, scope, and the basic question of whether the team builds a product or delivers something the product cannot.
One title, several very different jobs
Ganesh saw the confusion firsthand through the a16z Forward Deployed Engineer Fellowship, where he was nominated as one of the fellows. At a dinner in San Francisco, FDEs from Snowflake, Anthropic, and startups used the same two words for jobs that had “almost nothing in common.”
In one case, an FDE was a sales engineer who joined “the second call.” In another, the role belonged to a quota-carrying representative who could write Python; elsewhere, it looked like a consultant with a laptop and a statement of work, brought in to deliver something the product could not.
The confusion reached the practical level when someone asked how an FDE team should divide scope with a consulting firm already working in the account. “I’m not interested in gatekeeping a term,” Ganesh says, and meanings do shift. But different jobs with different incentives should not be treated as a single operating model simply because the title fits.
That is why the question “isn’t this just reinventing consulting?” keeps appearing in discussions about FDEs. Sometimes the answer may be close to yes. The difference depends on whether the engineer is discovering product needs, extending a platform, supporting a sale, or delivering a custom result that never becomes part of the core product.
What Project Frontline tried to fix
Palantir offered an early model for separating these responsibilities. From nearly the beginning, the company split into Product Development, or PD, and Business Development, or BD.
PD built the platform and, in most situations, did not engage directly with customers. BD included technical FDEs along with non-engineering customer-facing roles called Embedded Analysts or Deployment Strategists; in most situations, BD did not contribute directly to the generalized core platform.
That division created a gap between what customers needed and what the product became. PD gathered customer discovery secondhand through BD, then consumed successful build-in-the-field features into the core product. But the process ran on relationships—such as which FDE knew which PD engineer well enough to get their attention.
So a useful field insight could reach the platform or disappear depending on who happened to be in the room. A company can call that collaboration, but the operating system underneath was closer to personal networking.
In 2013, Ganesh worked on Palantir’s Phoenix transaction store. Engineers designed it around clear customer use cases, with a clean design and clever retention logic for storing a rolling window of data. It behaved as specified in every environment the team controlled.
Then Phoenix reached a bank, where real financial data contained holes that test data did not. A blank timestamp fell through to the epoch, causing the retention logic to request a ten-minute bucket for every window between January 1, 1970, and the present day—about 2.3 million keyspaces.
Cassandra, the backing technology, needed roughly five megabytes per file handle. The server ran out of memory, and restarting it would have required 14 terabytes of RAM. Clean design had met messy reality, and reality had brought a very large bill.
Project Frontline emerged as a response to that distance between engineering assumptions and customer conditions. Ganesh started on product development, rotated into a forward deployed engineer role, and later led the program that exposed software engineers to life in the field. Around 250 people went through Project Frontline, and many now run forward deployed teams at OpenAI, Anthropic, xAI, and Anduril.
The lesson is not that every engineer should become an FDE. It is that product teams need direct contact with the environments their systems must survive—and a clear path for turning field lessons into durable products.
Ganesh’s experience at Citadel adds another version of the same test: “Our customers were portfolio managers, and the only question that mattered was whether the data and software products we built helped them generate alpha.” That kind of outcome gives the role a purpose. Without one, “forward deployed” becomes a polished label for whatever work no existing team wants to own.
Based on
