The Skill Map

What employers ask for

First, the limits of this chapter. Nobody has studied which FDE skills predict a successful engagement. No cohort has been followed and no outcomes compared, so there is nothing at T1. Two kinds of evidence exist. Job posts are primary evidence of what employers ask for, and T4 evidence of how the job is done. One analyst has counted what those posts contain. The map below is built from those two, from the engagement chapters of this book, and from judgment. Treat it as a structured opinion: useful, but not proven.

The posts themselves are consistent about the basics. OpenAI's San Francisco FDE post asks candidates to "Bring 5+ years of engineering or technical deployment experience that includes customer-facing work", to write production code "using Python, JavaScript, or comparable stacks", and to have "built or deployed systems powered by LLMs or generative models" (OpenAI, FDE - SF, September 2026). Anthropic's London FDE post asks for "4+ years of experience in a technical, customer facing role" and "Production experience with LLMs including advanced prompt engineering, agent development, evaluation frameworks, and deployment at scale" (Anthropic, Forward Deployed Engineer, September 2026). Both posts are primary evidence of the ask.

The one quantitative view comes from Bloomberry, which analysed about 1,000 FDE-titled posts drawn from the jobs-data provider Revealera (Bloomberry, November 2025, updated January 2026; T2, one firm's count of its own sample). Python appears in 66% of the posts, TypeScript in 35%, AWS in 32%, AI agents in 35%, LLM experience in 31% and RAG in 12%. Customer-facing ability appears in 47%. Among responsibilities, "working directly with customers" appears in 55% and integrating systems or APIs in 32%. It is one sample, from one window, classified by one analyst. If you meet these percentages on a course page or in an explainer, check whether they trace back here before you count them as a second source.

Beyond the common core, the posts spread widely. Some read like research roles and some like deal-desk roles, and the spread is large enough that "FDE skills" is not one list.

Put those together and you get the reader's real question. If one employer wants a PhD in fine-tuning and another wants buyout deals with Python as a plus, what does "ready to be an FDE" mean? The answer this chapter argues for is that the posts list inputs. Engagements reward behaviours, and the behaviours are more stable across employers than the inputs are.

Four kinds of behaviour

The thesis of this book is that the distance between a capable model and a customer outcome is made of a misread problem, data nobody can reach, a review nobody planned for, a number nobody agreed and a system nobody owns once the vendor leaves. Each piece of that distance is closed by something an FDE does. Sorted by who the behaviour is aimed at, the doing falls into four domains.

Technical: making it work in their world. This means shipping on the customer's real data, inside their infrastructure, against an eval they accept. A prototype on clean data is the start of this domain, not its centre. The engagement chapters on data access, evals and building in their environment are this domain in practice.

Customer: getting the right problem and an agreed number. This means finding the observed problem behind the stated one, negotiating a threshold with the person who will live with it, and delivering bad news so that the engagement survives it. Discovery, scoping and the readout in Evals are where it shows.

Product: making the next engagement cheaper. This means turning what you built for one customer into evidence the product team can act on, and eventually into components others reuse. Feeding the Product argues that this loop is what separates an FDE from a contractor.

Judgment: knowing what is load-bearing. This means spotting scope creep and data risk early, saying no to a sponsor and making it stick, and calling a failing engagement while there is still time to act. When Engagements Fail and Judgment Under Pressure are about this domain.

Two things about the four are worth saying plainly. First, they are not skills. "Python" is a skill; "shipped an end-to-end workflow on the customer's data with an eval set" is a behaviour, and only the second tells you whether someone can close the distance. Second, they are not independent. A technical decision such as keeping the agent propose-only is also a judgment call and a customer negotiation. The domains are lenses for finding gaps, not boxes that a piece of work falls into.

What the posts measure, and what they only mention

Now read the same posts again, and sort every line into the four domains. The pattern that comes out is this chapter's central claim. Technical and customer behaviour appear as requirements, written so a recruiter can check them: years, languages, "customer-facing". Product behaviour appears as a duty of the job but never as a requirement for getting it. Judgment appears as adjectives.

OpenAI's SF post shows all three. Its requirements are checkable: five years, customer-facing work, Python or JavaScript, LLM systems. Its duties include "Codify working patterns into tools, playbooks, or building blocks that others can use" and "Share field feedback that helps Research and Product understand where the models succeed and where they can improve". Nothing in the "You might thrive in this role if you" list asks whether you have ever done either. Judgment is there, but as character traits: "Spot risks early and adjust without slowing down" and "Model calm and judgment when the stakes are high". Anthropic's London post has the same shape. "Identify and codify repeatable deployment patterns and contribute insights back to our Product and Engineering teams" is a responsibility. The requirements are years, LLM production experience, Python and "High agency with an ability to navigate ambiguity".

Bloomberry's counts are the same kind of evidence seen in aggregate. They count what a post names, and a post names a language or a cloud far more easily than it names a product loop or a judgment call. What a post cannot name precisely, a recruiter cannot easily screen for on a CV either.

There is an instructive exception, and it is seniority. Anthropic's Staff FDE post writes its requirements as track records: "A track record as the person a team turns to on ambiguous technical calls" and "A track record of directly influencing senior technical and business stakeholders, including VP and C-level". It also says "You don't need to have shipped agents to production", because "Side projects and prototypes count" (Anthropic, Staff Forward Deployed Engineer, October 2026). So at staff level the post asks for behaviour, and it relaxes the technical input. That is roughly the shift this chapter recommends you make for yourself at every level.

A second exception runs the other way. OpenAI's healthcare FDE post says: "This role owns the technical solution; ownership of the commercial or executive relationship is not required" (OpenAI, FDE Healthcare, August 2026). Some employers deliberately cap the customer domain below its top level. A map that pretends every FDE job wants the same profile is wrong. Read the post for which domains it caps, not just for which it lists.

Grade this section for what it is. It is one reader's sort of a handful of posts, T4 evidence of how employers write, not of how they hire. Interviews may well test product and judgment behaviour that the posts leave out; the Getting Hired chapter in Part IV covers what is reported about the loops. The practical consequence holds either way. If you prepare only for what the posts list, you prepare for the two domains that are easiest to fake on paper and least likely to decide an engagement.

What the sceptics see

The sceptical view belongs in a chapter about skills, because most of it is a complaint about the skill mix. What an FDE Is sets out the critics in full. Read through the four domains, two of their complaints turn out to be mirror images.

The job that turned out to be services. One of the disappointed hires in Gergely Orosz's March 2026 newsletter put the skill mix in a single line: the company "wanted to use me more on the engagement lead side, and nothing on software development" (Pragmatic Engineer, March 2026; T4, two anecdotes relayed by a newsletter). Two people are not a trend, and Orosz says the FDEs he interviewed at OpenAI and Ramp matched the role's better image. But the complaint is precise. The job had the customer domain and nothing else: no technical depth asked, no product loop offered.

The job that is really AI engineering. Paden Gayle, who is writing O'Reilly's book on the role, argues that "a lot of content labeled FDE is really AI engineering under a different name" (O'Reilly live event page; T4). That is the opposite failure: the technical domain on its own, labelled FDE because the label is fashionable.

The roadmap made of tools. roadmap.sh's FDE roadmap has 97 content nodes (roadmap.sh source, October 2026; T4). Most are technologies: Docker, Kubernetes, Airflow, several cloud platforms, several AI coding tools, several languages. A minority are behaviours, such as discovery and scoping, stakeholder management and a "product feedback loop". The node files cite articles and videos rather than employer posts, and the feedback-loop node describes feeding user feedback into the build "while still on the engagement", not into the vendor's product. The loop every lab post names as a duty is missing from the map. A tool list is easy to study and easy to tick off. It also tells you nothing about whether you can get a threshold signed.

Read together, the sceptics describe two ways the role collapses into a single domain. With customer behaviour only, it is services. With technical behaviour only, it is AI engineering. Both are respectable jobs. Neither is the job this book describes. The economics in Origins and Economics explain why the first collapse keeps happening: services revenue is easy to sell. The skill map's practical use is to show you, from your own record, which collapse you are drifting toward, and, before you sign, which collapse a job will push you into.

A post rarely tells you that. The interview can, if you ask about levels rather than duties. Ask one question per domain, and accept only answers that name a person, a customer or a date:

• Technical. "Whose infrastructure did the last FDE's system run in, and who on the customer side signed its eval?" No answer means L2 may be out of reach: the work stops at demos.
• Customer. "Who agrees the success threshold with the customer: the FDE, or someone else?" "The account team" caps you below customer L3. That can be a fair design, as OpenAI's healthcare post shows, but you should know before you start.
• Product. "Name one thing in the product that started as field work, and who wrote it up." If nobody can, product is capped at L1, and that is the services collapse.
• Judgment. "When did an FDE here last recommend stopping an engagement, and what happened?" If the question surprises them, judgment L4 is not part of the job.

Two vague answers are a pattern. These questions complement the posting checklist in Chapter 1, which reads the advert by stage. This list reads the employer by ceiling.

The rubric

Four domains, four levels, each written as something an observer could see you do. The right-hand column says what counts as evidence. The levels are not titles. An employer's "Senior FDE" may sit at L2 in one domain and L4 in another, and the Levels chapter in Part IV reuses this grid to compare ladders.

Three features of the grid are deliberate. Every L2 involves the customer's real conditions: real data, a real sponsor, a real engagement. A great deal of experience that feels like FDE work is L1 done many times. Every L3 involves someone with power who could have said no: a security reviewer, a director, a sponsor. And every L4 changes something beyond your own engagement: another FDE's starting point, the roadmap, the company's choices. Read the levels that way and the grid becomes hard to game, because each step up needs a witness further from you.

Placing yourself: what counts as evidence

A self-assessment is only as honest as its rules. Five rules make this one work.

Done, not known. Knowing how an eval contract works is not L3 technical. Having owned one that a customer signed is. If your evidence for a level starts with "I understand" or "I've read", score the level below.

Once is a data point; a level is a habit. One week-4 readout that went well is a data point at customer L3. Score a level only when you have done it on two separate occasions, or kept it up across an engagement. Running a system on their data for months counts. One good meeting does not. Record the one-offs separately, because they show where you are heading.

An artefact and a witness. For each level you claim, name a thing (a scope, a brief, a log entry, a decision record) and a person who would confirm it. If you cannot name the person, you are scoring what you hope happened.

Separate what you did from what your lead did. Most mid-level FDEs work an engagement alongside someone senior. The senior's actions are the most common source of inflated self-scores. Write a line for "what the lead did, not me", and keep it honest.

Uneven is normal; lopsided is a warning. Almost nobody is level across all four domains. The warning sign is two or more levels between your strongest and weakest domain, because that is the profile of the two collapses in 3.4.

Where you start depends on where you came from. Bloomberry looked at 100 LinkedIn profiles of current FDEs and found these prior roles: software engineer 45%, solutions engineer or solutions architect 22%, data engineer or scientist 15%, technical consultant 10%, founder or early startup employee 8% (T2, a small sample of profiles, not of hires, and not a measure of who succeeds). Which gaps go with which background is this book's inference, not a finding:

• Software engineers usually arrive at technical L2 or above and customer L1. The first readout where you missed the number is the moment to watch.
• Solutions and sales engineers usually arrive with customer behaviour and with technical work done on demo data. The step to watch is technical L2: their real data, their infrastructure, an eval they accept.
• Data scientists often arrive strong on evals and weaker on integration and on negotiating a threshold, which needs a director rather than a dataset.
• Consultants usually arrive with customer and judgment behaviour and no product loop. They are the most at risk of the services collapse, often without noticing it.
• Former founders, whom Anthropic's posts explicitly invite ("Former technical founders are also encouraged to apply"), often arrive strong on judgment and product. The usual gap is handing over a system someone else can run.

None of these is a verdict. They are hypotheses to test against your own record, and the template below is where you test them.

The template: a self-assessment

Fill it in after each engagement, not once a year. Then hand it to your lead and ask them to strike anything they would not sign.

SKILL SELF-ASSESSMENT                          date: ______________
Name / role: _______________________   Engagements so far: ______

Rule: score the highest level you have DONE unaided, twice or kept
up across an engagement, with an artefact and a witness. Knowing how
is not evidence. Anything done once goes in section 2.

1. LEVEL PER DOMAIN
   Domain      Level   Evidence (what, where, when)   Witness
   technical   _____   ____________________________   __________
   customer    _____   ____________________________   __________
   product     _____   ____________________________   __________
   judgment    _____   ____________________________   __________

2. ONE-OFF DATA POINTS ABOVE THAT LEVEL (not yet a level)
   Domain/level   What happened                       Witness
   ____________   _________________________________   __________
   ____________   _________________________________   __________

3. WHAT MY LEAD (OR SOMEONE ELSE) DID, NOT ME
   ________________________________________________________________
   ________________________________________________________________

4. SHAPE CHECK
   Strongest domain: _________   Weakest domain: _________
   Gap of two or more levels?  YES / NO
   If unchanged, I drift toward:  services / AI engineering / n.a.

5. NEXT ENGAGEMENT: WHAT I WILL ASK TO OWN
   1. __________________________________________________________
   2. __________________________________________________________
   3. __________________________________________________________

6. REVIEW
   Lead struck or changed: ______________________________________
   Lead: ______________   date: ________

The filled version follows. Levels are the rubric's; every engagement figure is a range.

SKILL SELF-ASSESSMENT                    date: month 9, the insurer
Name / role: the FDE, mid-level        Engagements: one, end to end

Rule: score the highest level you have DONE unaided, twice or kept
up across an engagement, with an artefact and a witness. Knowing how
is not evidence. Anything done once goes in section 2.

1. LEVEL PER DOMAIN
   Domain      Level   Evidence (what, where, when)   Witness
   technical   L2      auto FNOL triage live in the   claims ops;
                       insurer's VPC for months;      the lead
                       signed eval plan; regression
                       suite run on every release
   customer    L3      scope + "not now" list with    claims dir.
                       the claims director, wk 2;
                       wk-4 readout missed and kept
                       the deal; bar kept when she
                       asked to go live early
   product     L1      field log since week 1;        the lead
                       platform gaps filed
   judgment    L2      late replica named as a top    the lead
                       risk, wk 2; injection path
                       raised before model risk did

2. ONE-OFF DATA POINTS ABOVE THAT LEVEL (not yet a level)
   Domain/level   What happened                       Witness
   technical L3   propose-only design cleared model   model risk
                  risk, lead in the room
   technical L4   2nd insurer's FDE started from the  2nd FDE
                  template; a fifth to a third of
                  the build carried over
   product L2     product-feedback brief, month 5,    product lead
                  co-written with the lead
   judgment L3    no to write-back and to hiding the  claims dir.
                  stall, month 2; both held
   judgment L4    called the property stall, mo 8;    the lead
                  vendor stopped billing, mo 9

3. WHAT MY LEAD (OR SOMEONE ELSE) DID, NOT ME
   Paused the clock when day-5 access slipped. Set aside the days
   for the brief. Took the post-mortem to the COO and offered the
   reset. Holds the COO relationship.

4. SHAPE CHECK
   Strongest domain: customer    Weakest domain: product
   Gap of two or more levels?  YES (L3 vs L1)
   If unchanged, I drift toward:  services

5. NEXT ENGAGEMENT: WHAT I WILL ASK TO OWN
   1. the product brief: written and presented alone, by month 3
   2. the security review, without the lead in the room
   3. the sponsor's weekly note, from the first week

6. REVIEW
   Lead struck or changed: technical L3 and product L2 moved to
   one-offs (lead in the room; co-written, once)
   Lead: the lead       date: month 9

Three things in the filled version are the point of the exercise. First, the lead struck two of the FDE's draft scores, technical L3 and product L2, and moved both to the one-offs. The security review was passed with the lead in the room, and "unaided" is part of the level. The brief was co-written, and it happened once. Second, the highest-looking evidence on the page, the reused template and the early call, sits in section 2, because each happened once. Third, those two strikes changed the shape check from "no" to "yes". After a strong customer engagement the risk is not weak engineering. It is a product loop that exists only when the lead sets aside the days for it, which is how an FDE slides into services one well-run engagement at a time. Hence the first line of section 5: own the brief, alone, early enough that the next engagement's evidence can make it a level.

What the map cannot tell you

Be clear about the limits before you use this map in a promotion case or an interview.

It is not validated. No one has shown that FDEs higher on this rubric deliver better engagements. The rubric is built so that each level needs evidence closer to the outcome than a skill list does. That is a design argument, not a measurement. If your employer has outcome data on its own FDEs, it beats this grid.

Levels do not map to titles. The posts in 3.1 and 3.3 show one employer capping customer ownership and another making it the job. A "Senior FDE" at a lab and a Forward Deployed Finance Engineer at an application company may score the same total on very different shapes. Compare shapes, not sums. Never add the four levels into one number.

It describes the role this book describes. If the job you are offered is mostly demos and onboarding, or mostly building models, the map will say you are under-levelled in domains the job does not use. That is information about the job, not about you. What an FDE Is is the place to check which job it is before you start measuring yourself against it.

The same grid returns in Part IV. Getting Hired uses it to shape the one portfolio project worth building, and the Levels chapter uses it to read employers' ladders. Here its job is narrower: an honest list of what you have done, and the three things to ask for on your next engagement.