A Day in the Life of a Forward Deployed Engineer

After this lesson, you should be able to describe how a forward deployed engineer (FDE) moves through a customer engagement, explain why the work alternates between customer conversations and engineering, and identify who needs to own each decision. The example follows NorthPort Freight, a fictional regional logistics company. Its dispatchers are trying to resolve mismatched order details between an older ordering system and a newer dispatch tool. The company, people, workflow, and records in this example are invented.

Start with the work people already do

The first meeting is not a product demo. The FDE needs to see how dispatchers handle an exception before proposing a solution. In this example, a dispatcher notices that the order reference in the ordering system does not match the reference in the dispatch tool. The dispatcher checks another screen, asks a colleague whether the order changed, and decides whether to hold it for review.

That sequence gives the team something concrete to investigate. The FDE asks what makes an order an exception, which system contains the correct value, what information the dispatcher is allowed to see, and what should happen when the two records still disagree. A systems owner can explain when the older system updates its records. The dispatcher can point out a work rule that is not written in the system documentation.

This is discovery: learning how a task works, what makes it difficult, and which constraints affect a possible change. The people doing the work are usually the best place to begin, but they may not own every technical or policy decision. The FDE should find the system owners and approvers as well, and keep observed facts separate from guesses.

The meeting should end with open questions recorded, not hidden inside a confident summary. For NorthPort, the team might know that dispatchers compare two reference fields. It may still need to confirm whether the ordering system exposes both fields through an approved interface and whether a mismatch can be flagged without changing either source record.

The Forward Deployed Engineering overview from OpenAI describes working with customer teams to understand workflows, define a useful outcome, test in production, and help teams extend what works. Production is the environment where people use a system for real work. A current OpenAI job description also lists technical discovery, scoping, implementation, evaluation, deployment, and handoff. Those sources describe OpenAI's practice. The exact sequence and responsibilities vary by employer and engagement.

The engagement has a cycle

A customer engagement has a beginning, a changing middle, and an operating phase. Teams often move through discovery, scoping, building, validation, deployment, and handoff. The work can circle back when a test or new conversation changes what the team understands.

Discovery and scoping

After observing the exception, the FDE writes down the task and asks which part should improve first. The dispatcher may want fewer screen changes. The system owner may care that the older application remains the source of truth. The operations lead may need a way to review unresolved cases. These goals can coexist, but the first version needs a clear boundary.

Scope means the work the team agrees to include now. For NorthPort, a first slice might show the two reference fields side by side and flag a mismatch for a dispatcher to review. Automatically changing the order would be a larger step. It would require a separate decision about permissions, correction rules, and recovery if the update is wrong.

The team writes down what it will check. An acceptance criterion is a statement that describes a condition the customer and engineering team agree must be true for a change to count as acceptable. One example might be: "For the agreed sample records, the screen shows both source values and identifies whether they match." The sample records and expected results still need to be chosen with the system owner and users.

The FDE does not choose the business policy on the customer's behalf. The engineer can explain the technical trade-offs and suggest a safe first slice. The dispatcher or operations lead confirms whether the slice fits the task; the owner of the order system confirms what access and changes are allowed.

Build and integrate

With an agreed first slice, the FDE can make a small version. That may mean writing code, configuring a product, or combining both. Integration is the work of connecting systems so information or actions can move between them. Here, the engineer needs to learn how the ordering system provides records and how the dispatch tool identifies them.

The initial implementation might read a small set of permitted records and present the relevant fields. The FDE checks missing values, duplicate references, delayed updates, and records that cannot be matched. These cases are part of the work because they affect what a dispatcher sees. If the interface can only be used through a scheduled export, the design and freshness of the screen will differ from a live connection.

The FDE may pair with a NorthPort developer or data engineer who owns the source system. Pairing means working through a technical task together, often by inspecting code, data, or a test environment while discussing what each person sees. It helps the customer retain context and can reveal an assumption before it is encoded into the new system.

