The eight things we score before an engineer meets your customer

Key takeaways

• Every vendor selling forward deployed engineers uses the same three adjectives, so the adjectives no longer carry information. The rubric underneath them does.
• A.Team scores eight criteria, from craft depth to enterprise fluency, on a computed 0 to 100 scale rather than a reviewer's impression, so two people scoring the same builder get the same answer.
• Craft is the floor, not the differentiator. Scoping judgement, adoption and enterprise fluency are where candidates who look identical on paper separate.
• A score is a filter, not a hire. It does not tell you whether someone is available, how they have trended over time, or whether they suit your product.
• Readiness for the work in general is not readiness for your stack. That gap closes before the engagement starts, with your team in the room.

The title is not the capability

The forward deployed engineer role went from niche to everywhere in about two years, and the supply of people who can genuinely do it did not move at the same speed. What moved instead was the labelling. Solutions engineers, technical account managers and professional services consultants have all been relabelled as FDEs, because the title is free and the capability isn't.

That's the reason a buyer's first instinct is now suspicion. If you've had ten vendors reach out this quarter promising embedded senior engineers, the eleventh promise carries no information. Adjectives have stopped working in this category.

What still carries information is the rubric underneath the promise.

What we score

We score every builder considered for forward-deployed work against eight criteria. The score runs 0 to 100, and it's computed rather than asserted, which matters more than the number itself.

Each one in full, and why it earns its place:

Craft depth. Can they actually build, at the level the work demands, in the stack the work lives in. This is the floor, not the differentiator, and it's the one most vendors stop at.

End-to-end delivery and ownership. Have they carried something from an ambiguous starting point to a thing running in production, rather than owning a slice in the middle of someone else's plan.

Production maturity. Experience with systems that have real users and real consequences. Pilots and proofs of concept don't count here, which removes a surprising number of otherwise strong AI CVs.

Scoping and judgement. Given an open-ended problem and an impatient room, do they produce a defensible plan. This is the criterion that separates a strong engineer from an engineer you can put in front of a customer unsupervised.

Reusability and product mindset. Do they build the second version while building the first. In forward-deployed work this is what stops every engagement being bespoke forever, and it's the difference between a contractor and someone who leaves capability behind.

Communication. Not presentation polish. Whether they can hold a room containing a sceptical customer engineer, a nervous account lead and a deadline.

Adoption and impact. Did the thing they built get used. It's the criterion most rubrics omit, because it's the one most likely to embarrass the person being scored.

Enterprise and SaaS fluency. Comfort with procurement, security review, legacy estates and change management. The last mile is mostly this, and technical brilliance without it produces an engineer who is blocked for six weeks and can't say why.

zoom_in

How the score is built

Two inputs. The first is experience data drawn from a builder's résumé, their LinkedIn and their profile on our platform. The second is a health score that accumulates from their actual history working through us: engagements, outcomes, the signals a network sees that a CV never shows.

Each criterion resolves through binary checks against those inputs rather than a human impression, so two people scoring the same builder get the same answer. The output is a ranking, and a shortlist comes off the top of it.

What the score doesn't tell you

A rubric you can't criticise isn't a rubric, so here are its limits.

It isn't availability. A high score means someone is ready for this kind of work, not that they're free next month. Those are different questions and conflating them is how vendors end up promising people they can't field.

It isn't a history. We calculate the score live from current data, and we don't yet store how a builder's score moves over time. That's a real gap and it's being closed, but today it's a snapshot.

It isn't an interview. It's a filter that decides who's worth your time. You should still meet them, and you should still say no.

Scoring gets you a shortlist. Your stack gets you a fit.

A high-scoring engineer is ready for forward-deployed work in general. They're not yet ready for your product, your deployment patterns, the three things your customer's environment does that nothing else does, or the failure modes your team already knows about.

That gap closes before the engagement starts, not during it, and it closes with your team in the room. The work is unglamorous: your architecture, your conventions, your escalation paths, the specific way your product fails when a customer's data is messier than the demo. An engineer who arrives already fluent in that is a different proposition from one learning it on your customer's time.

This is also where the ownership question gets answered honestly. Your team directs the work and owns the outcome. What we're accountable for is who arrives and how ready they are when they do.

What to ask anyone selling you FDEs

Including us. If a vendor can't answer these, the promise is doing the work the evidence should be doing.

• What's your definition of the role, in writing? If it's a paragraph of adjectives rather than criteria, it's a label.
• How do you assess against it, and is the assessment computed or someone's impression? Ask to see the criteria. Not the marketing version.
• How many people clear the bar, and how many of those are available right now? The second number is always much smaller than the first. A vendor who conflates them is telling you something.
• What happens between selection and day one? If the answer is "we send you a CV," you're buying a résumé, not readiness.
• Who owns the outcome? There's no wrong answer, but there's a wrong situation, which is when you and the vendor believe different things about it.
• What does this look like when it ends? Engagements that can't describe their own ending tend not to have one.

Ask us those and we'll answer them in a call. The rubric above is the version of the answer we can publish.

What to do next

Put the six questions above in front of whoever you are talking to this week, including us, and write the answers down. The vendor who can produce criteria in writing and tell you how many people clear them is answering a different question from the vendor who sends adjectives, and the difference shows up in the first two weeks, not the first call.

If you are scoping forward deployed work now, A.Team can walk you through the scorecard on real candidates rather than in the abstract, and we will tell you where the score runs out and your own evaluation has to start.