Hiring playbook / Role spec for the buyer side
Forward deployed engineer roles: the eleven-line spec
Most guides on this question describe what a forward deployed engineer does at a desk. That description is fine for candidates and almost useless for the buyer about to post or contract one. This page is written for the buyer side. The role is best specified by output (four artifacts in your repo by calendar day 35) and three contractual gates (week-1 first PR, week-2 prototype, week-6 handoff). The eleven-line YAML below is the version we hand to clients before the SOW gets drafted.
Direct answer (verified 2026-05-08)
A forward deployed engineer role is best defined by output (four files in your repo) and three contractual gates (week 1, week 2, week 6), not by a job-title responsibilities list. The four files are rubric.yaml, eval/cases.yaml, .github/workflows/pilot-gate.yml, and runbook.md. The three gates are: week 1 first PR merged to your main, week 2 prototype passes the rubric in your staging (with refund-and-exit if missed), week 6 production handoff plus a 90-minute transfer session.
Sources reviewed: The Pragmatic Engineer (Forward Deployed Engineers), Palantir, A Day in the Life of an FDSE, a16z, Trading Margin for Moat.
The eleven-line role spec, copyable
Paste this into the SOW exhibit. Paste a prose translation into the public job description. Every line either ties to a deliverable that ends up in your repository or to a gate that decides whether billing continues.
The interesting line is exit_clause. Most FDE-flavored contracts skip it because it is uncomfortable to negotiate. That is exactly why it belongs in the role spec. If the engineer cannot get the prototype to clear the rubric in your staging by calendar day 14, the engagement pauses and billing pauses. The clause is the cheapest test of whether the seller actually thinks they can ship.
What the role spec must contain (and what most JDs skip)
The seven items below are the difference between an FDE role spec and a generic senior-engineer JD with FDE in the title. If the spec is missing any of them, the role is structurally something else (a contractor, a platform seat, a vendor tie-in) and should be priced and reviewed on those terms.
The seven items every FDE role spec must contain
- Output, not job duties: replace the responsibilities bullets with the four files the engineer leaves in your repo by calendar day 35.
- Three calendar gates in writing: week 1 first PR, week 2 prototype passes the rubric in your staging, week 6 production handoff plus a 90-minute transfer session.
- Refund-and-exit at day 14: if the prototype misses the rubric on day 14 in your staging, the engagement pauses and billing pauses.
- IP ownership clause: client owns the repo, the eval harness, and the runbook. No vendor-attached runtime. No platform license that has to keep being paid.
- Model neutrality clause: the engineer ships against the model provider you choose (Anthropic, OpenAI, Bedrock, Vertex, Azure OpenAI, or open-weight).
- Commit access, day 1: named senior engineer in your GitHub, Slack, and standup on calendar day 1. If access takes two weeks, the role is structurally staff-aug.
- Eval discipline as a hiring bar: the candidate must show a redacted rubric.yaml from a previous engagement on the first call.
The five role types you will meet on the first call
The role title is the same on all of them. The contracts, the IP terms, and the leave-behinds look very different. The cleanest way to draw the line is along two dimensions: who the engineer reports to during the engagement, and what is in your repository when the engineer leaves. The table compares a vendor-neutral studio engagement against the four other shapes (model-lab residency, big-firm consulting practice, platform-vendor FDE, in-house FDE contract) on the dimensions that actually matter when the role spec is being drafted.
| Feature | Vendor-tied or staff-aug variants | Vendor-neutral studio engagement |
|---|---|---|
| Who the engineer reports to during the engagement | The vendor. Engineer is in the vendor's standup, syncs with you weekly. | Your tech lead. Engineer is in your repo and your standup. |
| Who owns the eval rubric at week 6 | Vendor's platform or vendor's notebook. You see a number. | Your repo, your CI gate, your file. |
| What you keep when the engagement ends | A platform seat or a vendor-API tie that has to keep being paid. | rubric.yaml, eval/cases.yaml, pilot-gate.yml, runbook.md |
| Engagement length | 6 to 12 months, time-and-materials. | 2 to 6 weeks, fixed scope, refund-and-exit at day 14. |
| Engineer seniority | Pool of mid-level engineers, named after signature. | Named senior or staff. CV before contract. |
| Exit clause | 30-day notice, no rubric tied to the SOW. | Miss the day-14 prototype rubric, refund and exit. |
For the long version of how the role fragmented, see the three-era history of the forward deployed engineer. For a side-by-side of the four AI-flavored vendor types selling the title in 2026, see AI forward deployed engineer.
The day-14 acceptance gate, in calendar steps
The gate that decides whether the engagement continues is on calendar day 14, not at the end. By day 14 the prototype runs in your staging, the rubric is committed to your repo, the eval cases are committed to your repo, and CI blocks merges below the prototype-tier floor. If the prototype misses the floor, the contract pauses. The full calendar walk:
Calendar day 0: scoping call
One-pager with the production behavior to ship, the rubric axes, and the staging environment the engineer will push to. No statement of work without a one-pager.
Calendar day 1: commit access
Named senior engineer in your GitHub, Slack, and standup. If access takes two weeks, the contract is structurally staff-aug, not FDE.
Calendar day 7: first PR merged to main
A small, real PR in your repo. Not the full prototype. The point is to verify the engineer can actually ship in your environment.
Calendar day 14: prototype gate
Prototype runs in your staging. Rubric is committed to your repo. Eval cases are committed to your repo. CI gate exists. If the prototype misses the prototype-tier floor, the contract pauses and billing pauses. This is the only gate that decides whether the engagement continues.
Calendar day 35: leave-behind in your repo
Four files in your repository: rubric.yaml, eval/cases.yaml, .github/workflows/pilot-gate.yml, runbook.md. Architecture doc on Notion or Confluence is a bonus, not a substitute.
Calendar day 42: 90-minute transfer session
Engineer walks your on-call team through the runbook, the rubric ratchet schedule, and the eval cases that catch the failure tail. After the session, the engagement ends and your team owns it.
The reason the gate sits on day 14 (not day 30 or day 42) is that day 14 is early enough to fix or exit without sunk-cost pressure, and late enough that the engineer has had time to push back on the rubric in writing. For the long-form version of the day-14 review, see the FDE week-2 prototype rubric.
Why this beats a job-duties bullet list
A typical FDE JD lists eight bullets under responsibilities: own the customer relationship, write production code, run evals, document the system, and so on. Every one of those bullets is true. None of them are testable on calendar day 14, on a staging environment, with a rubric committed to your repo. An output-and-gates spec is testable. The candidate either pushed a PR to your main on day 7 or did not. The prototype either cleared the rubric on day 14 or did not. The runbook either lives in your repo on day 35 or does not. The spec collapses to a yes-or-no every two weeks, which is what a buyer needs when the role is six weeks long.
The other reason the role spec should be written this way is that the title on the first call is no signal. Five vendors will tell you they sell forward deployed engineers. The leave-behind file list is the only honest filter. If the vendor cannot agree on the file list before the SOW gets signed, the role they are selling is not the role you are buying.
Drafting an FDE role spec for a six-week ship line?
Bring the one-pager. We bring the rubric.yaml from a recent engagement and walk it line by line.
FDE role spec, frequent questions
What is a forward deployed engineer role, in one sentence?
A senior or staff engineer embedded in the buyer's repository, GitHub, Slack, and standup for two to six weeks, paid against an output-defined SOW (specific files in the buyer's repo) and an exit clause tied to a day-14 acceptance gate, not against a job-title responsibilities list.
Should we post the FDE role as a full-time hire or as a fixed-fee engagement?
Post the role two ways and let the structure decide. If the work is one specific production agent or ML system with a six-week ship line, contract a fixed-fee engagement; the rubric and runbook are the leave-behind. If the work is a six-quarter platform rollout with seven internal teams to shepherd, hire full-time and budget for ramp. The mistake we see most often is contracting full-time for a six-week problem and ending up with a senior engineer waiting for the next thing on calendar day 50.
What seniority level should the FDE role spec require?
Senior or staff, not mid. The role requires disagreeing with the buyer's product manager in writing about which case the rubric should be tightened around, in week three, before the prototype is hardened. A mid-level engineer will fold on the rubric and ship code that passes the average and fails the failure tail. If the budget will only support mid-level, the work is staff-aug, not an FDE engagement, and the role spec should say so.
What technical skills should the role spec name?
Production fluency in one application language (Python is the de facto standard, TypeScript or Go on the second axis), SQL plus one query engine, Docker plus Kubernetes, one of AWS, GCP, or Azure, an infrastructure-as-code tool. For AI engagements specifically: ragas plus a custom rubric for evaluation, MCP-native or A2A-compatible orchestration, and at least one of LangGraph, Pydantic AI, or a hand-rolled DAG. Soft skill bar: written disagreement with the product manager about the rubric, in week three, in a thread the buyer can read.
How is an FDE role different from a contractor or staff aug role?
Structurally, three things. First, the FDE owns the design from the scoping call; a staff-aug contractor takes a Jira ticket the buyer already wrote. Second, the FDE writes the rubric the work is graded against; staff aug is graded against story points. Third, the FDE stays in the buyer's standup until the runbook is signed off; staff aug logs hours. If the role spec does not include rubric ownership and a runbook deliverable, what you posted is a staff-aug role with FDE in the title.
How long should the FDE engagement run?
Two to six weeks for a vendor-neutral studio engagement focused on a single production agent or ML system. Longer than six weeks usually means the role drifted into platform configuration or multi-team rollout and the rubric is no longer load-bearing. If the role spec calls for twelve months, the work is closer to a Palantir-flavor or model-lab-flavor engagement and the spec should be written that way, with platform deliverables instead of file-list deliverables.
What goes in the SOW exhibit for an FDE role?
Four lines for deliverables (rubric.yaml, eval/cases.yaml, .github/workflows/pilot-gate.yml, runbook.md), three lines for gates (week 1 first PR, week 2 prototype passes rubric, week 6 production handoff), one line for IP ownership (client owns the repo and the eval harness, no vendor-attached runtime), one line for model neutrality, one line for commit access on day 1, one line for the refund-and-exit clause at day 14. That is the eleven-line spec.
Adjacent reading on the FDE role and what it ships
Related guides
What is a forward deployed engineer?
The structural definition: a software engineer who works inside the customer's environment, defined by what they leave in your repo when they go.
AI forward deployed engineer: the four vendor types
Model labs, big-firm consulting, platform vendors, vendor-neutral studios. They look identical on the first call, very different at month 18.
FDE Week 2 prototype rubric
The rubric.yaml, the pilot-gate.yml, and the day-14 decision meeting that decides whether the engagement keeps billing.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.