How to Develop FDEs | Training and Evaluation Through Which Engineers Learn Field Skills

Hello, this is Ryuta Hamamoto from TIMEWELL.

This is the final article in our FDE practice series. The nine before it covered field skills, how a week is run, the market numbers, and the contract structure. To close, I want to write about how to develop the people who hold those skills.

We are an engineering company, and every one of us is hungry to build. But half of what an engineer needs to go on site as an FDE is not coding. Asking, watching, being there, structuring, filming, handing a dictionary to a machine. Those six appear in no university curriculum and no programming textbook. Our engineers acquired them through external training and by repeating daily routines on site. This article covers what training can teach, what only the field can teach, and how evaluation is designed. If you first want to check how much field skill your own engineering team has, take the AI literacy check.

The skills an FDE needs lie outside code

First, what is being developed. The person who spent eight years as an FDE at Palantir names three things the role requires: high pain tolerance, the social and political skill to embed deep inside another company and win its trust, and velocity. He adds that the people who learn the customer's language fastest and drill deepest into how the business works do best.¹ He also lists, among the books handed to new FDEs, a user-research manual and an improvisational-theater text; the latter, he explains, breaks down human behavior and social status mechanically and served as a textbook for the skill of winning trust on a customer's site.¹

There is no book about code on that list. An engineering company was handing its new engineers books on interviewing and theater. The reason is that coding skill can be verified at hiring, while the skill of asking, watching, and winning trust on site can only be grown in-house.

The person who led Palantir's commercial business says the same thing from another angle. Imitators, by defining the role narrowly at the product's edges, lose the crucible that makes FDEs grow; it is the broad role, deeply involved in the customer's mission, that develops people.² The design of development cannot be separated from the design of the role. If the role is "build to spec," the only skill that grows is building to spec.

Here are the six skills from this series, rearranged in the order they are developed.

Skill	Article	What training can teach	What only the field teaches
Asking	Interviewing	Question design, silence, mirroring, pairs	The eye for the gap between explanation and screen
Watching	Observation	Where to sit, five columns, three methods	The eye that writes the unease column
Being there	Ethnography	Three-layer notes, how to write the dictionary of meaning	Sensing what the company takes for granted
Structuring	KJ method	Four steps, sorting pattern from branch	Naming a group
Filming	Video analysis	Six consent items, camera setup, AI split	Attaching meaning to numbers
Handing over the dictionary	Ontology	Five extractions, graph form	Separating the different meanings of the same word

The two right-hand columns are separated because they are developed differently. The left can be taught in training. The right cannot. What grows the right is daily routine on site.

What training can teach: forms are learned by being taught

The truth about training. Our engineers took external interview-technique training before going on site. What they learned was form: avoid leading questions, ask about past events rather than future opinions, stay silent for three seconds after a question, separate the interviewer from the recorder. After the training, the way they built questions changed.

Forms are learned by being taught. So we make sure the form part of all six skills is in place before an engineer goes on site: question design for interviews, the five observation columns, the three-layer ethnographic notes, the four KJ steps, the six consent items for filming, the five ontology extractions. These are skills that can be written down as procedures, and this series is that procedure. Our design is that a new engineer reads it in their first week, then accompanies an experienced engineer on site and takes the recorder's seat.

External options exist for the form. In summer 2026, a16z ran an eight-week fellowship for FDEs and applied-AI practitioners, in which participants ship frontier AI systems in real enterprise environments while learning alongside experienced people.³ In Japan, several courses for developing FDEs and programs for growing in-house FDEs appeared in 2026. The entry points for learning the form are multiplying.

But form alone does not stand up on site. What an engineer fresh from training invariably meets at their first site is this: they asked exactly by the form, and the person's answer and the screen disagree. Whether they can think "hm" at that moment is the next stage.

What only the field teaches: the eye for mismatch

The skill that only the field teaches is what we call the eye for mismatch. Someone says "the section manager always approves," and a moment later you see the assistant manager's name in the approval field, think "hm," and ask back, "so the assistant manager sometimes approves?"

Training did not develop that eye. Four daily routines did.

First, pairs. A new engineer starts in the recorder's seat; a senior asks. The recorder writes speech verbatim and also actions: pointed at the screen, looked at a sticky note, checked with the next desk. Write that record every day and the gap between speech and action starts to appear on the page. You move to the asking seat once you can find the gap on the page.

Second, the unease column. Of the five observation columns, the fifth holds the gap between what you heard and what you saw. We have a rule: never leave it blank; write at least one entry every day. In the first week, people usually cannot. They do not yet know what a gap is. In the second week they can write one, and by the fourth week that column is the longest of the five. That has been the progression we have seen. The eye I said training could not give us grew by writing that column every day.

Third, Friday groups. The KJ session where the week's fragments become cards, groups, and names. A new engineer starts by making the cards; a senior names the groups. To name a group you have to know what it is saying about the site. When an engineer can name groups, they have "seen" the site.

Fourth, dictionary versions. The weekly update of the dictionary of nouns and verbs, with a version number. Can you explain how the definition of "approve" changed between last week and this week? When an engineer can explain the dictionary diff to the person on site, the site's words have become their own.

