Build1 publisher3 min readPublished
Field insight reached Palantir's platform only if an FDE knew the right product engineer
Kepler's Vinoo, who led the rotation that turned about 250 Palantir engineers into forward deployed ones, writes that nothing carried customer findings back into the core product except who knew whom. He now runs the function inside product.
The Engineer · Build desk

What happened
- Vinoo, CEO of Kepler, writes that labs, startups and PE firms are all hiring engineers to sit inside customer operations, and that almost none of them agree on what those engineers are supposed to accomplish.
- At an a16z Forward Deployed Engineer Fellowship dinner in San Francisco, FDEs from Snowflake, Anthropic and several startups described the role variously as a second-call sales engineer, a quota-carrying rep who writes Python, and a consultant with a statement of work.
- A few days later, one of the fellows asked the group's WhatsApp thread how their FDE team should split scope with the consulting firm already sitting in the account.
- Around 250 Palantir software engineers went through Project Frontline, the rotation Vinoo led, and many of them now run forward deployed teams at companies including OpenAI, Anthropic, xAI and Anduril.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint When the path from customer site to core platform is an acquaintance rather than a process, what the field learns stays in the account that paid for it, and the next deployment starts from the same gap.
- decision Anyone standing up one of these teams picks a reporting line before a job description: under sales the team closes gaps in front of the product, under product it is chartered to remove them.
- exposure Candidates cannot read the title. Quota, comp and reporting line all differ under the same two words, so an offer can describe work the engineer never agreed to do.
- precedent Because alumni of a single Palantir rotation now run forward deployed teams at four named AI and defence companies, Palantir's product-versus-business split is the structure the next generation of these orgs inherits by default.
The split that produced the problem at Palantir was organisational. Product Development built the platform. Business Development held both the technical people already called FDEs and the non-engineering customer roles, called Embedded Analysts or Deployment Strategists [12]. In most situations PD did not engage customers directly, and BD did not contribute to the core generalised platform, so PD did its discovery secondhand [13]. Vinoo, CEO of Kepler, writes that none of this was a process: it ran on relationships, such as which FDE happened to know which PD engineer well enough to grab them [15]. "So a good insight from the field made it into the platform (or was dropped) depending on who was in the room," he wrote [14].
A field team on that wiring solves the same customer problem once per account. The code exists, the customer is happy, and the next deployment starts from the same gap.
The two later versions of the job start from a named outcome. At Citadel, Vinoo ran business engineering, where the customers were portfolio managers and the only question that mattered was whether the data and software products the team built helped them generate alpha [5]. At Kepler, the forward deployed function sits inside product instead of sales, in a domain where, he writes, a plausible wrong answer is worse than no answer at all [6].
The three descriptions of the role that came up at the a16z fellowship dinner do not have that in common. They differ in reporting line and in incentive, which Vinoo notes about the group himself [9]. For a table of people hired as experts in the function, three definitions in one evening is a lot of variance [18].
Vinoo says half the comments on any YouTube video about FDEs are some version of "isn't this just reinventing consulting?" [11]. Scope is the reason the question keeps landing. A team that delivers around a product can divide a statement of work with an incumbent consultancy cleanly, because both sides are billing for the same kind of artefact. A team chartered to make the product cover the case has nothing to divide, and its output is a change to the platform that the account it came from does not own.
This is one practitioner's account. The essay does not include headcount, revenue or win rates for the three teams beyond the roughly 250 engineers who went through Project Frontline [19]. Its evidence for one wiring over another is the Palantir structure and a mistake Vinoo says he helped make, which he credits with turning him into an FDE [17]; he dates his work on Phoenix, a transaction store he describes as cleanly designed, to 2013 [16]. He was later deployed as an FDE across commercial, DoD and NatSec, healthcare and oil and gas accounts [3].
What to watch
- Whether the rest of Vinoo's account names the Phoenix mistake and says what Project Frontline changed structurally, not just who rotated.
- Whether the a16z fellowship converges on one definition of the role, or its members keep publishing incompatible ones.
- Whether any lab or startup publishes the reporting line and comp structure for its forward deployed org, so candidates can read the title.