What an FDE does

By the end of this lesson

• Explain how an FDE turns an ambiguous request into an improvement that can be checked.
• Distinguish delivery-team decisions from customer decisions and identify who needs to participate.
• Start a record of facts, assumptions, decisions and outcomes, with an owner and deadline for the next action.

Before you begin

• Read the Beichen case introduction, including its 48 field engineers, six remote specialists and limits on the proposed assistant. All people and data are fictional.
• Open a blank note. Write down the customer's request, your first reaction and three questions you cannot yet answer.

Read the Beichen case and introductory data

Start with the work the customer needs to do

FDE stands for Forward Deployed Engineer. The role usually involves working closely with customers to understand a problem, build a system and help people use it in their work. Employers define the job differently. OpenAI's official role description includes discovery, technical scope, building, production rollout and adoption. Treat that as one employer's requirements, not a universal job specification.

Begin with a practical question: who needs to accomplish what, and under which conditions? Beichen asks for an incident-handling assistant. Its field engineers need to decide what to check next, find guidance that applies to the equipment and reach someone authorized to act when necessary. A fluent answer demonstrates text generation. You still need to find out whether it helps someone complete that work.

The initial assistant may provide recommendations and prepare parts-request drafts. It must not stop equipment, submit requests or issue incident conclusions to customers. Those limits apply throughout the following lessons. You may recommend a narrower or different scope, but expanding it requires fresh authorization and evidence; a convincing demonstration does not grant permission.

Check both the system and the conditions for using it

Look at two connected parts of the project. The system includes document versions, access permissions, retrieval, model output and external interfaces. The working conditions include who makes a judgment, who allocates time, who reviews it and who takes over when something goes wrong. One affects the other. Finding the right manual is not enough if the engineer cannot open it.

Do not assume every technical failure triggers an alert or every difficulty at work goes unrecorded. Unmonitored errors can persist, while support tickets may reveal organizational problems. Arrange deliberate checks: inspect the system record for one task, then ask the person who handled it what happened and which offline channels they used. Together, these accounts help distinguish missing capability, missing permission and insufficient staffing.

Assign responsibilities rather than inferring authority from titles

In this course, Echo labels responsibility for business and user research; Delta labels responsibility for engineering delivery. The names are borrowed from Palantir. You do not have to choose an identity before learning. On a small project, one person may investigate the work and write the code. What matters is documenting responsibilities and finding anything that has no owner.

The customer is not a single decision-maker. The business owner sets priorities and investment; the data owner agrees permitted uses and access; the operations owner arranges support and decides when operation can start or stop. Domain specialists help assess consequences that require specialist expertise, and users show whether the workflow is practical. Actual authority follows the customer's rules. Seniority or enthusiasm does not automatically give someone authority to approve decisions that belong to another owner.

Hand over information someone can act on

A handoff such as 'users want document search' or 'there are technical risks' leaves the next person guessing. Explain what happened, where the information came from and which choice it affects. Then list what still needs confirmation. A researcher should not turn one complaint into a team-wide requirement; an engineer should not turn technical feasibility into approval to launch.

Here is a hypothetical walkthrough. The customer wants everyone using the assistant next month. First record this as a timing expectation, not an approved scope. Next organize the questions about work and technology. Finally give one joint recommendation rather than two disconnected answers. Asking the recipient to explain the recommendation and limits in their own words can reveal whether 'recommendations only' was mistaken for permission to act automatically.

• Step 1: clarify the goal. Which delay are you trying to reduce? Is universal use a means to an end or the outcome the customer actually needs?
• Step 2: list unknowns. Which equipment tasks suit recommendations? Can users access the sources? Who has time to review and take over?
• Step 3: propose an action that can be approved. Investigate East China day-shift incident tasks first, with research scope confirmed by business, data and operations owners.
• Step 4: agree an owner and update time. Commit to presenting findings and options then, rather than promising an untested benefit.

Keep four kinds of record to make your reasoning visible

From now on, organize notes as facts, assumptions, decisions and outcomes. A fact is supported by a source or observation, with its scope stated. An assumption is a provisional explanation or expected effect that needs testing. A decision records what an authorized person chose. An outcome records what you actually observed after an action. One document or spreadsheet is enough; no elaborate tracking system is required.

For example, Beichen's 48 engineers are a case fact. 'Most waiting comes from finding documents' is an assumption. Analyzing an approved set of records can be a proposed action; record it as a decision only after authorization. The distribution found in that analysis is the outcome of that action. Give records identifiers and link them. Also note people's concerns and the next conversation, so the record does not contain numbers alone.

Move through the questions, and revisit them when necessary

The following lessons move through agreement, research, problem definition, design, verification, piloting and handover. Each uses the previous lesson's notes: agree what you may access before investigating the work; establish which problem is worth addressing before designing how people and the system cooperate. The sequence helps avoid unsupported investment. It is not a timetable every project must follow exactly.

A pilot is a limited trial with specified users, tasks and timing, plus observation, support and a way to stop. It means more than giving a few people early access. If a pilot reveals that approval is the main delay, revisit the problem. If access is reduced, revisit the research agreement. GOV.UK's discovery guidance likewise emphasizes understanding problems and constraints before deciding to proceed. Its government-service process should not be copied wholesale as enterprise policy.

Distinguish a demonstration, use and an improvement in work

A demonstration shows that a path works under the conditions presented. Launch shows that the system can be accessed; a login shows that someone opened it. Each is useful information, but none alone establishes shorter incident waits. When reading a project report, ask what records the task used, who had access, whether review was available and how the task ended. Attractive system metrics do not replace evidence about the work.

Avoid treating every instance of non-use as a training need. Someone may know how to use the assistant but lack permission, suitable records or clarity about responsibility. More training does not directly remove those conditions. Check one specific task to understand the reason. At this stage you need not establish every benefit. You need a useful next investigation and an opportunity for affected people to correct your understanding.

Respond when the customer says, 'Just decide for us'

A customer who asks you to decide may be seeking a professional recommendation. Separate engineering choices from customer authorization. How code is organized usually belongs to the delivery team. Using new data, accepting night-shift risk or changing service commitments requires checking customer authority. Where responsibility is unclear, do not treat silence or a casual phrase as approval. Equally, 'we cannot decide' is not a sufficient response.

Offer a short choice brief: what you recommend, the evidence, what remains unknown, each option's costs and who needs to confirm. For example: 'We recommend limited research first because the cause of waiting is not yet established. The data owner should approve the data use, and the operations owner should confirm support for any later pilot.' This gives useful advice while preserving the customer's authority over its work and risks.

Practice the method

Check your understanding

Write your answer before opening the explanation, then check what you might have missed.

Your record and next step

A responsibility note, a delivery plan and a next-step decision with an owner and a condition for reviewing it.

Keep your responsibility note, facts and assumptions, and next-step plan. Lesson 2 turns the people and access you need into an explicit working agreement.