The Forward Deployed Engineer: Role and Responsibilities#

Conceptual Explanation#

The FDE role is best understood by contrast with adjacent roles that it superficially resembles:

Sales Engineer (SE): Demonstrates product capabilities to prospects. The SE's primary accountability is to the sales cycle — moving deals forward. Technical depth is in service of persuasion. The SE rarely writes production code and is typically not present after the contract is signed.

Professional Services (PS) Consultant: Executes a defined project scope under a statement of work. Accountable for deliverable completion and project timeline. Optimizes for scope control rather than client success. Exits when the contract term ends.

Solutions Architect: Designs the technical architecture and hands it off to an implementation team. Depth in the product but typically not embedded in the client's day-to-day engineering environment.

Forward Deployed Engineer: Writes production code inside the client's environment. Accountable for client value realization — adoption, expansion, and measurable outcome improvement. Present throughout the lifecycle from discovery through post-launch optimization. Acts as the client's internal advocate with the product team and as the product team's technical representative to the client.

The FDE's unique position is that they are simultaneously the most technical person in most client meetings and the most client-aware person in most product meetings.

Core Architecture: The FDE Engagement Lifecycle#

An FDE engagement moves through a defined sequence of phases, each with specific activities, deliverables, and exit criteria.

Discovery → Assessment → POC Design → POC Execution
    → Architecture Review → Production Planning → Launch → Expansion

Phase 1 — Discovery: The FDE maps the client's technical environment, organizational structure, and use case landscape. Output: Discovery Summary document.

Phase 2 — Assessment: The FDE evaluates AI readiness across three dimensions: data maturity, infrastructure readiness, and organizational readiness. Output: AI Readiness Assessment report.

Phase 3 — POC Design: The FDE defines a scoped proof-of-concept with explicit success criteria, resource requirements, and production path. Output: POC Design document with signed-off success criteria.

Phase 4 — POC Execution: The FDE builds the POC alongside the client's engineering team. Output: Working POC with evaluation results against success criteria.

Phase 5 — Architecture Review: The FDE facilitates a structured review of the proposed production architecture. Output: Architecture Review Report with identified risks and mitigations.

Phase 6 — Production Planning: The FDE designs the migration path from POC to production and aligns the client's team on operational requirements. Output: Production Architecture document and go-live plan.

Phase 7 — Launch: The FDE provides technical support during production deployment. Output: Live production system with baseline metrics established.

Phase 8 — Expansion: The FDE identifies additional use cases and begins the cycle again. Output: Expansion use case pipeline and updated ROI model.

Architecture Diagram#

Common Mistakes#

1. Starting with the product instead of the client's problem. New FDEs default to product demos. Experienced FDEs spend the first 60% of the discovery phase listening and mapping the client's environment — not presenting.

2. Under-scoping the POC. A POC that runs against dummy data with a hardcoded prompt is not a POC — it is a demo. A real POC must run against production-representative data with the client's actual system constraints.

3. Over-promising on timeline without understanding the client's security review process. Healthcare and financial services clients have multi-week security reviews that the FDE cannot accelerate. If the FDE does not surface this constraint in Discovery, it becomes a delay that damages trust.

4. Losing the stakeholder map. Client stakeholders change. The compliance officer who approved the POC may not be present at the production architecture review. FDEs who do not maintain a current stakeholder map get surprised when deals stall due to a new decision-maker.

5. Not closing the product feedback loop. Field observations that are not formally communicated to the product team are invisible. FDEs who do not write structured feedback reports lose their ability to influence the roadmap — which is one of the highest-leverage activities the role enables.

6. Treating the POC as the finish line. POC success is not client success. The FDE's accountability extends through production launch and the first measurable outcome improvement. Celebrating a POC completion and disengaging is the most common cause of failed FDE engagements.

Best Practices#

• Complete pre-discovery research before the first client meeting. Arriving informed signals respect for the client's time.
• Define POC success criteria in writing before the first line of code is written. Verbal success criteria are renegotiated.
• Build discovery deliverables using structured templates so that pattern recognition across clients is possible.
• Maintain a current stakeholder map updated after every client interaction.
• Submit a structured product feedback report after every POC — good outcomes and bad.
• Never let a client meeting end without a specific next action assigned to a named owner with a date.
• Specialize. A healthcare FDE with deep FHIR and HIPAA knowledge is 3x more effective than a generalist FDE in that environment.

Alternatives#

The FDE model is not the only way to close the client integration gap:

Trade-offs#

Cost: FDEs are expensive. They are senior engineers allocated to client work rather than product development. The ROI must be justified by the revenue impact of the accounts they support. FDE coverage is typically reserved for strategic accounts.

Product development velocity: Every hour an FDE spends on client work is an hour not spent on product code. Organizations that grow FDE headcount aggressively risk slowing product development if they do not also grow the product engineering team.

Repeatability vs. customization tension: FDEs who over-customize for each client create institutional knowledge that does not transfer. FDEs must balance client-specific work with building reusable assets (templates, libraries, playbooks).

Scope creep: FDEs who are too embedded in a client organization can lose objectivity. The most effective FDE relationships have clear boundaries: the FDE designs and guides, the client team implements and owns.

Interview Questions#

Q: How does an FDE differ from a Sales Engineer, and why does that distinction matter at an enterprise AI company?#

Category: Architecture Difficulty: Senior Role: FDE / AI Architect

