The FDE Scorecard: Count What Stayed, Not Who Was Sent

The industry spent this week counting forward deployed engineers.

On October 2 Anthropic launched Claude Frontier Academy: $100 million to train 10,000 of them by the end of 2027. (It calls them Frontier Deployed Engineers. Same initials.) The day before, Karthik Sonti, Erik Farr, and Priya Bains at AWS published three free training pathways and two FDE credentials for partners. Matt Ashare at Channel Dive put both in one story on October 5 and added the supply side. Gartner's Mukul Saha estimates roughly 2,000 engineers fit the job description today. DXC Technology promised tens of thousands of Claude-trained engineers in June and had 86 ready to deploy a month later. Then on October 7 Atlassian introduced its team through Paavany Jayanty, who leads it in the US: 46 forward deployed engineers, heading for 100.

10,000. 2,000. 86. 46. Every one of those is a count of people.

Nothing wrong with counting people. But a badge tells you the engineer can do the work, and nothing published this week tells you whether an engagement worked. AWS came closest. Its third pathway is called Prove, and the question printed next to it is "Can the customer trust it in production?" Good question. It gets asked of the builder, in an AWS-provisioned environment, and the post is clear that the credential is "based on what builders can demonstrate, not what courses they've completed." Somebody still has to ask it of the deployment, at the customer, at day 60.

This is part 7 of The FDE Transition. Part 6 was month two, when the FDE leaves and customer success takes the account. This part is the scorecard: what to measure about the seat, and what to stop counting.

The short version

The week's news measures supply: how many FDEs exist, how many are being trained, and who holds a badge. The scorecard has to measure what the customer kept and what the product learned. I'd run four numbers, each as a trend against your own last quarter, because no benchmark exists. Time to landing is days from signature to the first change the customer makes without you. Reversal rate is the share of go-live workflows the customer switched off, overrode, or routed around by day 60. Generalization rate is the share of handback packets that got a written decision in two weeks, and the share of three-customer patterns that shipped. Hours per deployment, for the same class of customer, should fall every quarter. The first two go on the engineer's scorecard. The last two go on the function's and on product's. Off the scorecard entirely: headcount and badges, utilization, revenue per FDE, pull request counts, and CSAT on its own.

Three vendor lists, and one honest sentence

Three vendor posts have tried to write this scorecard since May, and they're worth reading side by side.

Srikrishnan Ganesan, co-founder of Rocketlane, splits the role into types and gives each a target. For deployment engineers, $250K to $400K in ARR per FDE. For a pod of four or five doing R&D services, 150 or more PRs a quarter. Perspective AI's playbook picks productization rate, features shipped to core product per engagement, with a target of at least one by day 90: "This is the master metric." Aditya Santhanam, co-founder and CTO of Entrans, lists ten, from time to value through utilization, adoption, and customer satisfaction.

These are firms' own suggestions, not measurements, and each firm sells something next to the list. Ganesan says the quiet part himself, and it's the best sentence in the genre: "There is no industry-wide benchmark." He calls his ranges provisional targets, not standards.

I'd start there. Nobody has the benchmark, so I'm not going to hand you thresholds. What I can give you is four numbers that each come off a page this series has already asked you to write. If you have the pages, you have the scorecard.

Four numbers

Time to landing. Days from signature to the day the keys line on the month-two page has a customer's name on it and that person has used it: changed a prompt, a rule, or a threshold without calling you, and watched the rows run. Not time to go-live. Go-live is the vendor's date, the day we switched it on. Landing is the customer's. Every time-to-value metric in the three lists stops at first outcome or production. Gartner's phrase from last week, "unable to evolve it on their own," describes the stretch between those two dates. So measure the stretch.

Reversal rate. Of the workflows that were live at go-live, the share the customer switched off, overrode, or routed around by day 60. You already collect it, twice: in the day-60 reversal update from part 3 and on the watch list from part 6. Read it next to the floor, whether the customer's eval rows still pass at the go-live rate. Atlassian's post says its team has put more than 80 agents into production. That post is an introduction to a team and I'm not faulting it for missing a scorecard. But it's the count every vendor leads with, and I'd lead with it too. The reversal rate is the question that comes after it. Eighty went on. How many are still running the way they shipped?

Generalization rate. Two parts. Of the handback packets sent to product, the share that got a written decision within two weeks. And of the patterns that reached a count of three customers, the share that shipped as product or configuration. Vinoo Ganesh wrote the reason at Latent Space: "An FDE engagement that ends with one delighted account and nothing changed upstream has failed at the only thing the role exists for." Gartner's second prediction from September 29 is this number, forecast for the whole market: through 2028, less than 20% of FDE engagements will turn recurring customer needs into core product.

