Forward deployed engineering: the complete guide / Building the function
The forward deployed to product engineer ratio
There is no credible published benchmark for the ratio of forward deployed engineers to product engineers, and we are not going to invent one. What exists is arithmetic you can do with your own numbers, and one documented floor: First Round Review reports Looker validating $25,000 or more in annual contract value before committing to the model. Size the function from account count, deployment length and the contract value that has to carry it, then check the result against whether your revenue per embedded engineer is rising.
Key takeaways
- No trustworthy published ratio exists. Any specific number you find in a blog post is unsourced, and we do not repeat it.
- Size from the bottom up: accounts needing embedded work, times deployment length, divided by working capacity per engineer.
- The floor is contract value. First Round Review reports Looker validating $25,000 or more in annual contract value before committing.
- The check on whether your ratio is right is whether revenue per embedded engineer rises over time. Flat means the custom work is not generalising.
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.
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 that circulates 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.
The arithmetic
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: sanity-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.
The floor that has to clear 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 anchors 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 this through.
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 absorbs what the field learned, each engineer covers more ground, and revenue per engineer climbs. 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 scale the problem 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 shape 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 harnesses 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 travel is more informative than any absolute number, which is the practical reason we would rather give you the arithmetic than a benchmark.
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.
How to build the team covers the starting shape.
Best for
- Sizing an embedded engineering function from your own numbers
- Sanity-checking a hiring plan against contract value
- Explaining to a board why a published benchmark ratio is not the basis for a plan
Avoid if
- You want a single number to copy, which no defensible source provides
Verify before you commit
- Count only the accounts that genuinely need embedded work, not all accounts
- Use engineer-months from your last three deployments rather than the plan
- Multiply the headcount answer by loaded cost and compare against those accounts' revenue
- Track revenue per embedded engineer over time and confirm it is rising
Common questions
What is the right ratio of forward deployed engineers to product engineers?
No credible published benchmark exists, and we do not invent one. The correct ratio varies with how much of your answer is already product, how different your customers' environments are, and how long a deployment takes. Derive it bottom-up from accounts, deployment length and real capacity instead.
How do you calculate how many embedded engineers you need?
Count only the accounts that genuinely need embedded work rather than all accounts. Multiply by engineer-months per deployment, taken from your last three actual deployments. Divide by real capacity per engineer, after subtracting holiday, internal work, productization time and gaps between engagements. Then check the total against contract value.
What contract value do you need before the model works?
Calculate your own floor. First Round Review reports Looker validating $25,000 or more in annual contract value, alongside a trajectory toward 2,000 customers and $100 million in recurring revenue, before committing. Anchors for loaded cost: Palantir forward deployed median total compensation of $278,000 on Levels.fyi, and a $173,816 median advertised salary across 1,000 postings.
Did Palantir have more forward deployed engineers than product engineers?
That claim circulates widely and we could not find a primary source for it, so we do not repeat it as fact. What is documented is that Palantir popularised the role and built its delivery model around engineers embedded with customers working on customer data.
Should the ratio go up or down over time?
Down, if the model is working. Early on most of every deployment is custom, so the ratio is high. As the platform matures and reusable harnesses exist, the custom share shrinks and each embedded engineer serves more accounts. A ratio flat for two years is the clearest sign nothing is being generalised.
What should you check instead of the ratio?
Revenue per embedded engineer over time. It should rise as the platform absorbs what the field learned. If it stays flat while custom work accumulates, the ratio is not the problem: the productization loop is not running, and hiring more embedded engineers scales the problem rather than solving it.
How a build like this runs
Related reading
How to size a team when generation is cheap
Headcount planning still assumes writing code is the expensive part. It is not anymore, and that changes which roles are actually scarce and how many people a project can absorb before it slows down.
How to estimate a software project honestly
A single-number estimate on new work is a promise nobody can keep. The honest version is a range that reflects real uncertainty, and the biggest driver of a bad estimate is risk nobody scoped.
More in Building the function
How to build a forward deployed engineering team
Before hiring anyone, confirm three prerequisites: your customers are enterprises, your product is still flexible enough to change based on what you learn, and their use cases differ from each other. First Round Review names all three, and missing two means do not start. Then begin with two or three engineers on your highest-value accounts only, report the function into product or engineering rather than sales, and give somebody the job of turning field work into product from the first month. Those last two decisions determine whether the function becomes a moat or a cost centre.
Forward deployed engineer job description
Most forward deployed engineer job descriptions fail in the same two places: they do not say which of the three jobs the role actually is, and they hide the travel. Across 1,000 postings carrying the title, 60 percent were production engineering roles, 30 percent were sales engineering with implementation duties, and 10 percent faced no external customer. 68 percent required travel, with 50 to 75 percent typical where a number was given. State both in the first hundred words and your funnel gets smaller and much better.
How to hire a forward deployed engineer
The candidates come mostly from software engineering: across 1,000 postings, 45 percent of routes into the role came from software engineering, 22 percent from solutions or sales engineering, 15 percent from data, 10 percent from technical consulting and 8 percent from founding or early-employee roles. First Round Review names five qualities that predict success and one counter-intuitive red flag: ten or more years at a large tech company, because the role needs somebody who operates without institutional scaffolding. Do not lower the engineering bar to get customer skills.
How to interview a forward deployed engineer
A forward deployed engineering loop has to test three things in roughly equal weight: engineering depth, judgment in front of a customer, and the ability to reason out loud through ambiguity. That makes it different from a standard engineering loop, where the third is barely assessed. The signature round is an ambiguous case: a vague problem from a hypothetical customer, which the candidate has to decompose into a plan. The most common reason strong engineers fail it is jumping to a solution before scoping the problem.
Where forward deployed engineering should report
Forward deployed engineering should report into product or engineering, not sales, and not a separate professional services unit. Marty Cagan's warning is direct: if embedded engineers sit in a professional services group, you lose the feedback loop and drift toward a pure services business. The hiring data suggests most of the market has already made the wrong choice, with only 45 percent of 1,000 postings sitting on a dedicated forward deployed team rather than under sales. This is a nearly free decision at the start and expensive to reverse later.
The productization loop
The productization loop is the mechanism that turns one customer's custom work into a capability every customer gets. It needs three things: a fixed cadence, a named owner, and a stop rule. First Round Review's version of the stop rule is the useful one: expand scope when the work creates repeatable software value, and halt when the iteration only serves a single customer. Without this loop, embedded engineering produces what a16z describes as bespoke deployments impossible to maintain or upgrade, where revenue grows and nothing compounds.