The Interview Skills That Make an FDE Work | How to Draw Real Insight Out of the Shop Floor

Hello, this is Ryuta Hamamoto from TIMEWELL.

We are an engineering company. Every one of us is hungry to build; we would rather be shipping something than sitting in a meeting. That is exactly why, when we go into a client's site as Forward Deployed Engineers, the thing we watch most carefully is not "don't build too soon" but "what do we ask before we build." I wrote in an earlier article that an FDE's value lies not in coding speed but in the skill of drawing real requirements out of the shop floor. This time I want to narrow that down to interviewing: what our engineers learned in external training, what we use on site, and what did not work.

This is the first article in a series that goes deeper into FDE practice. What the role is and why we run our business in the FDE style is in What is an FDE, and the difference from AI "accompaniment" consulting is in a separate piece. Here we start from the point after you have taken your seat at the client's desk: how do you open your mouth? If you first want to check how far your own team can handle field requirements with AI, take the AI literacy check.

Why engineers learn to interview: specifications lie

First, why an engineer would bother to learn how to ask questions. The reason is simple: specifications lie. Not deliberately. The person who wrote the specification cannot describe their own work as a specification.

Most of the work on a shop floor is not in words. Exception rules on a sticky note, a hidden column in a spreadsheet, a second screen opened to check with a manager. The person does all of it every day, but when asked "please explain your process," they describe the process as it should be, not as it is. That is not a failing of the person; it is how human memory works. As user-research practice has long noted, people cannot accurately recall their own behavior and tend to answer with opinions and generalities instead.¹

Toyota's factories have the phrase "genchi genbutsu," go and see for yourself, and Taiichi Ohno told people to ask why five times. Toyota's own account says the nature of the problem and its solution become clear as you keep asking.² I think that is the whole reason engineers should learn to interview. Requirements are not handed to you; you dig for them on site. The question is the shovel and the site is where you dig.

This is also what Palantir's FDEs actually did. According to a former employee who spent eight years there as an FDE, the books handed to new hires included the user-research manual Interviewing Users and the improvisational-theater text Impro. The judgment behind that was that winning trust inside a customer's organization takes the skill of asking and the skill of reading a room.³ An engineering company was giving its new engineers books about interviewing, not books about code.

What an FDE does with what they dig up is the distinctive part. A consultant turns it into a report. An FDE turns it into something that runs, the same day, and puts it in front of the person. Someone looking at a running artifact starts saying things they could not say in front of a blank page. So an FDE interview is not "ask and done." It is ask, build, ask again. The speed of that loop is half of why we say we can implement faster than anyone. The other half belongs in another article.

The purpose is different from a contract-development requirements interview

Let me be explicit about one thing. An FDE interview has a different purpose from the requirements interview in contract development. Seen only as "go on site and ask questions," they look alike, so here is the difference in a table.

Aspect	Contract-development interview	FDE interview
Why you ask	To fix the requirements as the basis for the quote and acceptance	To find the shortest working artifact that reaches the outcome
Scope	Fixed by contract; changes cost extra	Expansion in line with the customer's mission is welcome; branches that violate product principles are declined with reasons
Who owns the output	The customer's asset	Patterns go back into the product as standard features; customer-specific branches are managed as branches
Engineering hours	Revenue; the longer the better	Investment; the fewer hours per customer over time the better
How it ends	Acceptance and withdrawal	The customer runs it themselves and the pattern spreads to the next customer

A contract-development interview is conducted so that nobody argues later. What is heard gets frozen into a specification and every change becomes a change order. In that structure, a person looking at a working artifact and saying "actually, that's not it" is unwelcome. An FDE interview is the reverse: it exists to surface "actually, that's not it" as early as possible. The person who ran Palantir's commercial business described the FDE as a CEO with zero authority, someone accountable for the customer's business outcome rather than someone whose job is to shrink the customer's ambition down to what the product does today, and he wrote that scope expansion is welcome when the customer's mission demands it, as long as it does not depart from the product's principles.⁴

That does not mean accepting everything. a16z's January 2026 essay on the "Palantirization" of software lists three pressure tests for telling the real thing from the imitation: does engineering effort decline on mature accounts, can you say no to customization, and does the model still work past 50 customers.⁵ In our words, that is the Friday sorting of "pattern or branch." Patterns go back into the product; branches are watched so they do not multiply; branches that violate product principles are declined with reasons. Skip that sorting and you fall into what a16z warned about in 2025, the services trap: sending people in without a product spine and ending up as expensive custom development.⁶

In 2026 the model spread to the largest players. In May, OpenAI launched a deployment company with roughly 150 FDEs and described the typical engagement as a diagnostic of where value lies, a small number of priority workflows chosen with leadership and operating teams, and design, build, and rollout inside the organization.⁷ In June, AWS put a billion dollars into an FDE organization and made customer self-sufficiency at the end of the engagement, meaning working systems plus documentation plus trained in-house staff, the center of the design.⁸ In Japan, Accenture set up a dedicated FDE practice in April,⁹ large consultancies and cloud providers followed, and the label has spread far enough that a "chaos map" of FDE vendors has been published. The wider the name spreads, the more the burden of explaining how this differs from contract development falls on those who use the name. That is why this article goes into the details of how to ask.