What the four share is what Nonaka and Takeuchi called socialization: the transfer of tacit knowledge by being in the same place and going through the same experience.⁴ The eye for mismatch passes from senior to newcomer not by lecture but by sitting together. That is why we do not send a new engineer to their first site alone.

Designing evaluation: patterns returned and hours declining, not utilization

Development and evaluation are one thing. If the evaluation metric is billable utilization, what grows is the skill of staying on site longer. If it is lines of code, what grows is writing more. To develop FDEs, evaluation has to match the FDE model.

We look at four metrics. The number of patterns from the engagement that became standard product features. Whether on-site hours fell from week one to week eight. Whether the person on site came to update the dictionary themselves. And whether the patterns returned from the previous customer were reused at the next one. These are the three ratios from the contract article plus the customer's self-sufficiency.

They run opposite to contract-development evaluation. In contract work, higher utilization and longer stays raise the evaluation. For an FDE, leaving sooner, returning more patterns, and moving faster at the next customer raise it. Unless evaluation is reversed, development reverses too. The a16z test for the real model, whether engineering effort declines on mature accounts,⁵ is an evaluation of the company and, at the same time, of a single FDE.

One more thing goes into evaluation: the number of requests declined, and the grounds. Could the engineer say no to a branch request with reasons? More is not better, but zero means the engineer is either building everything or accepting everything. When the person who led Palantir's commercial business wrote that an FDE is the opposite of someone whose job is to shrink the customer's ambition to what the product does today,² I read him as asking for both judgments: yes to the mission, no to branches that violate product principles.

How it differs from developing contract engineers

Here is the difference from a development standpoint.

Aspect	Developing contract engineers	Developing FDEs
Skills developed	Languages, frameworks, design	Those plus asking, watching, being there, structuring, filming, handing over the dictionary
Materials	Technical books, certifications	The procedure plus practical books on interviewing and observation
Role on site	Build to spec	Dig out requirements, build, read reactions, return to the product
Where they grow	The development room	The customer's site, in company
Evaluation	Utilization, deadlines, quality	Patterns returned, declining hours, customer self-sufficiency, reuse rate
Exit of development	Project leader	Someone who grows the product

The biggest difference is where people grow. Contract engineers grow in the development room; the customer's site is where they go to pick up requirements. FDEs grow at the customer's site; the development room is where they go back to on Friday. That difference is also a difference in cost. Growing someone on site requires a senior in company, two people's time. We do it anyway because we want to avoid the scene where an engineer sent alone comes back having been shut in a meeting room.

The other difference is the exit. The exit of contract-engineer development is someone who leads a project. The exit of FDE development is someone who grows the product: a person who can make, alone, the judgment to return a pattern found on site to the product. We are small, so our on-site engineers and our product engineers are the same people, and that one person doing both is the exit of development itself.

What we do and where it stops

Let me be honest. This takes time. Training in the forms takes a few days, but we reckon the eye for mismatch takes two or three sites in company, about six months. During that time a senior's hours are spent twice over. For a small company that is not light.

There are limits. Some people do not develop this way. Some engineers would rather write than ask and have no tolerance for sitting on a shop floor. We do not regard that as a flaw. The product side needs engineers like that. Some people suit FDE work and some suit product work, and both are needed. Try to make everyone an FDE and you lose both.

And the limits of training. The external training our engineers took taught the form of interviewing. The forms of observation, ethnography, the KJ method, video, and ontology had to be filled in by our own procedures. One reason for writing this series is to put those procedures outside the company. If a company that wants to develop its own FDEs can use this series in place of a procedure manual, it was worth writing.

Summary

Half of what an FDE needs lies outside code: asking, watching, being there, structuring, filming, handing a dictionary to a machine. Of the six, the form can be taught in training and the eye for mismatch grows only on site. We put the forms in place before an engineer goes on site and grow the eye through four daily routines: pairs, the unease column, Friday groups, dictionary versions. Evaluation is by patterns returned, declining hours, customer self-sufficiency, and reuse rate, not utilization, and includes the grounds for declined requests.

The difference from developing contract engineers is that people grow at the customer's site rather than in the development room, and the exit is someone who grows the product rather than a project leader.

This series is the procedure we wrote to develop our own FDEs, made public. If you want to bring this development into your engineering team, or want to receive a developed FDE at your own site, take a look at the WARP program or talk to us. The whole series can be traced from What is an FDE.

Footnotes

1. Reflections on Palantir (Nabeel S. Qureshi, October 15, 2024). The three qualities an FDE needs, the point that those who learn the customer's vocabulary fastest do best, and the books handed to new hires are from this essay (my summary) ↩ ↩²

2. Sorry, that isn't an FDE (Ted Mabrey, September 21, 2024). The observation that imitators who define the role narrowly lose the crucible, and the description of the FDE as the opposite of someone who shrinks the customer's ambition, are from this essay ↩ ↩²

3. FDE Fellowship (a16z Build, Summer 2026). The eight-week cohort, shipping in real environments, and learning alongside experienced practitioners are from this page (my summary) ↩

4. Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press ↩

5. The Palantirization of everything (Marc Andrusko, a16z, January 16, 2026) ↩