How FDEs Observe | Shadowing and Contextual Inquiry to Catch the Steps Nobody Explains

Hello, this is Ryuta Hamamoto from TIMEWELL.

This is the second article in our FDE practice series. In the previous article on interview skills I wrote that the interview is the warm-up act for observation. This is the main act.

If asking questions on site were enough, there would be no reason for an engineer to keep sitting in a factory or an office. The reason to keep sitting there is that some things never come out no matter how you ask. Steps the person performs every day but cannot recall when asked: the exception rule written on a sticky note, the hidden column in a spreadsheet, the phone call to confirm before typing anything into the system. This article lays out the observation methods our engineers use to catch those unexplained steps, in the order we use them. If you first want to check how well your own team sees the shop floor, take the AI literacy check.

Asking gets you half. Observation catches the steps nobody explained

Why is asking not enough? Because people cannot describe their own behavior accurately. That is not laziness; it is how memory works. User-research practice keeps returning to the value of watching real behavior in the field, and the reason it gives is that what people say they do and what they actually do often diverge.¹

A person who spent eight years as an FDE at Palantir compresses the idea behind the role into one phrase: context is that which is scarce. You go to the customer's site to capture the tacit knowledge of how people work, rather than the flattened list of requirements.² At his first assignment, an aircraft manufacturer, he spent a year commuting to the factory and four days a week on the production floor. An engineer spent a year in a factory not to ask but to watch.

There is an older example. Taiichi Ohno, who built the Toyota Production System, is said to have drawn a circle in chalk on the factory floor, had a manager stand inside it, and made them watch an operation for hours. He would ask what they had seen, and if they had not seen it, tell them to keep watching.³ Our engineers do not draw chalk circles on site, but what they do is the same. Sit diagonally behind the worker, say nothing, and watch the same task several times over.

I sort what observation catches into four things: the order of the steps, the waiting and walking between the steps, the checks that happen outside the steps, and the decisions to skip a step. An interview gives you only the first. The other three cannot be known without watching.

Three observation methods: shadowing, contextual inquiry, think-aloud

"Observation" covers several methods, and each catches different things. Here are the three we use and when.

Method	What you do	What it catches	When
Shadowing	Follow the person through the day without interrupting	The whole flow, walking and waiting, checks that never come up in explanations	Day one
Contextual inquiry	Sit at the place of work and ask while watching the work	Reasons behind steps, decision criteria, how exceptions are handled	Day two onward
Think-aloud	Have the person say what they are thinking as they work	Where on the screen they look and where they hesitate	After a working artifact is in place

Shadowing means following like a shadow. We use it on day one. The goal is a map, and you do not interrupt. If the person gets up and walks to the next section, you walk with them. If they make a phone call, you ask one thing afterward, "what was that confirming?", and dig no further. Digging starts on day two. What matters in shadowing is recording the walking and the waiting. "Twenty minutes waiting for approval." "Carried a printout to another floor." That time never appears in the person's own explanation, because to them it is not part of the work. Yet the first thing an FDE should build is usually inside that time.

Contextual inquiry is a method systematized in user research. Its defining feature is going to where the work happens and asking questions on the spot while watching the work being done. It is often described as a master-and-apprentice relationship: the apprentice watches the master work and asks "why did you just do that?", and the master answers without stopping. Once that relationship is in place, the person becomes the one teaching and shows you the actual procedure rather than the official one.⁴ This is what our engineers use from day two. Think of it as the deep-dive interview from the previous article, done at the workstation instead of in a meeting room.

Think-aloud has the person say out loud what they are thinking as they work, and it is a basic tool of usability research.⁵ On an FDE engagement we use it after putting down a working artifact. "Please do your usual task on this screen and say whatever comes to mind." You learn where on the screen they stop, what they search for, and where they say "hm." It is the "what is different?" of the validation interview, taken from actions instead of words.