Three kinds of FDE interview: change how you ask by what you want

In the first week on site, we use three kinds of interview and keep them apart. Mixing them fails.

Kind	Purpose	Typical questions	Output
Discovery	Map the work	"What did you do yesterday afternoon?" "Then what?"	Flow of work, list of nouns and verbs
Deep dive	Collect exceptions and pain	"What was the worst case last month?" "How did you finally handle it?"	Exception notebook, candidates for the first feature
Validation	Get reactions to a working artifact	"What is different?"	Fix list, next version

Discovery interviews are days one and two. The goal is a map of the work, and coverage matters more than precision. The key is never to say "please explain your process." Instead: "What did you do yesterday afternoon?" Yesterday, people can remember. "Then what?" "Where is that screen?" You trace the day in time order. As you trace, you write down the company's nouns and verbs without translating them into system terms. You learn that "allocate" and "reserve" mean different things here at this stage. One more thing we always ask at the discovery stage is who owns the data. "Which system does that number come from?" "Who administers that system?" A former Palantir FDE describes pilots of eight to twelve weeks in which almost the entire period went to negotiating data access, and says the obstacle was organizational politics, not technology.³ Identify the data owner on day one and you do not stall in week two.

Deep-dive interviews start on day three. The goal is exceptions. Routine work already runs on existing systems, so the room for an FDE is in the exceptions. This is where the critical incident technique, described below, comes in. "What was the most troublesome case last month?" "How did you finally handle it?" "Who knows how that was handled?" The answers are rules that exist only in that person's head.

Validation interviews begin the moment something runs, which can be the evening of day one. Put the incomplete thing down and ask only "what is different?" Ask "what do you think?" and you get praised and nothing else. Ask "what is different?" and they start looking for differences. I ported this technique to new-business customer interviews and wrote up the procedure in the live mock article.

The reason to keep the three apart is that the questions have different shapes. Discovery is chronological, the deep dive is event-based, validation is difference-based. Mix them and the person no longer knows what kind of answer you want, and retreats into generalities.

Question design: specific past, behavior, exceptions

There are principles for building questions that can be taught, and our engineers learned them in external training. Here is the form in my own words, in three parts.

First, ask about past behavior, not future opinion. To "would you use this feature if it existed?" nearly everyone says yes, out of courtesy. The standard startup customer-interview book, The Mom Test, hammers on one point: ask about concrete facts of the other person's life and do not ask for opinions about your idea.¹⁰ On site we turn that into "when did you last do that task, and what happened?"

Second, ask about events. The critical incident technique, which John Flanagan systematized in Psychological Bulletin in 1954, is a set of procedures for collecting direct observations of behavior by focusing on specific, significant incidents: what happened, how it was handled, what the outcome was.¹¹ It grew out of aviation psychology research during the Second World War and is still used in user-experience research today.¹² It works for FDEs because exceptions are remembered as events. "Tell me the exception rules" produces nothing; "the worst case last month" produces the rule.

Third, keep asking why, carefully. Ask why five times in a row and you can corner someone. "Why that procedure?" "Why?" "Why?" By the third, the person feels accused. Toyota's five whys are asked of a problem, not of a person.² We replace "why" with "what." "What is it that gets in the way of changing that procedure?" You reach the same depth without blaming anyone.

Here are some rewrites, the question we tended to ask on the left and the one that actually worked on the right.

Question to avoid	Replacement
Would this feature be useful?	When did you last do that task, and how many minutes did it take?
Can you walk me through the process?	What was the first screen you opened yesterday afternoon?
Is there anything you struggle with?	What took the most of your time last month?
Why is the procedure like that?	What breaks if you change that procedure?
Is the data clean?	Which fields are most often left blank?

What the right-hand column has in common is a specific time, screen, or field. The person knows exactly what to recall. In the left-hand column, they do not.

How to listen: silence, mirroring, pairs

Good questions are wasted by bad listening. This is where we learned the most in training and failed the most on site.

Wait through silence. Three seconds after your question, three more after their answer. Engineers are bad at this. We want to fill the gap, so we offer a candidate answer ourselves: "so you mean approvals are slow?" The moment you say it, the person takes the candidate. An answer they took from you is your hypothesis, not their answer. Stay quiet and they add something. The exception is in what they add.

Mirror. Repeat their words exactly. "The allocation gets doubled." Do not paraphrase. Say "duplicate inventory, right" and their word disappears. Building the company's dictionary of nouns and verbs starts with mirroring. If you repeat it wrong, they correct you, and the corrected word is the company's real term.

Go in pairs. One asks, one records. The interviewer takes no notes. Notes pull your eyes down and you stop seeing the person's face and the screen under their hands. The recorder writes down speech verbatim and also actions: pointed at the screen, looked at a sticky note, checked with the next desk. That record of actions is the doorway to observation, which the next article covers. Going alone, get consent to record and concentrate on listening.

