Measuring forward deployed engineering

Most measurement of embedded engineering functions is borrowed from professional services, which is why it drives the wrong behaviour. Utilisation and billable hours were built to run a business that sells hours, and importing them unchanged into a function that is supposed to build a platform imports the wrong incentive along with the spreadsheet. Here is what to track instead.

The four that work

Time from contract signature to production. Not from the start of work. From signature, because the gap between contract signature and somebody actually 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 takes in 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.

Track this rate by cause of failure, not just as a single percentage, because the two most common causes call for different fixes. An engagement that stalls because the customer's environment turned out to be more complex than scoped points at the discovery phase needing more time before commitments are made. An engagement that stalls because internal approval never came points at a sales or contracting problem that has nothing to do with the engineering. Lumping both into one number tells you that something is wrong without telling you which part of the organization needs to change.

Revenue per embedded engineer, over time. The business-model measure. It should rise, because the platform takes in custom work and each engineer handles more accounts. 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 business.

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

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 no reusable work is building up. If you track it at all, track it as an upper limit, not a target.

Billable hours. The same underlying 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 released a change unaided.

Lines of code shipped, or story points closed. These measure activity, not the two things that matter: whether the work reaches production and whether it generalises. An engineer who writes a large amount of custom code that never gets reused looks productive on this metric and is quietly building the dependency problem this whole model exists to avoid. If a function tracks a metric like this at all, it should be a secondary check on individual output, never a target reported upward as a measure of the function's health.

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, custom work at customer sites is growing faster than the platform.

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.

Measure it properly, because a shallow version of this metric hides the exact problem it is meant to catch. "The handover happened" is not the same claim as "the customer's team is running the system unaided a quarter later." A handover can happen on schedule, on paper, with a training session and a document, and the customer's team can still be calling the vendor every week months later because nobody actually transferred the operational knowledge. The quarter-later check is what separates a real handover from a scheduled event with the same name. Handover and exit covers what the test for a real handover looks like.

What good measurement discipline looks like over a full year

A function that has this right produces a short, consistent report every quarter rather than a different set of numbers each time somebody asks how things are going. The four core metrics appear in the same format every quarter, tracked as a line on a chart rather than restated as a fresh snapshot, so a reader can see the trend without needing last quarter's report open next to this one.

The discipline that makes this possible is deciding the metrics and their definitions before the first deployment, not after the first awkward conversation about whether the function is working. A definition changed midway through the year to make a number look better is the single fastest way to lose the credibility that makes any of this reporting worth doing. If a definition genuinely needs to change, say so explicitly in the report the quarter it changes, and show both the old and new numbers side by side for at least one quarter so the trend line is not silently broken.

Do not trade speed for stability

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

Google's DORA research, which has studied software delivery for over a decade, finds that the strongest teams release more often and cause fewer failures 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 was released this week, progress against the production date, and an honest, current 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 other outcome metrics on this page do.

The one-line test

If your metrics would look better on an engagement that never ended, they are simply the wrong metrics to be using at all.

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

Run the test against your own current reporting before adopting anything on this page. If the metrics your function reports today would all look fine, or even flattering, on a customer who has been dependent on the same two embedded engineers for years with no handover in sight, that reporting is measuring the wrong things, whatever it happens to say this quarter.