Measuring forward deployed engineering

Most measurement of embedded engineering functions is borrowed from professional services, which is why it drives the wrong behaviour. Here is what to track instead.

The four that work

Time from contract signature to production. Not from kickoff. From signature, because the gap between signature and somebody starting is real and it is yours to fix.

This is the number a customer experiences, and it should fall across successive deployments as the platform absorbs what earlier ones learned. A flat signature-to-production time over eight deployments means nothing is being reused. It is also the number a16z's Marc Andrusko suggests investors ask about directly: how many engineer-months from contract signature to production.

Share of engagements that reach production. Count started engagements and count the ones running in production for real users. This is the honest version of a success rate, and it should be embarrassing at first.

Compare it against the context: MIT NANDA reported in July 2025 that 95 percent of generative AI pilots produced no measurable profit-and-loss impact, from 52 executive interviews, 153 leader surveys and 300 public deployments. If your rate is well above that, it is your strongest sales asset and you should be able to prove it.

Revenue per embedded engineer, over time. The business-model measure. It should rise, because the platform is absorbing custom work and each engineer covers more ground. Its own page covers the detail, and the summary is that flat revenue per engineer with growing custom work means you are running a services shop.

Capabilities returned to the product. Count them, per period, with a name attached. This is the output of the productization loop and the only direct measure of whether the margin you spent bought anything durable.

The three that look useful and are not

Utilisation. The standard professional services metric and the most damaging one here. It rewards keeping engineers on accounts, which is the endless engagement. A function at 95 percent utilisation is a function with no time to generalise, which means it is compounding nothing. If you track it at all, track it as a ceiling not a target.

Billable hours. Same problem, and it also pays the vendor to be slow. How to price covers what that does to behaviour.

Customer satisfaction alone. A customer whose engineers never learned the system and who now depends on you is frequently delighted. Satisfaction is worth knowing and it does not distinguish a successful deployment from a comfortable dependency. Pair it with whether the customer's own engineer has shipped a change unaided.

Two more worth tracking quietly

Share of shared versus custom code per deployment. Should trend toward shared. If the custom share grows with each account, the platform is losing to the field.

Handover completion rate. The share of engagements where the customer's team took the system over on the agreed date and still runs it a quarter later. This is the metric that detects the dependency failure mode, and almost nobody tracks it.

Do not trade speed for stability

Worth stating because the instinct in an embedded engagement is to slow down for safety in somebody else's production environment.

Google's DORA research, which has studied software delivery for over a decade, finds that the strongest teams ship more often and break things less at the same time. Speed and stability rise together rather than trading off. The mechanism is the verification, not caution.

In this context that means the way to move quickly inside a customer's environment is better checks rather than fewer changes. Generated code is not secure by default, so if a model is writing it, the checks have to be derived from the specification and graded independently of the model that produced the code. That is eval-driven development, and it is what makes a fast embedded engagement safe rather than reckless.

What to report, and to whom

To the board or leadership: signature-to-production time, share reaching production, revenue per engineer, capabilities returned. Four numbers, tracked as a trend rather than a snapshot.

To the customer: what shipped this week, progress against the production date, and the honest list of what has been discovered that changes the plan. Not utilisation, not hours.

To yourself, weekly: the time split per engineer against the roughly 20 percent customer-facing and 80 percent building that First Round Review describes. It is the earliest warning that an engagement is going wrong, and it moves before any of the outcome metrics do.

The one-line test

If your metrics would look better on an engagement that never ended, they are the wrong metrics.

Every measure on the recommended list gets worse when an engagement drags: signature-to-production rises, revenue per engineer flattens, handover completion falls. Every measure on the discouraged list gets better. That is the whole reason to choose between them deliberately.