What forward deployed engineers must master

A forward deployed engineer walks into a customer site alone and moves an AI system from working demo to production use. They write code, understand the business, and will tell a customer when a path is wrong. Five distinct capabilities sit behind those actions. Lose one and the system stalls.

We recruit engineers and help customers evaluate teams with this framework. Stop asking 'can you write Python?' That's threshold knowledge, not an assessment.

A counterexample first

Last year we took over a quality inspection project for a manufacturer. The previous team was strong, their model's accuracy was publication-grade. Three months after launch, line operators still manually checked every decision. Why? The model showed a confidence score of 0.73 when it flagged a suspected defect. No operator knew whether 0.73 meant stop the line or keep going. The engineer understood the model. He didn't understand what someone standing in front of a conveyor belt, making three thousand daily judgments, actually needed.

The technology was sound. The deployment failed. An FDE's value lies in the four things that have nothing to do with technical correctness.

Five capabilities, one table

Capability	One-Line Definition	Without It	How to Verify
Domain Understanding	Fluent in the customer's industry jargon, workflows, and KPIs	You build something technically sound but operationally useless	Have them walk through the customer's day. Every step they miss is where the system will fail
System Integration	Connect the model to existing IT infrastructure and keep it stable	Blocked by permissions, data pipelines, deployment environments that won't budge	Ask how they'd handle dirty data and edge cases
Customer Communication	Translate between technology and requirements; manage expectations and scope	Scope creep spirals, or you promise things you can't deliver	Do they have the spine to say 'we'll do that later' to a customer's face?
Security Posture	Assume data will leak, design the architecture to prevent it	One data breach, the whole project is radioactive	Ask: how do you enforce RAG permission boundaries?
Product Instinct	Know which features actually get used and which are noise	You ship ten unused buttons for every feature people click daily	Can they kill a feature they wanted to build?

Domain understanding: listen first, code second

An FDE's first week should not involve a keyboard. They should be in conference rooms, on the production floor, behind the counter, watching real people work. The compliance rhythm in finance, the logic of medical records, the scheduling demands in logistics don't appear in requirement documents. They live on site.

The test is simple: have the candidate describe the customer's day using their language. Skip a step and that's where the system breaks.

System integration: between demo and production lies a swamp

In demo, data is clean and traffic is predictable. No one fights for permissions. Production inverts all of that. Exceptional FDEs handle the messy details: legacy data with missing fields, cross-system identity verification, retry logic for 2 a.m. batch jobs.

A RAG system works fine on slides. The real test is a corrupted 2018 scanned PDF that your system has to handle anyway. Integration isn't a bonus. It's what forward deployment actually means.

Customer communication: the most underrated, hardest to teach

This is where we make mistakes. Strong technologists hear 'the customer wants this' and treat it as fixed. Scope balloons. Delivery slips.

A good FDE does something counterintuitive: they convince customers to do less, to their face. They say 'that feature will tank adoption, let's skip it' and have reasons to back it. Communication isn't about sounding polished. It's about managing expectations, holding scope, and knowing when to stop. Ask 'have you ever told a customer no?' in an interview. You'll see it in their eyes.

Security posture: assume everything will leak

Enterprise AI systems handle the most sensitive data: client lists, financials, medical records, contracts. Security posture isn't a pre-launch checklist. It's an assumption baked into your first architecture: 'this data will be seen by someone who shouldn't see it,' then you build backward from there.

RAG leaks are common: dump the whole knowledge base into a vector store and forget that different roles shouldn't see the same documents. Sales teams surface HR salary records. Permission boundaries need to sit at the retrieval layer, not in a prompt asking the model nicely. Ask an engineer: 'How do you handle RAG permissions?' You'll learn if they get it.

Product instinct: knowing what not to build

The first four capabilities get your system live. Product instinct determines whether anyone uses it. On the same budget, some ship ten unused buttons. Others build one feature used every day. The difference: an FDE stands in the user's shoes and separates real needs from conference room ideas.

In that quality inspection case, the fix wasn't higher accuracy. It was changing 0.73 to 'recommend stopping line. Two similar false positives today.' Same model, one human-readable sentence, and manual checks drop sharply. That's product instinct: knowing what not to build and what one sentence to add.

These five: hiring standard and guard rail

We're not hunting for someone who maxes out all five, those people don't exist. We want someone who passes on all five, excels in at least one, and we use the team to fill gaps. Use this table the same way for your team or external partners: whatever's missing, that's probably where the system stalls.

A beautiful demo doesn't count. Real deployment is when people on site still open it every day after the engineer leaves.