What makes a good Forward Deployed Engineer?

Forward deployed describes an engineer working close to a customer’s workflows and operating conditions. Some projects require time on site; others rely on regular joint development. The core responsibility is technical ownership across the problem, code, data, users and operation of the solution.

These boundaries vary by company. Databricks’ June 2026 announcement places FDE work within its Professional Services approach, and Vercel’s listing also sits in that organization. When assessing a candidate, ask about actual implementation and delivery responsibility rather than relying on the team’s name. Databricks · Vercel

OpenAI’s role description connects development with production adoption and workflow impact. Anthropic’s Staff FDE listing emphasizes architectural direction and handing over systems that customers can operate. Palantir highlights breaking down open-ended problems and considering how technical decisions affect users. OpenAI · Anthropic · Palantir

Our interpretation is that a strong candidate needs depth in one area and enough breadth to work across a customer engagement. Expecting expertise in every technology is unrealistic. Knowing the limits of one’s expertise and bringing in the right specialist at the right time is a more useful requirement.

Anthropic’s Claude Frontier Academy announcement of 2 October 2026 combines a simulated enterprise application, practical assessment and a period of work on real projects. Its title, Frontier Deployed Engineer, should not be assumed to be a standardized equivalent of the general Forward Deployed Engineer role. These examples are qualitative employer signals, not research measuring industry compensation or growth. Anthropic

Useful evidence includes a problem brief, working code, data quality checks, a failure analysis, decision records and a handover rehearsal. Certifications and years of experience help interpret that evidence. For service objectives, Google’s SLO guidance provides an approach grounded in user needs. Google SRE

Developing quickly with AI tools is useful, but the FDE must still review the code, diagnose incorrect behavior and defend the design. Anthropic’s agent guide distinguishes predefined workflows from agents dynamically directed by a model. The simplest approach that meets the need is a useful starting point. Read this 2024 guide for its architectural principles rather than as a current inventory of tools. Anthropic

Providing the model with the right sources, tool definitions and instructions is an engineering task in its own right. Context management belongs alongside source versions, conversation history, cost and access boundaries. The execution environment and task lifecycle also carry responsibilities beyond a model call. Anthropic · Anthropic

Security cannot rest on a system prompt alone. A model’s request to call a tool does not establish permission to perform the action. OWASP’s LLM and agent guidance examines tool permissions, data leakage and excessive agency. With MCP, identity, consent and scope must be checked as well as connectivity. OWASP · OWASP · OWASP · Model Context Protocol

If a data owner, acceptance decision or operating owner is missing, record the remaining work explicitly. NIST’s Generative AI Profile is a voluntary framework for evaluation across the lifecycle. It is not, by itself, a certification or a finding of compliance. NIST AI 600-1

A useful assessment considers quality, actual use, cost and independence after handover together. Set targets after understanding the baseline and the risk of the work.

A good average can hide a rare but serious failure. Evaluation should cover different task types, repeated runs and version changes. Staffing or process changes during the same period can also affect results: two measures moving together do not establish causation. Anthropic

A proposed assessment has three parts: discovery around an incomplete problem, a small implementation and debugging exercise, and a discussion of architecture and handover. Roughly 40, 90 and 45 minutes can serve as a starting design. These durations are suggestions, not validated hiring benchmarks.

AI tools may be used, but the candidate should explain the resulting work. Do not expect applicants to complete real customer work for free; longer exercises should be paid and clearly scoped. Missing evidence is not the same as demonstrated inability. Assessors should use shared behavioral criteria and set weights for the actual role. An overall FDE score should never hide a security or engineering gap.

Years of experience provide context. The more useful question is which uncertainty the person can now resolve independently. Anthropic’s Staff listing offers one example through architectural responsibility spanning business lines and reviews of other FDEs’ designs. Anthropic

This development plan assumes an existing software foundation. It does not promise independent production competence in 90 days to someone starting from scratch. Customer availability and data permissions can change the schedule.

A useful portfolio brings together the problem, a working example, an authorized technical review, measurements and a failure analysis. If illustrative examples replace confidential customer records, label them clearly.

An industrial FDE must learn equipment hierarchies, units, timestamps and the limits of maintenance records. Reading a signal does not establish a correct interpretation of its physical meaning. NIST SP 800-82 Rev. 3 addresses OT security alongside performance, reliability and physical safety. At the research cutoff, an initial public draft of Rev. 4 was also available; a draft is not a finalized revision. NIST SP 800-82 Rev. 3

In such a workflow, equipment identities and source versions must be matched, while calculations remain in testable code. Missing records, conflicting notes, outdated documents and wrong equipment matches should be tested. Model-generated text must not become the authority for physical calculations or a definitive fault diagnosis.

Success on synthetic data is not evidence of success at a real plant. Acceptance at one site does not automatically generalize to others or grant control authority. For Watt2Work, that distinction underpins keeping measured values, calculated results and interpretation separate.

The organization must provide a business owner who can make decisions, a technical counterpart, data access and subject matter expert time. The FDE owns technical delivery; domain experts assess technical interpretation, data owners govern access and the business owner evaluates the outcome. One person should not be expected to hold every specialization and decision right.

Capacity planning includes development, customer meetings, documentation, travel and support. Recurring customer needs should reach the product team with reproducible examples and impact information. Not every request belongs in the shared product, but the reason for the decision should remain visible.

When considering an FDE, ask for an example from their last delivery: which problem did they choose, what did they build, how did they discover what was not working, and how does the customer sustain the system without them? Concrete answers make the quality of the work visible.