The short answer

A forward-deployed engineer does two jobs in alternation: fieldwork (sitting with the people who run a workflow, mapping real volumes, exceptions, and systems) and shipping (building against live data in short loops until a production system exists and the client can own it). The backlog comes from the queue, not a ticket system, and done means running, not delivered.

Most descriptions of this job are written for people who want it, which makes them useless to the people paying for it. This is the buyer's version: what the work actually looks like when it is real, so you can tell when it is not.

The two halves of the job

The first half looks unlike engineering: shadowing the queue, asking operators why the Tuesday step exists, counting how many cases are clean and how many are exceptions, learning which system is the real source of truth and which one everybody works around. This half is why the role exists at all: the discipline's founding bet is that systems designed from briefs automate imagined workflows, and the fieldwork is how the real one gets learned. The second half is engineering at full seniority: integrations into the systems of record, prompts with boundaries, golden sets, deployment in the client's cloud, in loops short enough that the operators see progress weekly.

A representative week

  • –Monday: two hours watching intake handle real arrivals; three exceptions nobody mentioned in the kickoff get written down. The scope adjusts before it calcifies.
  • –Tuesday to Thursday: shipping: the calendar integration, the extraction step, the refusal boundaries; each increment demoed against live data to the person who runs the queue.
  • –Friday: the eval suite grows by the week's discoveries, the runbook grows by a page, and the workflow owner hears the honest status, including anything that argues for building less.

The backlog comes from the queue, not the ticket system. Done means running, not delivered.

What makes it different from adjacent jobs

Against ordinary product engineering: requirements are discovered, not received, and the customer is three desks away rather than an abstraction. The pairing is not new; Palantir institutionalized it fifteen years ago, and the job has kept its shape through every owner since. Against consulting: the deliverable is a system, so the week ends in commits, not decks. Against the pre-sales roles it gets confused with: the FDE's clock starts where the sale ends. The pairing of senior engineering with fieldwork is genuinely rare, which is why the market fights over it and why the throughput, when it lands, feels disproportionate: one person who can both find the right thing and build it skips the entire telephone game between those steps.

What a buyer should watch for

The job description above is also an inspection checklist. In week one, an embedded engineer should be conspicuously present in the workflow and asking questions that sound almost naive; distance and confidence that early are the warning, not the reassurance. From week two, increments should be visible against your real data on the cadence the engagement anatomy lays out. And throughout, the writing should accumulate: maps, evals, runbooks, the artifacts that make the eventual handover real. An engineer doing this job leaves a paper trail of your operation understood. An engineer doing a different job under the same title leaves a deck.