All three share two things: they happen at the workstation, not in a meeting room, and they take little of the person's time. Shadowing uses almost none. Contextual inquiry accumulates tens of seconds in the gaps between tasks. Think-aloud takes ten minutes. As I wrote last time, the person on the floor does not have an hour.

FDE observation is observation in order to build. How it differs from as-is analysis

Here is where contract development differs. Contract development has as-is analysis too. You draw process flows, list the issues, and write a proposal. Judged by the motions alone, it looks like observation. The difference is what happens afterward.

Aspect	As-is analysis in contract development	FDE observation
Purpose	Ground the proposal and the quote	Decide the working artifact to put down tomorrow
Output	Process flow diagrams, issue lists, a proposal	An exception notebook and the next version of the artifact
Duration	A bounded analysis phase, followed by design	Runs alongside implementation and does not end
What happens to an observed exception	Agreed as a requirement and priced into the quote	Built on the spot; patterns go to the product, branches are managed as branches
Who observes	An analyst, usually not the implementer	The engineer who will build it

As-is analysis is done for later phases, so the analyst and the implementer can be different people. FDE observation is done to decide what to put down tomorrow, so the person who watches and the person who builds must be the same. The twenty minutes of approval waiting found on Friday becomes a working artifact in front of the person on Monday. That loop works only because the engineer who observed is the one who builds. a16z's January 2026 essay lists "does engineering effort decline on mature accounts" as a test of the real FDE model,⁶ and when observation feeds directly into implementation, the same observation is not needed at the next customer, because the product already knows that step.

The other difference is what you do with an observed exception. In contract development, an exception becomes a requirement, gets priced, and is fixed by contract. For an FDE, the exception is built on the spot. Then, once a week, you sort: is this a branch unique to this company, or a pattern other companies share? Patterns go back into the product as standard features; branches are recorded as branches. The former Palantir FDE writes that the FDE's job was to solve the problem and not worry about generalizing, because generalizing was the product team's job.² We are a small company, so the engineer who observed also writes the product, and the sorting is done weekly by the same person.

On site: where to sit, what to watch, what to write

Concretely, this is how our engineers observe.

Sit diagonally behind the person. Directly behind is oppressive; beside them you cannot see the screen. Diagonally behind, you can see the screen, the papers under their hands, and their face at once. The first thing to ask on day one is "could you show me your usual task, done the usual way, while I watch?" Before that, tell them you came to learn rather than to evaluate, and that what you see will come back to them as something that runs.

Watch four things: screen, hands, paper, movement. Screen: which system, which screen, the order of switching, copy-and-paste motions. Hands: what they touch besides keyboard and mouse, a calculator, a sticky note, a printout. Paper: the forms on the desk and in the drawer, and the notes written on them. Movement: why they leave the desk and where they go. Of these four, an interview gives you a fraction of the first.

Write five columns: time, action, screen, speech, unease. Time to the minute, so the length of waits and walks can be reconstructed. Action as a verb, "opens approval screen." Screen as system and screen name. Speech verbatim. And in the unease column, the gap between what you heard and what you see, such as "explanation said section-manager approval, but the assistant manager's name is in the field." That fifth column is the candidate list for tomorrow's build. The eye for mismatch I said training could not give us grew by writing this column every day.

The problem with observation is that being watched changes how people move. This is called the Hawthorne effect. Research is still debating how real and how large it is, but the possibility that observation changes behavior is something study design is expected to account for.⁷ We do three things. Say on day one that this is not an evaluation. Watch the same task again on another day. And give back the result of the observation as a working artifact by the next day. The third works best. Once people see their own work turn into something that runs, they stop showing the work for display and show you the real one.

Whether to interrupt depends on the method. In shadowing, you do not. In contextual inquiry, you do, but never make them stop working. Questions go in the gaps and stay short, "who did you just confirm that with?", and if the answer is going to be long, cut it with "tell me later." Breaks and lunch are for conversation, not observation. The "honestly, nobody looks at that form" that comes out over lunch cannot be caught by any observation method.

Four patterns we keep finding

