FDE Skills Map: Code, Customers and Judgment

Lists of FDE skills tend to be either a technology shopping list or a vague call for "soft skills". Neither helps you tell whether someone can do the job. This map breaks the role into eight skills, says how each one shows up in a real engagement, and suggests what evidence proves it.

I use it in two directions: to check my own gaps as a freelance forward deployed engineer, and to help clients write a realistic brief when they hire. It also ties together the other posts I have written about the role.

The FDE skills map at a glance

The eight skills fall into three groups, and the third group is the one that most separates FDEs from other engineers.

Job postings reflect this mix. Bloomberry's analysis of about 1,000 FDE postings found the top responsibilities were working directly with customers (55%), building and deploying AI or ML systems (37%) and integrating systems and APIs (32%). Python appeared in 66% of postings and TypeScript in 35%.

Code skills: production, integrations, data, AI and evaluation

The code skills are the entry ticket. Without them you are a consultant, not an engineer, and the customer skills have nothing to deliver.

Production engineering. The system has to run after you leave: authentication, error handling, logging, deployment, background jobs. Gergely Orosz's reporting notes that almost every company hiring FDEs wants a solid software engineering background plus real-world shipping experience. Evidence: a system real users rely on today.

Integrations. Most FDE work is glue: connecting a model to a CRM, a document store, a ticketing system or an internal database. The skill is less about calling an API and more about doing it safely, with the minimum permissions, retries, idempotent writes and an audit trail. Evidence: an integration that writes to a production system without incident.

Data. Real data is messy. Fields are empty, labels mean different things to different teams, PDFs are scans. An FDE needs enough data engineering to clean and join it, and the patience to read samples by hand before trusting any pipeline.

AI systems. This now means retrieval, structured output, tool use and agents. A since-closed Anthropic posting expected FDEs to deliver artefacts such as MCP servers, sub-agents and agent skills for production workflows. Bloomberry found 35% of postings mention AI agents and 31% LLM experience.

Evaluation. The skill that separates a demo from a system. You build a set of real examples with expected outputs, run it on every change, and watch for drift in production. The same Anthropic posting listed evaluation frameworks alongside agent development as a core requirement.

Customer skills: discovery and communication

The customer skills are why the role exists. A company can hire engineers who code; it hires FDEs because someone has to turn a vague business problem into the right software.

Discovery. The request is rarely the problem. "We need a chatbot" often means a team loses hours searching for answers. Discovery means interviewing the people who do the work, watching them do it and mapping the workflow before proposing anything. Paraform calls customer empathy and ambiguity tolerance the hardest traits to screen for. I lay out the steps in my FDE discovery playbook.

Communication. This covers three things: explaining trade-offs in the client's terms, writing decisions down so they survive the meeting, and delivering bad news early. The last one is tested directly in interviews; my list of forward deployed engineer interview questions includes the role plays to practise.

Communication also includes the handover. A system only one person understands is a liability, so the runbook, evaluation results and cost estimate are part of the deliverable. My FDE handover checklist covers what that includes.

Judgment: scoping and the confidence to say no

Judgment is the skill that ties the other seven together: choosing which problem to solve first, how small the first version should be, and what not to build at all. It is the hardest to teach and the easiest to spot when it is missing.

It shows up in small decisions every week:

• Choosing the first win. Not the biggest idea, but the one with clear value, ready data and mistakes a human can catch.
• Saying no to AI where it does not fit. Google's People + AI guidebook notes that a rule or heuristic-based solution will often work just as well as an AI one, and is easier to maintain. An FDE should be able to say so.
• Refusing unsafe shortcuts. Production write access "to save time", keys in a personal account, skipping the review step. Each sounds reasonable under deadline pressure.
• Stopping a pilot. Calling a project that will not reach its success metric, before more money goes in.

Interviewers test judgment through decomposition rounds, where you scope a vague problem out loud. On the job, it shows up as a scope document with an explicit out-of-scope list.

How to use the map

Use the map to find your weakest skill, not to score yourself out of eight. Most engineers who move into FDE work are strong in two or three areas and adequate in the rest; the job exposes the weakest one first.

If you are an engineer: rate yourself honestly on each skill, then pick the lowest one and build a project that proves it. If discovery is the gap, find a real user and interview them before you build. If evaluation is the gap, add a test set to a project you already have. My guide on how to become a forward deployed engineer turns this into a six-month plan.

If you are hiring: decide which three skills matter most for your first project and test those properly, rather than screening for all eight at once. A team whose data is already clean needs integration and discovery more than data engineering. A regulated workflow needs evaluation and judgment above everything else.

Work with me

As a freelance forward deployed engineer, I work across this whole map in a fixed pilot, from discovery to handover. See AI agent development and AI integration, look at my work, and book a scoping call.