Forward Deployed Engineering

Customer delivery and product learning

Forward deployed engineering (FDE) is hands-on engineering close to customer operations: understanding a problem, implementing a solution, and learning from its use. Organizational arrangements vary. The AWS delivery account, for example, places embedded delivery capability within partner organizations and identifies customer self-sufficiency as an intended outcome. [1]

The mandate must specify how FDEs collaborate with customer operators, product engineering, support, and commercial teams. Operators understand daily work; commercial commitments establish expectations; engineering and support need explicit implementation and operating responsibilities. These boundaries cannot be inferred from the title: historical FDE work has included platform operation, integration, custom solutions, and customer enablement. [2]

An illustrative support-triage engagement makes these responsibilities tangible. A support team requests automatic assignment of incoming requests. The intended outcome spans intake, triage, resolution, and recording the result; assigning a category is only one step. This example supplies operating decisions, not customer performance measurements. [4]

Discovery of the operating problem

Discovery investigates users, work, constraints, and desired outcomes before committing to a solution. A requested feature is a starting hypothesis. The GOV.UK discovery guide explicitly allows discovery to end with a different intervention or a decision not to build. [5]

Contextual inquiry combines observation of everyday work with questions about what is happening. Follow recent cases using the worker’s actual records and tools, including exceptions and workarounds. Asking for explanations reveals reasoning but can change behavior; silent observation preserves more natural activity. The contextual research method makes that tradeoff explicit. [6]

Jobs to Be Done frames discovery around progress sought in particular circumstances. For the support operator, the job may be finding an accountable resolver without losing the customer’s explanation. That includes functional progress and social concerns, such as avoiding an unsupported promise to another team. [8]

A testable problem statement names the affected worker, failure, and consequence: operators cannot identify the responsible team when account context is missing, causing transfers and repeated investigation. This directs discovery toward context availability and ownership rules, rather than prematurely committing to a classifier. [5]

Workflow and decision authority

A workflow comprises the activities and decisions carrying work toward an outcome. It includes mental tasks, waiting, parallel activity, and exchanges between organizations—not just API calls. The AHRQ definition makes human work part of the system boundary. [10]

A stakeholder is a person, team, or organization with an interest in the system and whether it meets their needs. Purchasers and direct users are only part of that population. Decision rights specify which stakeholders can authorize particular changes. [11]

Map observed practice alongside the documented process, then validate discrepancies with participants. A swimlane map assigns activities to responsible roles; the figure instead names owners in node details. Queues and handoffs expose where work accumulates, but a process map alone establishes neither time savings nor value. [17]

Conflicting incentives need resolution before implementation. A sponsor may want more automation while operators inherit checking work and support inherits failures. Ask whether the receiving roles have time and authority to perform their new duties. Agreement to a demonstration is not an agreement to operate its result. [18]

Value agreement and delivery boundaries

A value hypothesis states which change should improve which outcome for which work. Task correctness, workflow performance, and business value are distinct: correct routing might reduce transfers, but shorter resolution requires the destination team to act. Define success before selecting a model, using actual domain examples rather than public benchmark rankings. [19]

A guardrail is an outcome that must remain acceptable while another improves. For triage, resolution speed might improve only while routing errors, repeated transfers, and operator burden remain within agreed limits. Guardrails constrain optimization; maximizing a usage count or minimizing human involvement is not the objective. [20]

A vertical slice is a narrow release spanning a complete user outcome. Here it could read an eligible request, propose a destination, obtain operator confirmation, and record the accepted assignment. That is more useful than separately completing a classifier, dashboard, and connector without joining them into usable work. Story mapping organizes such releases across activities and exceptions. [21]

Evaluations are systematic checks against intended-use criteria. They should distinguish the agent’s claimed success from the resulting environment state. Evals develops scenario selection and judgment methods; locally, the acceptance agreement determines which outcomes matter and who judges them. [22]