Say "show me." When an explanation runs long, switch: "could you show me that screen?" Every step that never came up in the explanation is on the screen. This is the boundary between interviewing and observation, and the method called contextual inquiry is built exactly this way: go to where the work happens and ask while watching it being done.¹³ We think of the interview as the warm-up act for observation.

Keep the layers apart. Executives, division heads, and the shop floor want different things from the same project, and in one room only the executive's voice survives. I covered that in the earlier article, so one addition on listening: when you interview a front-line person, do not have their manager in the room. With the manager present, they describe the process as it should be.

What training gave us, and what only the field gave us

Let me be plain. Our engineers take interview-technique training before going on site, and it helped. Avoiding leading questions, asking about past events, waiting through silence, separating recorder from interviewer: these are forms, and forms can be taught. After the training, the way we built questions changed.

What training did not give us was the ability to notice the gap between what a person says and what their screen shows. Someone says "the section manager always approves," and a moment later you see an assistant manager's name in the approval field, and you think "hm." Can you turn that "hm" into words and ask "so the assistant manager sometimes approves?" That skill only grew through repeatedly putting a working artifact in front of people and reading their reactions. In my article on putting unease into words I argued that when AI gets pulled by context and fails to abstract, a person has to notice. Interviewing is the same. Training gives you a form for asking; the field gives you an eye for mismatch.

The other difference was time. Training has you design a 60-minute interview. On site, the person is busy and a solid hour never appears. What you get is ten minutes between tasks and five minutes when you show them something running. So our interviews became short and frequent. Instead of trying to get everything in one session, we ask five minutes every time we put down a new version. That shape produced more exceptions than any hour-long interview, because seeing the artifact makes people remember.

Interviewing in the age of AI: records to the machine, the room to people

Finally, how we use AI.

Recording and transcription go to AI. With consent, we record, produce a verbatim transcript, and extract nouns and verbs into a draft dictionary. Up to that point the machine is faster and more accurate. But we do not let it summarize. An AI summary keeps the routine work that happens every day and drops the exception that happens once a month. The exception is what an FDE is there for, so a person goes back through the verbatim transcript. Summaries are convenient, and in exact proportion to their convenience they erase the thing that matters most.

Three things cannot be handed to AI: silence, hesitation, and the screen that appears when you say "show me." A transcript does not record why someone went quiet for three seconds. The "but" that follows "well, basically, um" is flat on the page, but in the room it is the signal of an exception. And a screen does not travel over audio at all. So the split is: people hold the listening and the looking, AI takes the recording and the sorting.

That split carries into the next article on observation, and beyond it into filming the shop floor and analyzing the video with AI. We have started doing that, and the same rule holds there: the consent you get before filming and what a person is watching while the camera runs decide the quality of the analysis.

Summary

What makes an FDE work is not coding speed but listening. Specifications lie, so requirements are dug up on site. There are three ways to dig: discovery in time order, the deep dive by event, validation by difference against a working artifact. Questions ask about past behavior rather than future opinion, specific events rather than generalities, "what" rather than "why." Listening means waiting through silence, mirroring, working in pairs, and switching to "show me" when explanations run long.

Training gives you the form; the field gives you the eye for mismatch. Our engineers go on site with both, turn what they hear into something that runs the same day, and ask again. That loop is half of what makes our implementation fast.

If you want your engineering team to be able to listen on the shop floor, or you want to prepare your own site to receive an FDE, take a look at the WARP program or talk to us. The next article covers what comes after listening: observation, shadowing, and contextual inquiry.

Footnotes

1. User Interviews: How, When, and Why to Conduct Them (Nielsen Norman Group). The point that people cannot accurately self-report their behavior is from this article ↩

2. Ask 'why' five times about every matter (Toyota Motor Corporation, Toyota Traditions) ↩ ↩²

3. Reflections on Palantir (Nabeel S. Qureshi, October 15, 2024). The onboarding books, how often FDEs were on site, the practice of shipping something usable within a week or two, and the data-access anecdote are from this essay ↩ ↩²

4. Sorry, that isn't an FDE (Ted Mabrey, September 21, 2024). The "CEO with zero authority" framing, welcoming scope expansion, and not departing from product principles are from this essay ↩

5. The Palantirization of everything (Marc Andrusko, a16z, January 16, 2026). The three pressure tests are from this essay ↩

6. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups (Joe Schmidt, a16z, June 2025) ↩

7. OpenAI launches the OpenAI Deployment Company (OpenAI, May 11, 2026). The typical engagement structure and the roughly 150 FDEs from the Tomoro acquisition are from this announcement ↩

8. AWS invests $1 billion to embed AI forward deployed engineers with customers (Amazon, June 30, 2026) ↩

9. Accenture launches a Forward Deployed Engineering practice with Microsoft to help organizations scale AI across the enterprise (Accenture Japan, April 16, 2026, in Japanese) ↩

10. The Mom Test (Rob Fitzpatrick). The principle of asking about concrete facts of the other person's life rather than opinions about your idea is from this book ↩

11. Flanagan, J. C. (1954). The critical incident technique. Psychological Bulletin, 51(4), 327–358. PubMed ↩

12. The Critical Incident Technique in UX (Nielsen Norman Group) ↩

13. Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context (Nielsen Norman Group) ↩