Forward deployed engineers (FDEs) are among the most in-demand roles in AI and data infrastructure today: labs, startups and investment firms hire engineers to sit inside customer operations and solve concrete problems. Vinoo Ganesh, CEO of Kepler, who has built the forward deployed function three times (at Palantir, Citadel and Kepler) over more than a decade, explains what has worked, what has failed, and how the role should be structured.
Background: Project Frontline and early lessons
Ganesh began at Palantir in product development and later worked as an FDE across commercial, DoD and national security, healthcare and oil and gas sectors. He led Project Frontline, a rotation that converted software engineers into forward deployed engineers: about 250 people went through the program, and many now run FDE teams at companies such as OpenAI, Anthropic, xAI and Anduril.
At Citadel he ran business engineering, serving portfolio managers where the central question was whether the data and software produced alpha. At Kepler, the forward deployed function sits inside product rather than sales, operating in a domain where a plausibly wrong answer can be worse than none at all.
Common misunderstandings of the FDE role
As the term spread, its meaning blurred: some use “FDE” to mean a sales engineer who joins a second call, a quota-carrying rep who can write Python, or a consultant with a statement of work. This plurality creates problems because different definitions imply different reporting lines and incentives.
Ganesh argues the real FDE is not just customer support or consulting: the FDE’s job is to solve customer problems to earn the insight that informs what should be generalized into the product.
Becoming an FDE — the Phoenix story
In 2013 Ganesh worked on Phoenix, a transaction store at Palantir. The design was clean and matched the specified commercial retention use cases, and behaved correctly in controlled environments. But when deployed at a bank, real financial data revealed holes the tests never showed: blank timestamps fell back to the epoch, causing the retention logic to request a ten-minute bucket for every window between January 1, 1970 and the present — about 2.3 million keyspaces on a system where Cassandra needed roughly 5 megabytes per file handle. The server OOMed; restarting it would have required about 14 terabytes of RAM, effectively killing the deployment.
The root cause was not lack of user research: there was a spec and an understood use case, but no one had stood inside the building while the system ran on production data. Knowledge had been relayed secondhand and nobody owned the gap between design and daily reality. That forced Ganesh to fly to the field, fix what had been shipped, and start building systems in service of the people using them — a visceral education in the FDE mindset.
Phoenix evolved into a platform used by Palantir’s FDEs for cybersecurity, KYC, AML and many use cases that hadn’t been scoped initially. The iteration cycle — solving field problems to inform the platform — is the core idea: an FDE solves customer problems to create insights that inform what gets built next.
What an effective FDE actually does: collect nouns and verbs
Ganesh suggests FDEs should "collect nouns and verbs." Spend a week inside a company and you’ll find the same concept has many names: sales says customer, ops says client, finance books billing entity, engineering writes org_id. Those names are surface-level; underneath sits the operating model.
- Nouns are the entities the business treats as real (positions, counterparties). They’re rarely defined the same way across organizations.
- Verbs are how nouns move: how trades are booked, what must be true to close the books, who signs off on exceptions. These processes are often lived, not written.
This operational knowledge typically lives in the heads of long-tenured people or in an old spreadsheet the team depends on. It is hard to extract in interviews but critical to understand.
Example: at one customer a data quality engineer validated CSVs by downloading them from S3 to a Windows laptop and eyeballing rows. Parquet had no native viewer, so migrating to Parquet would have removed her only quality-control instrument. After an FDE watched her workflow, the team built a Parquet viewer that night; she approved the migration two days later and pipeline execution time fell from about 17 hours to 2. She would never have articulated the constraint in an interview — observing the work did.
Understanding the nouns-and-verbs of that analyst let the team build a solution that could then be shipped to other customers with the same problem.
The output must be a product
Nouns and verbs contextualize problems, but the output must become a product rather than a one-off fix. Solving the immediate problem and leaving the insight local is a failure of the FDE role. Ganesh recalls hacking together a groovy script named "vinoo.groovy" as an afternoon stopgap; a year later it was running across a large customer and became an embarrassing long-term maintenance burden. Every shortcut shipped tends to become something you own.
Discipline is knowing which fixes belong in the platform and which to throw away on purpose after they’ve served their temporary purpose.
The fork: consulting versus platform-building
The split is clear. Do the work without a platform underneath and you learn one company’s model, ship a bespoke solution and lose the knowledge when the engagement ends — that is consulting: well-paid, non-compounding. Build a platform under the same work and each mapped company makes the next deployment faster and the product sharper because the field knowledge has somewhere to live. That’s the difference between selling hours and creating an asset. Ganesh’s read of the current gold rush is many companies are doing the first while telling investors they’re doing the second.
How Kepler implements the function
At Kepler the FDE function was set as an extension of product from day one. They sell to hedge funds, investment banks, PE firms and other financial institutions, which differ in mandate but share a non-negotiable constraint: numbers must be correct and every number must have demonstrable provenance. That constraint forces operating models into the open and becomes the platform’s design invariant.
Provenance is both a correctness requirement for customers and a mechanism that makes field work compound. A system that improvises around bad encoding never signals the encoding was bad; Kepler’s system does not improvise. Misunderstandings surface as failures rather than as passable answers, and engineers get corrected by the system quickly. Deployments then indicate what to extend in the platform: the focus is not on which single feature a fund would like, but on where the platform’s provenance layer is too narrow to represent reality. Three firms asking for the same provenance capability is the meaningful signal.
Product leverage buys the right to experiment: every capability added to the platform makes the next deployment cheaper and faster, so a small company can learn via cheap, frequent attempts rather than one expensive guess per customer. This is why reporting lines matter: point the function at sales and the incentive is to close the account in front of you; point it at product and every deployment must create something the next deployment can start from.
Where the moat is
The moat is not the model (which decays and is rented), nor purely the talent, nor a single customer map. The asset is an accumulated, current, verified understanding of how firms in a vertical actually operate, held in a platform that keeps it current and can prove it. Accumulated — because one deployment is anecdote and the tenth is a pattern. Current — because operations drift. Verified — because plausible encodings and correct encodings look identical until something breaks. That sequence of being wrong in a customer, getting corrected, folding the correction into a platform, and arriving at the next firm with knowledge of which questions matter is not shortcuttable.
Ganesh has watched the function built three times and the same pattern held: the most valuable engineers were not those who shipped the most for customers, but those who came back and changed what was built. Hiring FDEs buys you the right to identify which problems are worth solving. That is the entry fee, not the prize.
Vinoo Ganesh is CEO of Kepler, where he is building the layer that lets an AI product trace every number back to source. Previously he led compute at Palantir and built Project Frontline, then ran business engineering at Citadel. He invites discussion on LinkedIn.