The engineer also keeps a record of important choices: which fields the screen reads, what happens when a value is missing, and what the first version deliberately leaves out. This record gives reviewers something specific to check. It also helps the team understand the implementation if the original FDE moves to another engagement.

Prove the result with users

Once the first version runs, the FDE returns to the people who will use it. The team tries agreed examples and checks whether the screen shows the right values. A dispatcher can explain whether the flag makes sense in the workflow. The system owner can check whether the displayed values match the approved source.

Validation is the work of gathering evidence that a system behaves as intended. A polished screen is not enough. The team should include ordinary records and awkward cases such as a blank reference, a delayed update, or two records with similar identifiers. If the first version cannot tell those records apart, the team needs to show that limitation clearly instead of presenting a match as certain.

Testing can lead to a change in scope. Suppose the dispatcher asks for a button that edits the order. The FDE should record the request and find out who can authorize a write operation. That request may require new access, additional checks, and a recovery path. The team can decide whether to include it now or keep the initial version read-only while those questions are resolved.

The result of validation is not always approval to deploy. It may be evidence that a requirement is met, a defect to fix, an unanswered question, or a reason to narrow the rollout. The FDE communicates which one it is and what decision is needed next.

Deploy, hand off, and operate

Deployment makes the approved version available in its intended environment. Before release, the customer and delivery team need to agree on access, monitoring, how to report a problem, and who can pause or roll back the change. A rollback is a way to return to a previous working version if a release causes a problem.

Handoff transfers the information and responsibilities the customer needs to use and maintain the result. It may include a short architecture description, operating instructions, known limitations, contact paths, and a record of open questions. The people who will operate the system should review these materials while the FDE is still available to explain them.

Operations continue after launch. A team may notice that an export arrives late, an identifier changes, or a new exception appears. The customer needs a way to notice these conditions and decide how to respond. The FDE can help establish that approach, but the long-term owner should be clear before the engagement ends.

There is no universal rule that the FDE disappears at a particular point. Some roles include ongoing customer support or follow-on work. In other engagements, the FDE helps a customer team take over and then returns to product work. Agree on the support boundary and escalation path for the actual project.

Feed field learning back to the product

During an engagement, the FDE may find a repeated customer need. A configurable mapping for order fields could help NorthPort. If another team has the same issue, the product group might consider a general feature. A one-off rule may remain in NorthPort's configuration. The engineer records what was observed and who else may benefit, while the product team decides whether and how to change the shared product.

An observation from one engagement is useful input, not proof that every customer needs the same feature. The product team can compare the request with other evidence, maintenance cost, and the product's direction. The FDE's job is to make the field signal clear enough for that decision.

How one illustrative workday might go

FDEs do not follow one standard daily schedule. A day can change because a user is available for a workflow walkthrough, an integration fails, or a customer review is scheduled. The 2020 Palantir engineer account linked in the sources describes time spent designing, writing, and testing workflows, configuring software, handling communications, and learning about other deployments. That is one employee's account at one company and one point in time.

Here is an illustrative NorthPort day, not a schedule to copy:

1. At the start, the FDE reviews the previous test results and writes down a question about records that did not match.
2. A dispatcher walks through the task so the engineer can learn which field they trust when values differ and what they do with an unresolved order.
3. During focused build time, the FDE changes the comparison screen, reviews the code, and tries it against sample records in a test environment.
4. The source-system owner checks whether the screen reads approved fields and represents the export timing correctly.
5. To close, the engineer updates the issue list, notes what remains unverified, and sends the customer a concise summary of the day's result.

Some days have more uninterrupted engineering time. Others require more coordination because the customer is reviewing access or deciding how an exception should be handled. During an early discovery period, conversations may dominate. During integration work, coding and debugging may take longer stretches. Near launch, reviews, checks, and operational preparation become more visible.

The work has several audiences. Dispatchers explain the task and assess whether the interface helps. System owners confirm technical boundaries. Project leads decide priorities and timing. Product engineers may need a clear report about a repeated gap. A good FDE changes the level of detail for each audience while keeping the underlying facts consistent.