Answer Framework:

A Sales Engineer (SE) is primarily aligned to the sales cycle — their success is measured by deal closure. They demonstrate product capabilities to prospects and handle technical objections during the pre-sale process. They rarely write production code and typically disengage after the contract is signed.

An FDE's accountability is fundamentally different: client value realization measured by adoption, expansion, and measurable outcome improvement. The FDE is present throughout the full engagement lifecycle — from technical discovery through post-launch optimization. They write production-grade code inside the client's environment, attend architecture reviews, and translate field friction back to the product team.

The distinction matters at an enterprise AI company because AI products fail disproportionately at the integration boundary. The FDE is the engineer who ensures that boundary is crossed successfully. An SE can sell a product; an FDE determines whether it actually works.

Key Points to Hit:

• SE = pre-sale, demo-oriented, deal metric
• FDE = full lifecycle, production-oriented, client success metric
• FDE writes production code; SE typically does not
• FDE's product feedback loop is a distinct organizational value

Follow-up Questions:

• How do you measure FDE success?
• At what deal size or client complexity does an FDE become necessary?

Red Flags (What NOT to say):

• "They're basically the same role with different titles"
• Framing FDE success purely in terms of technical delivery milestones

Q: You've just been assigned to a Reference Healthcare Organization that is evaluating AI for clinical documentation. Describe your first 30 days.#

Category: System Design Difficulty: Principal Role: FDE

Answer Framework:

Days 1–5 would be pre-discovery research: confirming the EHR vendor (likely Epic given market share), checking whether they have FHIR R4 App Orchard credentials, researching the organization's bed count and annual discharge volume, reviewing any public procurement or conference presentations about their IT environment, and understanding their existing documentation workflow.

Days 6–10 would be the discovery kickoff. I would facilitate a 90-minute structured session mapping the current discharge summary workflow from admission to filing — not presenting the product. The output is a Discovery Summary document identifying the pain points, the current state architecture, and the open technical questions.

Days 11–20 would be the Assessment phase: getting access to a sandbox FHIR environment to evaluate data quality and availability, understanding the client's security review process for new applications (HIPAA BAA, App Orchard timeline), mapping the stakeholder landscape including the compliance officer and clinical informatics director, and running a preliminary data quality assessment against a sample of discharge encounters.

Days 21–30 would be POC Design: based on assessment findings, propose a scoped POC with explicit success criteria — something like "AI-generated discharge summary drafts for 50 randomly selected inpatient encounters, achieving physician edit rate < 30% and section completion rate > 95%, measured by two hospitalist reviewers." Get the success criteria signed off in writing before writing a line of code.

Key Points to Hit:

• Pre-discovery research before first meeting
• Discovery as listening, not presenting
• Assessment produces a written report with open questions resolved
• POC success criteria defined in writing before execution begins

Follow-up Questions:

• What if the client wants to start the POC immediately?
• What do you do if the FHIR sandbox data is of poor quality?

Red Flags (What NOT to say):

• Starting with a product demo in week 1
• Skipping the POC success criteria definition

Q: An FDE engagement has a technically successful POC but the client is not moving to production. What do you investigate?#

Category: Behavioral Difficulty: Senior Role: FDE

Answer Framework:

A POC-to-production failure is almost never a technical problem — it is almost always an organizational, financial, or political problem. The investigation begins with the stakeholder map: who approved the POC, who needs to approve the production deployment, and are they the same people? If there is a new decision-maker (a new CIO, a new compliance officer, a new CMO), the FDE needs to restart the value conversation with that stakeholder.

The second investigation is the procurement path. Healthcare organizations frequently have capital budget cycles that are separate from operational budgets. A POC funded from an innovation budget may need a new capital request to move to production. The FDE must understand the procurement calendar.

The third investigation is the organizational change management dimension. POC success demonstrates technical feasibility; it does not demonstrate that clinical staff will adopt the tool, that the workflow redesign is feasible, or that physician champions are in place. If the POC was run by IT with no clinical champion involvement, that gap needs to be addressed.

Finally, review whether the success criteria from the POC are actually compelling to the production decision-makers. A technical metric (section completion rate 97%) may not resonate with a CMO who cares about physician satisfaction and malpractice risk.

Key Points to Hit:

• POC-to-production failures are organizational, not technical
• Stakeholder map may have changed since POC approval
• Procurement cycle timing is a common blocker
• Clinical champion engagement during POC is essential

Follow-up Questions:

• How do you prevent this situation in the first place?
• When do you escalate to account leadership?

Red Flags (What NOT to say):

• Focusing exclusively on technical explanations for the delay
• Proposing to build more features to unblock the decision

Key Takeaways#

• The FDE role is distinct from SE, PS Consultant, and Solutions Architect — it is accountable for client value realization, not deal closure or project delivery
• FDE success is measured by adoption rate, expansion use cases, and net revenue retention — not by POC completion
• The engagement lifecycle has eight stages; Discovery and POC Design are the highest-leverage stages
• Pre-discovery research is required before the first client meeting
• POC success criteria must be defined in writing before execution begins
• The product feedback loop from FDE field observations to product roadmap is one of the highest-value activities the role enables
• Healthcare FDEs require specialized knowledge: HIPAA, FHIR, clinical workflows, FDA SaMD awareness
• POC-to-production failures are almost always organizational, not technical