What Does a Forward Deployed Engineer Do Each Day?

Why is there no standard FDE day?

A standard calendar assumes that the work arrives in a stable form. Forward deployed work does not. The engineer may start with a business outcome, partial access and several versions of how the process supposedly works. The immediate task is to find which uncertainty is expensive enough to block the next decision.

Current role descriptions support this phase-based view. OpenAI’s healthcare FDE role ^[1] spans discovery, architecture, implementation, evaluation, production deployment, adoption and handoff. OpenAI’s UAE FDE role ^[2] describes ownership of the delivery state from first prototype to stable production. OpenAI’s forward deployed software engineer role ^[3] adds detailed scoping and an experiment-driven build approach.

The same pattern appears outside OpenAI. Palantir’s FDSE description ^[5] places engineers side by side with customers to understand difficult problems and build the solution. Anthropic’s FDE description ^[6] includes production applications inside customer systems, deployment support and reusable field patterns. These are not separate jobs stitched together. They are different states of one delivery problem.

This is why a job description can truthfully include customer conversations, code, evaluation, deployment and documentation without implying that every day contains equal parts of each. For a deeper explanation of the ownership boundary, read what a forward deployed engineer is.

How does an FDE use time across different phases?

There is no defensible universal percentage for coding, meetings or travel. A better model is to estimate the centre of gravity for each phase. The chart below is an editorial model built from the work categories in current FDE descriptions. It is designed to explain the shift in work, not to report employer time-sheet data.

The percentages are an illustrative model. They should not be presented as survey findings or employer benchmarks.

What does a technical discovery day look like?

Technical discovery is often misunderstood as a sequence of requirement meetings. That framing is too passive. The FDE is trying to discover the smallest set of truths needed to make a safe build decision.

The day usually starts with evidence, not a presentation. The engineer checks whether the team has representative cases, working credentials and access to the environment where the workflow will run. A missing permission can make a polished architecture discussion irrelevant.

Next comes direct observation. OpenAI’s workflow-mapping guidance ^[7] argues for understanding multi-step work rather than isolated AI tasks. For an FDE, that means watching how an operator handles normal cases and exceptions. The stated process may say “review and approve.” The actual process may include an undocumented spreadsheet, a call to a specialist and a manual correction before approval. That hidden path changes the system design.

What does a production rollout day look like?

A rollout day is less predictable because customer behaviour and system behaviour become visible at the same time. The FDE has to protect two things: the launch criteria and the ability to recover.

The day begins with production signals. OpenTelemetry’s observability guidance ^[10] describes traces, metrics and logs as the signals needed to ask why a system behaves as it does. Google SRE’s monitoring guidance ^[11] recommends low-noise alerting and focuses user-facing monitoring on latency, traffic, errors and saturation. For an AI workflow, those signals need workflow context. A request can return HTTP 200 and still produce the wrong action.

Model behaviour also needs its own evidence loop. OpenAI’s agent-evaluation guide ^[9] recommends using traces to identify workflow-level failures, then moving to repeatable datasets and eval runs. OpenAI’s evaluation best practices ^[8] adds continuous evaluation as the system changes. This is why a rollout day includes both production debugging and eval maintenance.

Recovery deserves explicit calendar time. AWS guidance on rollback safety ^[13] explains why deployments can become hard to reverse when code and data states diverge. AWS guidance on retries and backoff ^[12] shows how a seemingly small dependency failure can amplify load. An FDE who ignores these control paths may ship a fast demo and create a fragile production system.

How much of an FDE’s day is spent coding?

No credible public source supports one universal percentage. The coding share depends on what is blocking progress and how the employer divides work between FDEs, forward deployed software engineers and deployment leads.

The better question is: Is code the fastest safe route to the evidence we need? If the team does not agree on the workflow, more code creates rework. If the critical uncertainty is whether a legacy API can support the required action, a thin integration may be more useful than another meeting.

OpenAI’s FDSWE description ^[3] explicitly uses an experiment-driven, iterative approach to full-stack solutions. OpenAI’s UAE FDE role ^[2] frames the broader job as scoping, sequencing and building while owning the delivery state. The practical distinction is useful: the FDE does not optimise for maximum coding time. The FDE optimises for the fastest reliable movement toward production value.

A coding hour can serve four different purposes

What does an FDE produce during a normal week?

The most reliable way to judge a week is to inspect the artifact trail. A calendar can look busy while the delivery state remains unchanged. Artifacts make the new state visible to someone who was not in the room.

OpenAI’s healthcare role ^[1] explicitly includes reusable architectures, integration patterns and evaluation harnesses. Anthropic’s role ^[6] similarly asks FDEs to codify deployment patterns and return insight to product teams. This second output matters. A deployment that works once creates customer value. A pattern that reduces the cost of the next deployment creates platform leverage.

What hidden work makes FDE days difficult?

People often picture the role through code, whiteboards and customer meetings. The harder work sits underneath those visible activities. It includes waiting for access, reconciling conflicting definitions and protecting a delivery plan from external dependencies.

The hardest skill is not tolerance for chaos. It is the ability to restore a coherent thread after the day changes. OpenAI’s deployment-lead role ^[4] makes this explicit through milestones, dependencies, sequencing and readiness. A strong FDE can explain the current state in a few lines: what outcome matters, what evidence exists, what risk remains and what happens next.

How do travel and customer proximity change the routine?

Travel is common in some FDE roles, but travel is a delivery mechanism. It is valuable when being present reduces information latency, unlocks an environment or improves a rollout decision.

Current public roles show variation. OpenAI’s healthcare FDE listing ^[1] states travel up to 50 percent. Palantir’s current FDSE listing ^[5] describes a hybrid role and travel requirements that can vary by assignment. Anthropic’s FDE listing ^[6] estimates 25 percent travel based on location. These figures belong to those listings, not to the role family as a whole.

What can a two-week FDE engagement look like?

The following calendar compresses an engagement into ten working days to show the cadence. It is not a promise that a production deployment should take two weeks. Regulated workflows, deep integrations and enterprise change can require much longer.

The calendar contains feedback loops on purpose. New production failures should become test cases. Anthropic’s evaluation guide ^[14] separates capability evaluation from regression evaluation. The first asks what the system can do. The second protects behaviour that already works. An FDE needs both because progress is not useful if yesterday’s success disappears.

Who is likely to enjoy the FDE daily routine?

The role tends to suit engineers who like direct evidence, broad ownership and purposeful context switching. It may frustrate someone who wants every requirement settled before build or needs uninterrupted coding blocks as the default.