The forward deployed to product engineer ratio

This question gets asked constantly and the honest answer is that nobody has published a defensible benchmark. What follows is how to derive your own, and what to check it against, so a hiring plan rests on your numbers rather than on a stranger's blog post.

Why we will not give you a number

Several sites publish confident ratios for this. We could not trace any of them to data, and a made-up ratio is worse than no ratio, because it gets used to justify a hiring plan.

The claim repeated most is that Palantir employed more forward deployed engineers than product engineers by around 2016. We could not find a primary source for it and do not repeat it as fact.

What is documented is that the correct ratio varies enormously with three things: how much of your answer is already product, how different your customers' environments are, and how long a deployment takes. A company whose platform covers 90 percent of every deployment needs a fraction of the embedded staff of one whose platform covers 40 percent.

A fourth variable published ratios never mention is the industry sold into. A company selling into financial services or government, where security and access review can take weeks before an engineer even reaches a customer's data, needs a different ratio than one selling into a market where an engineer can be looking at production data on day two. Two companies at the same revenue, same headcount and same product maturity can correctly have different ratios because their customers' approval processes differ. A benchmark that ignores this measures the wrong thing even where one exists.

The calculation

Bottom-up, with your own numbers.

Step one: how many accounts need embedded work? Not all of them. First Round Review's guidance is to reserve embedded engineers for the highest contract values and customers with complex, non-standardised needs, typically organizations of 1,000 employees or more, and to serve everything smaller with repeatable implementations. Count only the first group.

Step two: how long is a deployment? In engineer-months, from signature to handover. Use your actual last three rather than the plan. If you have not done three, use the plan and revise it after the first.

Step three: what is real capacity? An engineer is not on customer work 12 months a year. Subtract holiday, internal work, the productization time you are deliberately funding, and the gap between engagements. Two-thirds of the year on customer deployments is a reasonable planning figure to start from and worth replacing with your own measurement.

Step four: divide. Accounts needing embedded work per year, times engineer-months per deployment, divided by real engineer-months of capacity per person.

Step five: check against contract value. Multiply your headcount answer by loaded cost per engineer. If that number is a large share of the revenue from those accounts, the model does not work at your current contract values, and the fix is pricing or account selection rather than a different ratio.

A worked example shows how quickly a plausible plan can fail that check. Say twelve accounts need embedded work this year, each deployment runs four engineer-months from signature to handover, and real capacity per engineer is eight customer-facing months a year after subtracting holiday, internal work and funded productization time. Twelve accounts times four months is 48 engineer-months of demand. Divide by eight months of capacity per engineer and the answer is six embedded engineers. Multiply six engineers by a loaded cost and compare that total against the combined annual contract value of those twelve accounts. If the twelve accounts are worth $600,000 combined and six loaded engineers cost $2.4 million, the ratio was never the problem: the accounts are too small for the model at any staffing level, and the fix is raising the contract-value floor before hiring anyone.

The minimum that has to be met first

Before the ratio matters, the unit economics have to work.

Take one engineer's loaded cost for the length of a typical deployment. Compare it to the annual contract value of the accounts you would deploy on. First Round reports Looker validating $25,000 or more in annual contract value, together with a trajectory toward 2,000 customers and $100 million in recurring revenue, before it committed.

Do not adopt $25,000. Your costs and margins are different, and a US-based senior engineer against a $30,000 contract is a different calculation than the same engineer against a $2 million one. Two verified compensation figures to start from: Levels.fyi reports Palantir forward deployed engineer total compensation with a median of $278,000, read 8 September 2026, and the median advertised salary across 1,000 postings was $173,816. What it costs works through this.

The number that tells you whether your ratio is right

Ratios are inputs. The output to watch is revenue per embedded engineer, tracked over time.

It should rise. As the platform takes in what engineers learned at customer sites, each engineer handles more accounts, and revenue per engineer rises. If it stays flat while custom work accumulates, the ratio is not your problem: the productization loop is not running, and hiring more embedded engineers will make the problem bigger rather than solve it.

Revenue per forward deployed engineer covers the measurement, and the productization loop covers the mechanism.

What the market looks like, for calibration only

Two data points worth having, neither of which is a ratio.

58 percent of the 1,000 postings analysed came from companies with 11 to 200 employees. At that size, a handful of embedded engineers is a meaningful share of engineering, which tells you the model is being adopted by companies where the ratio is necessarily high.

Only 45 percent sat on a dedicated forward deployed team. So in over half the market this is not a distinct function with its own headcount plan, which is part of why no reliable ratio exists to publish.

The pattern to aim for

If the model is working, the ratio should fall over time.

Early on, most of every deployment is custom, so you need many embedded engineers per product engineer. As the platform matures and the reusable delivery tools exist, the custom share shrinks and each embedded engineer serves more accounts. A ratio that stays flat for two years is the clearest sign that nothing is being generalised.

That direction of change is more informative than any absolute number, which is the practical reason we would rather give you the calculation than a benchmark.

Two mistakes the calculation does not catch on its own

The five-step calculation gives a headcount number, and a headcount number can still be wrong in two ways the arithmetic will not flag.

Counting deployment length from the plan instead of the history. Every deployment plan understates how long the work actually takes, because the plan is written before discovery finds the parts nobody scoped. If step two uses planned engineer-months instead of actual engineer-months from your last three deployments, the whole calculation understates headcount need, and the shortfall shows up months later as engineers pulled off one account to firefight another. Revise step two with real numbers as soon as you have three completed deployments to revise it with.

Treating capacity as a constant instead of a curve. A newly hired embedded engineer is not at full capacity in month one. They are learning your product, your domain models, and the registry of what already exists, which is exactly the kind of knowledge the productization loop is supposed to be building for them. Budget a ramp period, typically the length of one full deployment cycle, before counting a new hire's capacity at the same level as an engineer who has done this three times already. Skipping the ramp period is the most common reason a hiring plan that looked correct on paper produces a team that is still behind schedule a year later.

Start here instead of with a ratio

Two or three engineers on your highest-value accounts, one named owner for productization, and a tracked ratio of shared to custom code per account. Then re-derive the number after three deployments with real data, using actual engineer-months from those deployments in place of the plan and actual capacity in place of the assumption. That re-derivation is not a formality: it is the point where the calculation stops running on guesses and starts running on your own company's evidence, which is the only version of this number worth keeping.

How to build the team covers the starting setup.