What an FDE does inside the building:
collect the nouns and verbs, then send the fix home

Vinoo Ganesh, now CEO and co-founder of Kepler, previously led compute at Palantir, where he built Project Frontline, a rotation that turned software engineers into FDEs, before running business engineering at Citadel. He has built parts of the forward deployed function at three institutions, over a decade. A Forward Deployed Engineer, or FDE, is an engineer a vendor places inside a customer’s operations to solve problems there.

The account begins at a dinner for the Forward Deployed Engineer Fellowship launched by the venture firm a16z, to which he had been nominated as a fellow. Around the table were FDEs from Snowflake, Anthropic, and several startups. Over the evening, the same two words described jobs with almost nothing in common: a sales engineer who joined “the second call,” a quota-carrying representative who could write Python, or something closer to a consultant with a laptop and a statement of work, brought in to deliver what the product could not. A few days later, someone asked the WhatsApp group how an FDE team should split scope with the consulting firm already in the account.

Ganesh is not interested in gatekeeping a term whose meaning is changing. His concern is that the current experts use it for fundamentally different jobs, with different reporting lines and incentives. Half the comments under any YouTube video about FDEs are some version of “isn’t this just reinventing consulting?”

The definition he works from came through three builds. At Palantir, the data-platform company, he began in Product Development, building storage and retrieval systems. He later worked as an FDE across commercial, defense and national security, healthcare, and oil and gas deployments. He also led Project Frontline. Around 250 people passed through it, and many now run forward deployed teams at companies such as OpenAI, Anthropic, xAI and Anduril. At Citadel, a hedge fund, he ran business engineering for internal customers who were portfolio managers. The third build is Kepler.

The story of Project Frontline starts with a mistake he helped make.

Ganesh’s reading is that the instinct beneath that expansion is still sound. Problems that can be solved by one well-designed product sold identically to a thousand companies have largely been solved. Much of what remains sits inside company walls, embedded in messy, undocumented workflows that are difficult to understand from outside. A discovery call cannot reveal how a particular company closes its books.

In his account, the repeatable product motion remains appropriate for tokens, bytes, or physical goods. Elsewhere, value has moved toward customization and the last mile: the twenty percent of the workflow that no product anticipated and that determines whether the other eighty percent gets used at all.

Solving that last mile is only half of the role. A problem found at one customer is also a signal about which part of the platform should become generalizable. In Ganesh’s words, “An FDE function that solves last miles without ever sending that signal home is a services/consulting team with a better title.”

The team made three arguments. Parquet would reduce storage, minimize compute, and optimize the pipeline. None addressed the actual problem.

An FDE went to watch the engineer work. She downloaded CSV files from S3, a cloud object store, onto a Windows laptop. She double-clicked each file and inspected the rows with her eyes. That was the data quality check. Moving to Parquet would have removed her only instrument without giving her a replacement. “She wasn't being difficult, she was just protecting the one thing that let her do her job.”

The team built a Parquet viewer that night. She approved the migration two days later, and pipeline execution fell from about seventeen hours to two. She would never have said any of this in an interview, Ganesh writes, because from where she sat the reason was obvious and not worth mentioning.

Mapping her nouns and verbs, in Ganesh’s telling, revealed the real system of operations. It also allowed the team to build something that could be delivered across a fleet of customers facing the same problem.

Every firm runs some version of the same ontology, the model of objects and relationships through which an institution operates, but describes it differently. A position can mean one thing on a credit desk and something adjacent on an equities desk at the same bank. Two funds may use identical language for a return calculation while disagreeing about the denominator. Many differences persist because somebody made a reasonable decision in, say, 2011 and the decision outlived that person. It is not written down anywhere that can be found. “A schema tells you what is stored. It does not tell you what is meant,” and the distance between the two is where a system that sounds right produces a wrong number.

Three firms asking for the same feature is, in Ganesh’s words, easy to notice and worth relatively little. The stronger signal is three firms needing something the platform cannot express. It usually arrives quietly, when an engineer works around the same limitation for the third time.

Product leverage makes experimentation cheaper. Each capability incorporated into the platform lowers the cost of attempting the next deployment. Without that leverage, a company gets one expensive guess per customer. If the guess is wrong, it has spent an account and a quarter finding out. Ganesh would rather be wrong four times in a month, with each attempt costing less than the previous one.

That, in his view, makes the reporting line more than an administrative choice. Point the function at sales and the incentive becomes closing the account in front of it, a real job that belongs to somebody else at the company. Point the function at product and every deployment is expected to produce something from which the next deployment can begin.

Ganesh rules out three candidates for the moat. The model becomes cheaper by the month and is rented from somebody else. Talent is bid for by every lab, the same few hundred people, and that price has already been discovered. The map of any one customer is nearly free to extract, since anyone can draft how a firm operates in an afternoon. “The draft is not the asset. Knowing which parts of it are wrong is the asset, and that only comes from having been corrected.”

For Kepler, he writes, the moat is the accumulated, current, verified understanding of how firms in a vertical actually operate, held in a platform that keeps it current and can prove it. Each of those words carries weight. Accumulated means one deployment is an anecdote and the tenth is a pattern. Current matters because operations drift, and a stale model can fail silently beneath an AI system in a way it did not when placed before an analyst. Verified matters because a plausible encoding and a correct one look identical until something breaks.

A competitor, he writes, can hire the same engineers, copy an interface, and read the same article. What it cannot shortcut is the sequence of being wrong inside a customer, being corrected, incorporating that correction into the platform, and arriving at the next institution already knowing which questions are load-bearing.

Across his three builds of the function, the engineers who mattered were the ones who returned from the field and changed what the company built, rather than those who shipped the most for customers. Hiring FDEs buys exactly one thing: the right to identify which problems are worth solving. “But it's the entry fee, not the prize.”