How to Measure FDE Teams: Metrics, ROI, and Unit Economics

Here's a made-up but familiar case. A forward deployed engineer spends four months inside a customer's claims team. The system goes live and the customer sends a thank-you note. Then the quarterly review comes around, and four people read the same project four ways.

Sales sees a deal that was in trouble and got rescued. Product sees sharp insight into what customers need. Engineering sees an expensive person writing custom code. Finance sees software revenue propped up by work that looks a lot like consulting.

All four are right. A useful scorecard holds all four views at once. Optimize one of them on its own and you bend the whole model out of shape.

Forward deployed engineers (FDEs) are engineers who work inside a customer's company to get a product running on the customer's real systems and data. This guide is for the people who run FDE teams. It gives you four groups of measures, a worked example of the cost math, and the metrics to avoid because they reward the wrong work. If you're an FDE, or interviewing to become one, there's a short section for you near the end.

The four parts of the scorecard

Part	Question	Core measures
Customer outcome	Did the customer's work improve?	Outcome delta, adoption, time to value
Delivery health	Did we ship safely and predictably?	Phase time, reliability, scope change, handoff
Product reuse	Did one deployment improve the next?	Reuse, productized patterns, engineering time recovered
Business economics	Was the value worth the capacity?	Protected revenue, expansion, contribution, capacity cost

No single number covers the whole job. A fast deployment that nobody uses failed. A happy customer who needs permanent custom engineering can still lose the company money. A reusable feature that misses the customer's goal is product work, not a successful engagement.

Part 1: Did the customer's work get better?

Start here. Going live and a happy customer are supporting evidence, not the finish line.

Outcome delta

During discovery, agree on the one operating number the project should move: how long a case takes, cost per case, error rate, conversion, resolution rate, analyst capacity, loss avoided, or another business result.

Outcome delta = post-deployment result − baseline result

Write down the starting number (the baseline), which users or cases you measured, the time period, and anything else that changed at the same time. A before-and-after number with no context hands the project credit it may not have earned. When lower is better, say so plainly when you report the drop.

Time to first value

Time to first value = date of first verified workflow benefit − engagement start date

This tells you more than the go-live date does. A system can be live and still not help anyone. Define "verified benefit" up front. For example, the first week the target users complete real work through the new flow.

Production adoption rate

Production adoption rate = active eligible users completing the target workflow ÷ total eligible users

Logins don't prove much. Count the behavior the system was built to change. When the system talks to other systems instead of people, count the share of eligible transactions or decisions that actually run through it.

Completion and fallback

Track how often the workflow finishes, and how often a person overrides it, falls back to the old way, gives up, or hits an error. Those numbers tell you whether people trust the system and whether the odd cases are handled safely.

How sure you are the project caused it

Add a plain judgment: high, medium or low confidence that the deployment caused the change. Note anything else that moved at the same time, like a new process, staffing changes or a shift in the market. This keeps a precise-looking dashboard from claiming more than the evidence shows.

Part 2: Did the team ship safely and predictably?

Time in each phase

Measure qualification, discovery, prototype, validation, rollout and stabilization separately. One total hides where the work got stuck. Long discovery can be normal in a regulated industry. Repeated security delays are a different story. They usually mean the product is missing a control customers need.

Scope change

Scope change rate = material additions after scope approval ÷ total committed deliverables

The goal isn't zero change. You keep learning after the deal closes. What this number exposes is weak qualification, committing too early, and sales promises made before anyone from delivery looked at them.

Production quality

Track uptime, speed, evaluation scores, bugs that reach users, security findings, incidents, recovery time and cost per transaction, wherever each applies. Hold field work to the same engineering standard as the core product, while allowing for the customer's environment.

Handoff health

Thirty days after the FDE hands the system to its long-term owner, check:

Can the long-term owner deploy and operate the system?
Are alerts and incidents reaching the correct team?
Is the FDE still the default contact?
Is documentation current?
Has adoption remained stable?

Give each handoff a red, amber or green rating, with written evidence behind it. A handoff that keeps slipping is often a capacity problem dressed up as good customer care.

Estimates versus actuals

Compare how long you thought each phase would take, and how much engineer time it would need, against what actually happened. Don't use the gap to punish honest uncertainty. Use it to qualify better and to spot friction that keeps coming back, which should become product or tooling.

Part 3: Did this deployment make the next one easier?

This is where FDE work stops being one-off project delivery. The work should compound.

Reuse rate

Reuse rate = engagements using an existing FDE-built component or playbook ÷ total eligible engagements

Be careful about which engagements count as eligible. A healthcare identity pattern may not apply to a manufacturing deployment. Count too many engagements as eligible and specialized reuse looks weak even when it's working.

Productization yield

Track field patterns that become:

Core product capabilities
Extension points or APIs
Connectors and templates
Evaluation suites
Security and deployment tooling
Documentation and enablement

Count accepted and shipped separately. A long backlog of requests doesn't count.

Time saved on future deployments

Estimate how many hours or weeks a reusable piece should save, then measure what it actually saved. If a connector cuts discovery and build from six weeks to three, that frees up engineering time and gets the next customer to a result faster.

Core engineering time recovered

Compare how much time core product engineers spend on customer deployments before and after you set up the FDE team. Don't aim for zero. Healthy work between the field and the product still needs core engineers involved. The aim is fewer surprise interruptions and more deliberate ownership.

The repetition alarm

Watch for the same workaround showing up across engagements. F-Prime Capital argues that when a large share of deployments needs heavy FDE effort, the problem has probably moved from go-to-market to product design. Treat any precise percentage from an outside framework as a reason to dig in, not a law. Your own repetition trend is the signal that matters.

