Forward deployed engineering: the complete guide / Commercials
Revenue per forward deployed engineer
Revenue per embedded engineer, tracked over time, is the single number that tells you which business you are in. It has to rise. When the platform absorbs what the field learned, each engineer covers more ground and the number climbs. If it stays flat while custom work accumulates, you are running a services shop that has not admitted it yet. The benchmark for what a rising curve looks like is the previous generation: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, reaching 79 and 75 percent by 2024.
Key takeaways
- The number must rise over time. Flat revenue per embedded engineer with growing custom work is the definition of the services trap.
- a16z's benchmark for the healthy trajectory: ServiceNow 63.2 percent gross margin at IPO to 79 percent in 2024, Workday 54.1 percent to 75 percent.
- Track it quarterly on a rolling basis, and pair it with the share of shared versus custom code per deployment.
- If the number is flat, hiring more embedded engineers scales the problem rather than solving it.
One number, tracked as a trend. It answers a question most companies running this model avoid asking.
What to calculate
Revenue attributable to accounts served by embedded engineers, divided by the number of embedded engineers, over a rolling period.
Keep it simple and keep it consistent. The absolute value is not comparable to anybody else's, because what counts as attributable revenue differs by company. The trend within your own numbers is what matters, so pick a definition and do not change it.
Track it quarterly. Monthly is noise, annually is too late to act on.
Why it must rise
The economic case for spending margin on embedded engineers is that they learn things that improve the product, so the next deployment is cheaper. If that is happening, then over time each engineer serves more accounts, or the same accounts with less custom work, and revenue per engineer climbs.
If it is flat, the learning is not being converted. Each deployment is starting near zero and the margin you spent bought a delivered project rather than a durable capability. a16z's Marc Andrusko describes that end state as bespoke deployments impossible to maintain or upgrade, with revenue scaling and nothing compounding.
The uncomfortable version: flat revenue per embedded engineer means adding engineers adds revenue linearly, which is the definition of a labour business. That is a legitimate business and it does not deserve a software valuation, and pretending otherwise is what Andrusko's piece is about.
What a healthy trajectory looks like
The best public benchmark is the previous generation of enterprise software, from a16z's Trading Margin for Moat.
ServiceNow's gross margin at IPO: 63.2 percent. In 2024: 79 percent.
Workday's gross margin at IPO: 54.1 percent. In 2024: 75 percent.
Both started well below the 80 percent software investors treat as normal, and both climbed roughly 16 to 21 percentage points as the services-heavy motion converted into product. That climb is the thesis. A company that stays at its starting margin for a decade did not execute the second half of the plan.
Gross margin and revenue per engineer are not the same metric, and they move together for the same reason: both improve when the platform absorbs what the field was doing by hand.
When flat is fine, briefly
Two cases.
The first year. With three deployments there is nothing to generalise across yet and the number is noise. Start tracking it and do not react to it.
A deliberate market expansion. Entering a new vertical resets the custom share, because the domain models and connectors for that market do not exist. Revenue per engineer dips and should recover. Say out loud that this is what you are doing, with an expected recovery period, so the dip does not become permanent by accident.
Outside those, flat is a diagnosis.
What to do when it is flat
Do not hire more embedded engineers. This is the instinct and it scales the problem. More engineers on more accounts producing more custom code makes the maintenance burden worse and the margin picture no better.
Check whether the productization loop exists. Is there a cadence, a named owner with authority to promote work, and a stop rule applied out loud? If any of the three is missing, that is the cause. The productization loop covers the mechanism.
Check the reporting line. A function under sales or inside a services unit with its own margin target has a structural incentive against generalising. Where the function should report covers why.
Check the shared-versus-custom ratio per deployment. If the custom share grows with each account rather than shrinking, you have the measurement to prove the cause.
Check whether you are serving accounts that should be templated. First Round Review's guidance is to reserve embedded engineers for the highest-value accounts with genuinely non-standardised needs, and to serve smaller accounts with repeatable implementations. Embedded engineers on accounts that did not need them will hold this number down on their own.
The pair to track alongside it
Revenue per engineer is a lagging indicator. It moves quarters after the cause.
Pair it with the share of shared versus custom code per deployment, which is a leading indicator and moves within a deployment. When the custom share starts growing per account, revenue per engineer will flatten two or three quarters later. Catching it on the leading indicator is the difference between an adjustment and a restructure.
Measuring the function covers the full set.
For a buyer
This metric is also a question to ask a vendor, and it is the sharpest one on Andrusko's list of pressure tests: what does year-three margin look like on mature customers?
A vendor whose margin never improves on long-standing accounts is running a labour business, and your renewal price will reflect that permanently. A vendor whose margin improves has been generalising, which means the thing they built for you is maintained rather than frozen.
Questions to ask a vendor has the rest.
Best for
- Diagnosing whether an embedded function is compounding or just delivering
- Deciding whether to hire more embedded engineers
- Pressure-testing a vendor on year-three margin
Avoid if
- You are in your first three deployments, where the number is still noise
Verify before you commit
- Pick one definition of attributable revenue and keep it fixed across quarters
- Confirm the trend is rising, not the absolute value against someone else's benchmark
- Pair it with shared versus custom code per deployment as the leading indicator
- If flat, check the loop, the reporting line, and whether templated accounts are being embedded on
Common questions
What is revenue per forward deployed engineer and why track it?
Revenue attributable to accounts served by embedded engineers, divided by the number of those engineers, over a rolling period. It is the single number that tells you whether you have a platform or a labour business, because it only rises if the platform is absorbing what the field learned.
What does it mean if the number is flat?
That the learning is not being converted into product. Each deployment starts near zero, so adding engineers adds revenue linearly, which is the definition of a labour business. a16z describes the end state as bespoke deployments impossible to maintain or upgrade, where revenue scales and nothing compounds.
What does a healthy trajectory look like?
The best public benchmark is the previous software generation. ServiceNow's gross margin at IPO was 63.2 percent, reaching 79 percent in 2024. Workday's was 54.1 percent, reaching 75 percent. Both climbed roughly 16 to 21 points as the services motion converted into product.
When is flat revenue per engineer acceptable?
Two cases. In the first year, when three deployments give you nothing to generalise across and the number is noise. And during a deliberate expansion into a new vertical, which resets the custom share because the domain models and connectors do not exist yet. State the expected recovery period so the dip does not become permanent.
What should you do if it is flat?
Do not hire more embedded engineers, which scales the problem. Check whether the productization loop has a cadence, an owner with authority and a stop rule. Check the reporting line for a structural incentive against generalising. And check whether you are embedding on accounts that should have been templated.
How does a buyer use this metric?
As a question: what does year-three margin look like on your mature customers? A vendor whose margin never improves on long-standing accounts is running a labour business and your renewal price will reflect that permanently. A vendor whose margin improves has been generalising, so what they built for you is maintained rather than frozen.
Related reading
Stop paying for headcount you no longer need
An hourly quote is a price for people and months. When most of the implementation is generated, that is a price for an input that has largely gone, and it quietly pays your supplier to be slow.
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure motion, not progress. Here is how we think about engineering output without the vanity metrics.
More in Commercials
How to price forward deployed engineering
There are four ways to price embedded engineering: time and materials, fixed scope, outcome, and bundled into a licence. Each produces different behaviour, and the behaviour matters more than the rate. Billable hours pay the vendor to be slow and to keep the engagement going. Fixed scope pays them to argue about scope. Outcome pricing aligns both sides and is hard to write. When AWS announced its own forward deployed engineering organization it said the work would be structured around shared goals and business results rather than billable hours, which is a standard worth holding every vendor to.
Outcome-based pricing for embedded engineering
An outcome you cannot measure on the day of signature is a hope with a payment schedule attached. A workable outcome passes three tests: it is observable rather than inferred, somebody named takes the measurement, and neither party can move the goalposts unilaterally. The most reliable outcome for an embedded engagement is the least exciting one, which is a defined system running in production for real users by a named date. Business-metric outcomes sound better and fail more often, because neither side fully controls them.
What forward deployed engineering costs
Two compensation figures for this role are traceable to a source. Levels.fyi reports Palantir forward deployed engineer total compensation in the United States with a median of $278,000 and a range from $185,000 to $631,000, read on 8 September 2026. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816. Everything else circulating is unsourced. Load one of those two for benefits, travel and unbilled time to get your input cost, then compare it against the cost of the deployment not happening.
Measuring forward deployed engineering
Measure four things: time from contract signature to production, the share of engagements that reach production, revenue per embedded engineer over time, and what came back into the product. Do not measure utilisation. Utilisation rewards keeping engineers on accounts, which is exactly the endless engagement this model fails into. The metric that matters most to a customer is time to production, and the metric that tells you whether you have a business is revenue per engineer rising rather than staying flat.
The contract for an embedded engagement
Before an outside engineer touches your repository, six things belong in writing: IP assignment on creation, scoped repository access rather than organization-wide, production access as a named exception with an audit trail, a production date, a handover date with a defined artefact, and subcontractor binding. The one people get wrong most often is the first: an NDA covers secrecy and does not assign ownership of what the vendor creates. Those are two separate clauses and you need both.