This diagram groups kinds of work, not hours. It does not claim that an FDE spends a fixed share of the day coding or meeting. The mix depends on the engagement, the phase of work, customer availability, and the engineer's responsibilities.

Working on site, remotely, or between teams

"Forward deployed" does not always mean that an engineer sits at a customer's office every day. An engagement may be remote, on site, or a mix. The right arrangement depends on the customer's access rules, the work being done, the team relationship, and the employer's expectations.

An OpenAI San Francisco FDE job posting checked on 5 November 2026 described a hybrid office schedule and travel requirements for that role. Those details can change and do not define every FDE position. A Palantir employee's 2020 account described remote work during the COVID-19 period. It is useful as an example of one work arrangement, not as a current guide to Palantir policy.

When travel is expected, the job description may state how much. If it does not, ask how often engineers visit customers, how visits are planned, and whether travel depends on a specific stage of an engagement. The title alone cannot answer those questions.

Remote work can make access and review convenient, but it can also make it harder to see a physical process or build trust with a new group. On-site work can help an engineer observe the real workflow, although observation still needs permission and care around private or sensitive information. A useful engagement makes clear when the engineer needs to be present and what information can be shared in each setting.

Share responsibility clearly

Customer work involves people with different authority. The FDE can design and implement a technical change, but the customer has to confirm business rules, data access, and operational ownership. Security, legal, or system owners may need to approve parts of the work. The team should write down these boundaries instead of assuming that a meeting invitation gives someone authority to decide.

For NorthPort, a dispatcher can confirm whether the mismatch view helps with a real task. The ordering-system owner can approve how records are read. The operations lead can decide which team handles an unresolved case. The FDE can document the behavior, implement the approved flow, and show the result against agreed examples. If one of these decisions has no owner, that is a project risk to surface early.

Clear ownership also helps when something fails. A runbook is a short set of instructions for operating a system or responding to a known issue. It should tell the customer what to check, who to contact, and which actions are safe. Later in the course, you will create a runbook and a fuller handoff pack.

Mistakes beginners make

1. A beginner may treat the first request as the full problem. Ask someone to show the task and its exceptions before choosing a solution.
2. A day full of meetings leaves little room to inspect, build, or check the system. Schedule conversations when they can answer a question or unblock a decision.
3. Writing code before access and ownership are clear can create work the customer has not approved. Find out who owns the source data and which actions are allowed.
4. Showing only the successful path hides missing, delayed, duplicate, and ambiguous records that may matter to the workflow.
5. Leaving handoff until the final meeting can make gaps harder to resolve. Bring future operators into review while there is still time.
6. One customer's request does not establish a universal product need. Record the request and look for evidence from other engagements before asking the product team to generalize it.

Recap and try it yourself

An FDE's work follows a changing engagement: discover the workflow, agree on a first scope, build and integrate, validate with users, deploy, prepare a handoff, support operation, and share product learning. A workday can include customer conversations and hands-on engineering, with the balance changing as the engagement changes. The customer and FDE need clear decision owners, access boundaries, and an operating plan.

Try it: choose a workflow you know and sketch one working day for an engineer supporting it. Add one conversation that would answer a question, one block of focused technical work, one review with a user or system owner, and one written handoff or update. Mark which details are assumptions. Then name the person who can approve access and the person who will own the result after release. Next, you will look at career paths into FDE work and the interviews employers may use to assess candidates.

Sources

Checked on 5 November 2026. Job requirements, office policies, and travel expectations can change.

• Forward Deployed Engineering at OpenAI, for OpenAI's description of workflow discovery, prototyping, validation, deployment, scale, and post-launch ownership.
• Forward Deployed Engineer at OpenAI, San Francisco, for one current employer example of customer delivery, production work, internal coordination, hybrid work, and travel expectations.
• A Day in the Life of a Palantir Forward Deployed Software Engineer, a 2020 employee account, for examples of designing, writing, testing, configuring, communicating, and sharing field learning. The account's work arrangement is dated and not presented as current policy.