Part 4: Was it worth the engineer's time?

Fully loaded FDE cost

Include salary, bonus, payroll costs, equity planning assumptions, benefits, recruiting, management, travel, cloud or tooling, and allocated support. Finance should decide how to count this once and apply it the same way every time.

Engagement contribution

Engagement contribution = protected revenue + attributable expansion + paid services + recovered capacity value − allocated FDE cost − incremental delivery cost

This is a management view, not accounting guidance. Keep the assumptions where people can see them. Protected revenue and expansion are probabilities, not cash in hand.

Retention and expansion with and without an FDE

Compare renewal and expansion for accounts that had FDE support against similar accounts that didn't. Account for size, maturity, product fit and how much attention each account got. FDEs usually get assigned to the hardest or most valuable customers, so a naive comparison can mislead in either direction.

Cost per phase

Phase capacity cost = FDE weeks used × fully loaded weekly cost

Use this while you decide whether to take an engagement. A valuable account can still be a bad engagement if the first result eats too much engineer time compared with the revenue and the learning it brings.

Where the cost shows up

Decide whether FDE salaries sit in cost of revenue, sales expense, research and development, or get split by activity under your accounting policy. The point is that people can see it. Pricing that looks like software shouldn't hide delivery that takes a lot of human labor from the people making operating decisions.

Unit economics don't require billing FDEs by the hour. They require knowing where the time went, what outcome it produced, and whether the next deployment got easier because of it.

A worked example: one FDE for one year

Here's a made-up company deciding whether one FDE was worth it over twelve months. These figures are illustrative, not benchmarks.

Costs

Fully loaded compensation: $290,000
Travel, tools, and incremental infrastructure: $60,000
Management and shared support allocation: $50,000
Total annual cost: $400,000

Expected value

Two at-risk $200,000 contracts with a 40 percentage-point improvement in expected retention: $160,000
Expansion attributable to successful deployments: $220,000
Recovered product-engineering capacity: $140,000
Reusable connector expected to save $35,000 across four future deployments: $140,000
Total expected value: $660,000

Result

Expected contribution = $660,000 − $400,000 = $260,000

Illustrative ROI = $260,000 ÷ $400,000 = 65%

Now change two assumptions. If only half the expansion happens and the connector gets reused twice instead of four times, expected value drops by $180,000 and ROI falls to 20%.

That swing is the point. Leadership needs to know which assumptions the whole team depends on.

Plan capacity by phase, not by account count

An engineer with three accounts can be bored or drowning, depending on what stage each account is in. So give each phase a weight. Start with internal planning weights like these, then adjust them from real work:

Qualification and discovery: 0.25 FDE
Active build: 0.75 FDE
Rollout and stabilization: 0.5 FDE
Mature advisory support: 0.15 FDE
Protected productization and learning: 20% of total capacity

Say an engineer has one active build, one rollout and one mature account. That's already 1.4 FDE of planned work before any productization time. They're over capacity. The model forces a decision: narrow the scope, change staffing, delay an engagement, or hand off the mature work.

Track context switching and travel separately. Two half-time engagements often cost more than one full-time engagement, because each one brings its own meetings, environments, stakeholders and urgency.

Metrics that reward the wrong work

Each of these sounds reasonable. Each one, used as the main measure, pushes the team somewhere you don't want it to go.

Metric	What goes wrong	Use it for
Utilization as the main KPI	Rewards keeping an engagement alive and punishes the productization that would cut future work	Capacity planning, not the definition of value
Closed revenue	Commission-like incentives encourage overpromising and quick custom fixes	Context. Production adoption and lasting value are safer main measures
Customer satisfaction alone	Customers can love a responsive engineer while barely using the product	Pair it with usage and outcome evidence
Lines of code or features shipped	The best call is sometimes configuration, a smaller scope, a product fix, or walking away from a bad engagement. Volume rewards needless complexity	Not a performance measure
Number of active accounts	Ignores phase and difficulty, rewards shallow involvement and hides overload	Replace with phase-weighted capacity
Go-live count	A deployment that doesn't last, doesn't get handed off, or doesn't change how work gets done isn't a success	A phase milestone, not a result

A monthly scorecard for leadership

Keep the portfolio view short:

Qualified engagements by phase and capacity
Median time to first value and trend
Production adoption by engagement
Customer outcome movement and attribution confidence
Reliability and critical risk exceptions
Handoff status and overdue transitions
Reusable assets adopted in new deployments
Product patterns accepted and shipped
Protected revenue and expansion with assumptions
Team load, travel, attrition risk, and hiring need

Review the exceptions and the decisions, not every activity. The scorecard should tell you where to invest, where to stop, what to productize, and whether the model is getting better.

Not everything moves at the same speed. Check each engagement's evidence at each phase gate, delivery risk weekly, and the portfolio monthly. Retention, expansion and reuse take longer to show up, so review those quarterly.

If you're the engineer being measured

Ask how the team is measured before you accept an FDE offer. If the answer is utilization, ticket count or closed revenue, expect pressure to keep engagements open and to say yes to custom work. If the answer includes adoption, handoff and reuse, the team is set up to let you finish a project and move on to the next one.

Once you're in the job, keep your own record for each engagement: the baseline number, adoption after launch, the handoff date, and anything the next deployment reused. That's the evidence that speaks for you in a review. The FDE interview guide covers what else to ask, and the FDE career path covers the role itself.

What to read next

Pair this scorecard with the FDE engagement playbook, which walks one engagement from discovery to production, and the team design guide. If the numbers already look bad, why FDE teams fail has a 30-day recovery plan.