Revenue per forward deployed engineer

One number, tracked as a trend over multiple quarters rather than read once. It answers a question most companies running this model avoid asking out loud, because the honest answer sorts them into one of two different kinds of business with two different valuations.

What to calculate

Revenue attributable to accounts served by embedded engineers, divided by the number of embedded engineers on those accounts, over a rolling period.

Keep it simple and keep it consistent over time. 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, on a rolling basis. Monthly figures change too much to read as a signal, and annually is too late to act on if something has gone wrong.

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 rises.

If it is flat, the learning is not being turned into product. Each deployment is starting with almost nothing reused, and the margin you spent bought a delivered project rather than a lasting capability. a16z's Marc Andrusko describes that end state as bespoke deployments impossible to maintain or upgrade, with revenue growing and no reusable work building up.

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.

The mechanism is worth stating in full, because the number by itself does not explain why it rises. Every embedded engineer who ships something at a customer site learns two things: a fact about that customer's environment, and a fact about what the platform is still missing. The productization loop is what turns the second fact into a capability every future customer gets for free. When that loop runs, each new deployment starts closer to finished, the engineer spends less time on work that has been done before, and the same engineer can therefore take on more accounts within a year. Revenue per engineer is the number that shows this happening from the outside, without needing to inspect a single codebase.

What a healthy direction 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 below the 80 percent software investors treat as normal, and they rose by 15.8 and 20.9 percentage points as the early services work turned into product. That rise is the whole argument. 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 takes over what engineers at customer sites were doing by hand.

Neither company reached its healthy margin quickly, and the pattern is instructive for how to read your own curve. A company that expects a straight, steady climb from its own starting number will be disappointed by the reality, which is closer to a series of steps: a period of near-flat margin while a capability is being built, followed by a jump once it ships and starts serving multiple accounts, followed by another near-flat period while the next capability is built. If you are two quarters into a flat period and you know exactly what capability is being built and when it ships, that is a normal step. If nobody can name what is being built, it is the warning sign described below wearing a patient face.

When flat is fine, briefly

Two cases.

The first year. With only three deployments there is nothing to generalise across yet and the number means little. Start tracking it anyway and do not react to it.

A deliberate market expansion. Entering a new industry 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 warning sign.

What to do when it is flat

Do not hire more embedded engineers. This is the instinct and it makes the problem bigger. More engineers on more accounts producing more custom code makes the maintenance burden worse and the margin no better.

Check whether the productization loop exists. Is there a fixed schedule, a named owner with authority to move work into the platform, 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 served with a template. 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 keep this number low by themselves.

Run through these checks in order rather than jumping to whichever one is most comfortable to discuss. A team will often reach for the account-selection explanation first, because it does not implicate anyone's process, when the real cause is that the productization loop has no named owner. Check the loop and the reporting line before checking account fit, since those two structural causes are both more common and more expensive to leave unaddressed.

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 stop rising 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.

The lag matters most at exactly the moment leadership wants a fast answer. A board asking why the number has not moved this quarter is asking about a cause that, if the loop is healthy, happened two or three quarters ago and has already been visible on the leading indicator since. This is the strongest argument for reporting both numbers side by side rather than revenue per engineer alone: the leading indicator gives an honest answer to "what is happening right now," while the lagging one gives an honest answer to "did the last correction work."

For a buyer

This metric is also a question to ask a vendor, and it is the most useful one on Andrusko's list of 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.

Ask the question with a specific reference point rather than in the abstract. Naming one of your own accounts that is two or three years into the relationship and asking directly whether the vendor's cost to serve it has fallen forces a concrete answer rather than a general claim about efficiency. A vendor who can only answer in principle, and not for a real account, has not been tracking the number internally either, which is itself informative about how seriously they take the distinction this page is built around.

Questions to ask a vendor has the rest.