A new request changes more than the implementation backlog. Extending assignment into automatic resolution introduces new behavior, consequences, and acceptance evidence. Restate the user, need, reason, and testable acceptance criteria before treating that extension as part of the existing commitment. [24]

Customer variation and reusable capability

Two customers can request automatic routing while requiring different behavior. One permits assignment by account tier; another requires supervisor approval for the same tier. Different record schemas create a separate integration difference. Shared wording does not establish shared policy, while different wording can conceal the same underlying capability. [25]

A practical reuse decision weighs recurrence, policy meaning, interface stability, maintenance burden, strategic fit, and a willing owner. This is an engineering judgment, not a universal scoring rule. Generalizing unstable policy can create more exceptions than it removes; retaining a bounded local implementation can be the more maintainable choice. [3]

Platform engineering builds shared capabilities and interfaces for multiple engineering users. A repeated customer need becomes a platform candidate only when that shared service boundary is useful. AI Platform Engineering covers its architecture and operating model; field delivery should not silently inherit responsibility for operating a new internal platform. [26]

Integration into existing work

A system of record is the designated authoritative source for a particular business fact. A data contract records the producer–consumer agreement around that data. Establish field meanings, identifiers, freshness expectations, quality, ownership, and support contacts—not just JSON types. The Open Data Contract Standard supplies a broader checklist; completing it does not prove compliance. [15]

Workflow automation coordinates activities, state, and people through software. Keep explicit control flow, tool boundaries, and information restrictions in code; use model assistance where interpretation is useful. Workflow Automation develops execution and recovery patterns. The FDE’s local responsibility is agreeing how those mechanisms fit the customer’s work. [27]

Human review means inspecting a proposed action before deciding whether it may proceed. Show concrete parameters, not merely a tool name, and enforce the decision in the execution path. An approval interface that the agent can bypass does not establish authority. [30][31]

Customer-system integration also translates meaning. In the VoiceOps account, generated customer intent and resolution status are mapped into customer relationship management records, with operators validating and editing prepopulated fields. That illustrates a useful workflow placement, but does not establish that every downstream write waits for confirmation. [32]

Operational acceptance

Operational acceptance applies the delivery agreement to representative work and consequential exceptions. Customer operators should judge outcomes and record reasons for rejection. Those explanations expose domain criteria that a bare approval rate hides, and can become reusable failure categories. [33]

Review quality itself needs testing. In a proctoring study, trained reviewers accepted some fabricated AI alerts on legitimate historical sessions. Later evidence-focused guidelines accompanied improved rejection, although different sessions and timing prevent attributing the change solely to those guidelines. A review step is an imperfect safeguard whose behavior depends on its design. [34]

Limited rollout permits reliance for a restricted population after acceptance; wider reliance remains conditional on outcomes and operating capacity. Rollback restores an earlier software or configuration version for future work. It cannot retract an already delivered harmful instruction, so the acceptability of live exposure must be decided before relying on reactive monitoring. [35]

Rehearse recovery with the receiving operator. Compensation is a new business action that counters completed work, not an erasure of history; it can fail and may not restore the original state. Record progress and escalate irrecoverable effects. Evals covers scenario coverage; acceptance additionally requires authority and practical ability to respond. [36]

Adoption and realized customer value

Adoption is sustained, appropriate use in the intended workflow. It requires workable interactions, confidence, accountability, and allocation of duties. Normalization Process Theory explains why introducing a tool can add work when people repeat its output checks rather than replace old activities. [18]

Non-use needs a cause before it needs a remedy. Separate lack of exposure or access from awkward workflow fit, justified rejection of unreliable outputs, abandonment after failed attempts, and continued dependence on the implementer. Observe cases and ask for reasons; forcing acceptance can suppress useful evidence about the system. [39]