Confidentiality means I cannot describe individual engagements, so here are four patterns, generalized, that our engineers have found again and again on site. None of them came out in interviews; all were found by watching.

First, double entry. What was entered into the core system is entered again into a separate spreadsheet. Asked why, people say the spreadsheet is easier to total, or that it is a habit from the previous system. They do not think of it as work, so it never comes up in an explanation.

Second, confirmation before entry. Before entering anything, the person checks with the next desk or by phone. If the person they check with is off that day, entry stops. What is being confirmed is the decision criterion that is not written in the system.

Third, printing and carrying. An approval that could be completed on screen is printed, carried to another floor, stamped, and brought back. There is an approval screen; it is not used. Asked why, people say the approver does not look at the screen.

Fourth, skipping. The procedure manual has a verification step, and the experienced person skips it, because experience tells them nothing goes wrong. That judgment is written nowhere, and when that person is away, the newcomer follows the manual and it takes twice as long.

What the four share is that they are too ordinary to the person to put into words. And the first thing an FDE should build is usually one of them: remove the double entry, put the confirmation criterion on the screen, put the approval where the approver actually looks, make explicit the conditions under which skipping is fine. None is a large feature. Each changes the person's day.

What we do and where it stops: observation takes time

Let me be honest. Observation takes time. Shadowing takes a day, contextual inquiry several, and watching the same task twice takes several more. Spending engineers' time on site naturally meets resistance. For engineers who want to build, a day spent sitting and building nothing feels long. We keep doing it because one day of observation erases a week of rework later. Something built without watching gets "that won't work on our floor" the moment it is put down. Something built after watching gets "this part is different," and that is all.

There are limits. You can observe only the work of the person you watched, on the day you watched. The month-end process, the annual close, and the fallback procedure on the day that person is off cannot be seen. So observation is combined with the interviews from the previous article: ask about what you saw, "is this every day, is month-end different?", and ask about what you could not see as events.

Confidentiality and consent are limits too. Observation means watching how someone works, so it needs the agreement of the person and their manager. We settle at the first meeting whose work will be observed, when, for what purpose, and how the record will be handled. We commit in advance that the record will contain nothing that could feed into an individual's performance evaluation and will be used only to build the working artifact. That commitment gets heavier in the next article, on filming and AI analysis.

Summary

Interviews get you half of how work is done. The other half is in steps the person cannot explain, and can only be seen. There are three observation methods: shadowing on day one to build the map, contextual inquiry from day two to dig out reasons and criteria, and think-aloud once a working artifact is in place to capture actions. Sit diagonally behind; watch screen, hands, paper, and movement; write five columns of time, action, screen, speech, and unease.

What separates FDE observation from as-is analysis is that the person who watched is the one who builds. The twenty minutes of approval waiting found on Friday becomes a working artifact on Monday. That loop is what makes observation part of implementation rather than an analysis phase.

If you want your engineering team to develop an eye for the shop floor, or 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 business ethnography, a way of making observation longer and deeper.

Footnotes

1. Field Studies (Nielsen Norman Group). The value of observing behavior in its real setting and the gap between self-report and actual behavior are from this article ↩

2. Reflections on Palantir (Nabeel S. Qureshi, October 15, 2024). "Context is that which is scarce," the year spent four days a week on an aircraft manufacturer's floor, and the division of labor between FDEs and the product team are from this essay ↩ ↩²

3. Taiichi Ohno's Chalk Circle (AllAboutLean.com, Christoph Roser). The chalk-circle story is passed down through accounts of former Toyota managers and is taken from this article ↩

4. Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context (Nielsen Norman Group). The master-and-apprentice framing is from this article ↩

5. Thinking Aloud: The #1 Usability Tool (Nielsen Norman Group) ↩

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

7. McCambridge, J., Witton, J., & Elbourne, D. R. (2014). Systematic review of the Hawthorne effect: New concepts are needed to study research participation effects. Journal of Clinical Epidemiology, 67(3), 267–277. PubMed ↩