Here I part ways with Perspective's target. One feature into core per engagement by day 90 is a quota for shipping one customer's accident to everybody. The loop chapter has the rule: one customer's workaround is a workaround, three is a pattern. Kill is a real decision and it counts. So count decisions, and count shipped patterns only once the count is three.

It's also a shared number. The FDE controls whether the packet went out on time. Product controls the answer. Put it on both scorecards or it lands on neither.

Hours per deployment. FDE hours for the same class of customer, quarter over quarter. The economics chapter says it should fall, because that's the product absorbing what the field learned. This one belongs to the function, never to an individual, or you've just told your engineers to leave early. It's also the only number here that says anything about this week's news. Whether the market needs 10,000 depends on whether this line slopes down.

What to stop counting

Headcount and badges. They're inputs. I'm glad the training exists, and Anthropic's version ends in a 12-week residency on a real use case, which is the right shape. It still certifies a person.

Utilization. Perspective's playbook says "a high billable-utilization number is actually a warning sign." Santhanam sets a band instead: "60% to 75% customer-facing time." I'd take it off the individual scorecard altogether. A utilization target of any size pays for hours at the customer, and the fourth number says those should fall.

Revenue per FDE. Part 5 called an accelerator on deployments shipped a quota with a lab coat on. ARR per FDE is the same coat.

Pull request counts. Part 4 made a harness PR a priced event, because it changes the cost per case for every customer on that harness. Pay by the PR and you'll get more tools on every call.

CSAT on its own. Santhanam lists it and names the risk in the same breath: "The risk is becoming a yes-person." A happy customer at day 30 is mostly measuring that the FDE is still in the room.

I worked on experimentation at Airbnb, and the rule I'd carry over is general. If the person being measured can move the number without moving the outcome, the number will move. Nobody has to cheat. They just do what the scorecard asked.

Who reads it

The engineer's own scorecard has two of the four, time to landing and reversal rate, plus one hygiene line: packets sent on the three dates. The function's has all four. The product owner who reads the handback carries the decision clock.

And the person who reads it monthly is the FDE's manager, who per the org design chapter doesn't carry a bookings number. Comp stays where that chapter put it, on the customer's outcome and the renewal. The scorecard explains why the outcome moved. I wouldn't wire it to pay.

What this means in the seat, and at the top

If you're the FDE: start the landing clock yourself. Write down the date the customer first changed something without you. If there isn't one, that's your next two weeks.

If you run product: your number is the decision clock. Packets in, written answers out, inside two weeks.

If you run the company: when the board asks how many FDEs you have, answer with hours per deployment.

One thing to try this week: take your last three deployments that went live more than 60 days ago. For each, write four things. Days from signature to the customer's first unassisted change, or "never." Workflows live at go-live, and how many still run as shipped. Handback packets sent, and how many got a written decision. FDE hours. Then count the cells you can't fill. Those blanks are the scorecard you're running today.

Sources: Anthropic, "Claude Frontier Academy: $100M to train 10,000 engineers" (October 2, 2026) · Karthik Sonti, Erik Farr, and Priya Bains, "New FDE Pathways For AWS Partners: Get Ready for Production Agentic AI Delivery," AWS Partner Network Blog (October 1, 2026) · Matt Ashare, "Anthropic, AWS step up FDE push," Channel Dive (October 5, 2026), with Mukul Saha's estimate · Atlassian, "Meet the Forward Deployed Engineer," Inside Atlassian (October 7, 2026), with Paavany Jayanty quoted · Vinoo Ganesh, "The Rise of the Forward Deployed Engineer, and How To Do the Job Right," Latent Space (September 12, 2026) · Srikrishnan Ganesan, "The FDE Blueprint: Build and Scale a Forward Deployed Team," Rocketlane (May 21, 2026) · Perspective AI Team, "The Forward Deployed Engineer Playbook: How to Structure, Run, and Scale an FDE Function in 2026" (June 12, 2026) · Aditya Santhanam, "Forward Deployed Engineer Metrics: How to Measure FDE Performance and ROI," Entrans (September 29, 2026) · Mukul Saha, "Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028," Gartner (September 29, 2026)

Part of the running argument on AI Product Management: once building is cheap, the scarce work is deciding what gets built for everyone, and the scorecard is how you find out whether the field's work ever got that decision.

Related answer: How do you measure a forward deployed engineer?