Don't measure an FDE by effort. Measure reuse.

Hours worked is the wrong number for judging a forward deployed engineer. The number that decides the value of forward deployed engineering is how much of what got built on workflow one shows up again on workflow two.

Ask a vendor that question and the answer tells you what you are buying. A specific answer names components. A vague answer describes a methodology, and a methodology is what consulting sounds like when it wears an engineering title.

Why reuse is the economics

An FDE model has two possible shapes. In the first, each deployment costs what the last one did. Revenue grows with headcount and margins stay flat, and the customer pays for the vendor's education one engagement at a time.

In the second, hours per deployment fall while deployments rise, because the team learned the domain and encoded it. The customer's second workflow costs less than the first, and the third less again. Only the second shape compounds, and from inside a single engagement the two look identical unless someone counts.

For a buyer this is a pricing question. The first shape sells effort. The second sells reuse, which gets cheaper each year.

The scorecard

Neej Gore, chief data officer at Zeta, proposed four metrics for running an FDE organization in VentureBeat, then added a fifth. They work as well from the buyer's side of the table. For each one, ask the question, then score the answer specific or vague.

1. Engineers per live workflow. Ask how many engineers it takes to keep one workflow in production. Good: the ratio falls as workflows are added. Warning: one engineer per workflow, and the ratio stays there.

2. Engineering hours per deployment. Ask what the last three deployments in your vertical cost in hours. Good: falling, deployment over deployment. Warning: flat, which means you are funding a lesson they already had.

3. Time to value by vertical. Ask how long it took from kickoff to the first production decision on the last two engagements in your industry. Good: shorter each time, with dates. Warning: "it depends on the client."

4. Share of implementation reused rather than rebuilt. Ask what share of the last engagement was new code. Good: a number, and it is falling. Warning: the vendor has no number.

5. Productization lag, Gore's fifth: the time between a discovery in the field and a tested capability available to the next customer. Ask when the field last taught them something and how long until it shipped. Good: weeks, with an example. Warning: it lives in a notebook.

Three or more vague answers and you are talking to a consultancy. That still works for a first project, if you price the engagement as consulting and expect the second project to cost what the first did.

The example worth keeping

Gore describes a large telecom deployment where the model's definition of a high-intent customer contradicted the criteria the retention team used. Those criteria came from years of which offers worked, on which tenure bands, in which regions, and the team had written none of it down. An engineer had to extract that logic from experienced staff before the system could be trusted with a decision.

That extraction is the job. It is also the step that gets cut when a project runs late, and cutting it is how systems ship and then get ignored by the team they were built for. The reuse metric catches the cut. Rules extracted once and encoded show up as fewer hours on the next deployment in the same vertical. Rules skipped show up as a rebuild.

Two proposals, scored (illustrative)

A hypothetical, not a client case. Two firms propose the same invoice-matching build for a distributor.

Firm A quotes 600 hours and describes a discovery phase and a phased rollout. Asked what carried over from its last three distributor engagements, it names a framework and a team. Asked what share of the last engagement was new code, it does not know. Score: five vague.

Firm B quotes 400 hours and names the components it already has, the three-way match logic and the exception queue among them. Asked what share of the last engagement was new code, it says a third, down from half the time before. Score: four specific, one vague on time to value.

Firm B is cheaper because the learning already happened, and it will be cheaper again next year. Firm A is selling effort, and effort does not get cheaper.

The sixth number for mid-market buyers

Gore writes for people running FDE organizations. I would add one number for companies under a thousand employees: the share of what was built that your own team can run after handover. If the answer is none of it, you rented a result, and your internal reuse is zero by definition.

If you have an FDE proposal on your desk, send me the vendor's answers to the five questions and I will send back how I would score it and what I would ask next.