Measure across all eligible work, including rejected suggestions, failures, manual assistance, and escalations. A support-assistant study assessed access to assistance through resolved issues per hour alongside handling time, resolution, and customer satisfaction; its main analysis was not restricted to accepted suggestions. That avoids selecting only successful interactions as the population. [39]

The VoiceOps speaker reported average after-call administrative work falling from 6.3 to 3.1 minutes. These are post-call work averages, not call duration or model latency. Without sample size, observation window, or comparison controls, the account illustrates a measurable workflow target but cannot establish the causal saving for another deployment. [40]

Attribution depends on a credible comparison. Representative observation, phased introduction, and suitable comparison groups can help, but changing workload, selected participants, and simultaneous process changes remain threats. METR’s follow-up productivity work illustrates how participation and task selection can undermine an estimate. Evals develops the methods; report uncertainty rather than converting a pilot association into a guaranteed return. [42]

Expansion is justified when the intended operation improves within its guardrails and the added capacity has a valuable use. Faster engineering or more generated output remains an intermediate result when another part of the business is the binding constraint. Revise or stop when review burden and ongoing costs consume the expected gain. [43]

Sustainable operating ownership

Handoff is an accepted transfer of operating knowledge, authority, and responsibility. Google’s SRE engagement account provides a useful analogy: documentation, system instruction, access, and hands-on exercises support progressive transfer while the development team remains available. Sending documents alone does not establish receiving capability. [44]

A runbook describes how to perform a recurring operational task or respond to a known failure. It needs prerequisites, diagnostic evidence, actions, and escalation contacts. Incident findings should update these instructions and response workflows, so the handoff remains connected to operating experience rather than becoming a frozen description. [45]

A practical acceptance exercise has the receiving team run routine work, diagnose an unavailable dependency, and recover or escalate without the original implementer directing each step. Record missing knowledge and authority, assign maintainers for customer-specific documentation and known limits, then repeat the failed portions. This is a proposed handoff test, not a claim about every FDE engagement. [44]

The receiving owner may be a customer team or an internal service team. Customer enablement can reduce repeated vendor-led work without eliminating all FDE responsibilities. Continuing support, withdrawal, and eventual retirement should therefore depend on accepted responsibilities and ongoing usefulness, rather than an assumption that every engagement ends with vendor departure. [49]

Field evidence and product decisions

A useful field record contains the underlying problem, workflow context, observed frequency, workaround, outcome evidence, customer variation, and maintenance burden. Preserve the customer’s circumstances while grouping related needs. A request for another control may reveal a documentation gap, an unclear interaction, or a missing capability; implementing the requested control immediately can hide that distinction. [50]

Productization turns a local solution into a supported capability with an owner and lifecycle. Decagon reports moving promotional-policy changes from custom engineering into configuration, debugging, and testing by its deployment team. The useful change is who can safely perform the work and what the product supports—not merely where the original implementation was written. [3]

Open questions

1. 01

   Reliable reuse boundaries remain difficult to establish before maintaining several deployments. Similar requests can hide incompatible policies, while excessive local work duplicates support effort. Progress would be demonstrated by a shared capability that preserves differing policies and measurably reduces later implementation and maintenance work. [25][56]

2. 02

   Net FDE value remains hard to attribute when pilots select willing users or unusually tractable work. Hidden assistance and changing workloads can inflate apparent gains. Progress requires outcomes across a predefined eligible population, including non-use and failed work, with implementation and operating effort recorded. [42]

3. 03

   Durable handoff remains uncertain when receiving teams rarely encounter serious failures. A successful exercise may not predict operation after personnel, policies, or integrations change. Progress would include repeated independent recovery exercises and documented responsibility changes after real incidents. [44][57]

4. 04

   Human review must balance catching consequential mistakes against introducing enough work to erase the benefit. Approvals can also become misleading feedback labels. Progress would show reviewers rejecting seeded errors while preserving usable workflow performance, with evidence kept separate from model-influenced agreement. [58][34]