The document that decides
your year is already signed
Every forward deployed engineer eventually discovers that the hardest constraint on their work was written in a contract they never read, by people who were optimising for a quarter that ends before the deployment does. The commercial layer is not somebody else’s department. It sets your scope, your deadline, your definition of done, and whether the job you have is engineering or unbilled consultancy.
Why an engineer needs this at all
The commercial argument for the role is explicit: a16z’s services-led-growth thesis is that companies deliberately accept lower gross margin on deployment work because the resulting customer outcome is defensible in a way that software alone is not.8 That is a trade, not a gift. It holds while deployment work produces durable product and durable revenue, and it stops holding the moment an FDE org becomes a consultancy that ships nothing reusable.
You are on one side of that trade. Which means the commercial mechanics — how the work was sold, how it is priced, what the contract obliges you to do — are not background. They are the shape of your job.
MSA (master services agreement) — the legal frame: liability, IP, data handling. Signed once, rarely re-read, and it contains the security and data clauses you will have to satisfy. Order form — what was bought, for how much, for how long. SOW (statement of work) — the one that binds your week: deliverables, milestones, acceptance criteria, assumptions. Success plan / mutual action plan — not contractual, often more accurate about what people actually expect. Support agreement — SLAs and response times, covered in incidents and SLAs.
Not after. An engineer’s review of a draft SOW takes twenty minutes and routinely removes a deliverable that would have cost six weeks. The request is also uncontroversial — no account executive wants to sell something undeliverable, they simply do not know which parts are hard. If you are not in the room, the person writing acceptance criteria for your work is someone who has never seen the customer’s data.
Reading a SOW like an engineer
Six clauses account for nearly all the pain. Find them first; the rest can be skimmed.
| Clause | What to look for | What it does to you if wrong |
|---|---|---|
| Deliverables | Nouns you could point at. “A deployed pipeline that routes documents to six queues.” | Verbs and adjectives — “support the customer’s AI transformation” — are infinite scope with a signature on them. |
| Acceptance criteria | A measurable test with a named approver and a review window. | “To the customer’s satisfaction” means one unhappy stakeholder can withhold sign-off indefinitely. |
| Assumptions | Everything you need from them: data access by a date, an environment, a named SME, decisions within N days. | Missing assumptions mean their two-month delay is your two-month overrun. |
| Out of scope | An explicit list. Data migration, historical backfill, training beyond N sessions, integrations not named. | An empty out-of-scope section means everything is arguably in scope. |
| Change control | Who can request a change, who prices it, how long it takes. | No change process means every new request becomes free work delivered under the original deadline. |
| IP and reuse | Whether what you build can be reused for other customers. | Customer-owned bespoke IP is how an FDE org quietly becomes a body shop with no compounding asset. |
“…and any other reasonable requests related to the deployment.” It reads as courtesy and functions as an unbounded obligation. Every FDE meets it once. Strike it, or bound it — “up to 20 hours per month, by agreement” is a sentence people happily accept when you ask before the ink is dry.
customer provides read access to the invoice warehouse by week 1
customer names one SME available 4h/week for weeks 1–8
customer decisions returned within 5 business days
environment (VPC, IdP app registration) available by week 2
# and the clause that makes them mean something
"delays in the above shift milestone dates day-for-day."
← without this line, the assumptions are decoration
Three pricing models, and what each does to your week
Bundled into the licence
- Deployment is “free” — funded by the software revenue.
- Good: no timesheets, no per-hour arguments, you optimise for the outcome.
- Bad: your cost is invisible, so scope creeps without anyone noticing until the margin review.
- Watch: the internal number for how many days were assumed. Find it, because you are being measured against it.
Fixed-fee professional services
- A defined scope for a defined price.
- Good: forces written acceptance criteria — the healthiest thing on this page.
- Bad: every discovery becomes a change order, which is friction with a customer you need on your side.
- Watch: whether change control is real or theatrical. If nobody has ever raised one, it is theatrical.
Time & materials
- Billed by the day or hour against a cap.
- Good: honest about uncertainty, which deployments genuinely have.
- Bad: you now have utilisation targets, and utilisation targets are the mechanism by which engineers become consultants.
- Watch: whether product work is billable. If it is not, nobody will ever do any.
Outcome / success fee
- Payment tied to a measured result.
- Good: perfect alignment, and it forces a baseline to exist.
- Bad: the measurement becomes the negotiation, and you may not control the variables.
- Watch: who computes the number, and whether the baseline was captured before you changed anything.
“How is deployment work paid for here, and what happens to my time if a deployment runs long?” The answer tells you more about the job than the job description did. Bundled means you will be measured on days-per-deployment. T&M means you will be measured on utilisation. Those two organisations feel completely different to work in and both call the role forward deployed engineer.
Working with the account executive
Not an adversary. A partner with a different clock, a different comp plan, and information you do not have.
The AE knows things you need: who holds the budget, when the renewal date is, which stakeholder is quietly against this, what the competitor promised. You know things they need: what is actually possible, what a request really costs, when a demo is going to fall over. The FDEs who do well treat this as an information trade rather than a border dispute.
Learn their incentive structure, without cynicism
Quota, quarter boundaries, what counts as booked. This is not a character flaw — it is the system they work in, exactly as your sprint or your on-call rota is yours. Knowing that a request lands three weeks before quarter end explains most of its urgency and none of its merit.
Separate the customer’s need from the deal’s need
Ask directly: “is this something the users asked for, or something we need for the deal?” Both are legitimate answers and they get engineered differently — one becomes product, the other might be a well-built demo with a documented shelf life. Confusing them is how a demo hack ends up in production.
Say “yes, and here is the cost” instead of “no”
“We can do that; it is about three weeks and it pushes the pipeline milestone into April. Do you want it more than that?” This converts you from an obstacle into someone the AE brings into the room early — which is where you actually want to be.
Never let a technical promise be made without you
The failure mode is a slide with a capability on it that nobody checked. Get a standing rule: nothing technical goes in a proposal without an engineer’s read. Ninety seconds of review, and it prevents the single most demoralising experience in the role — being handed a deadline for a feature you know does not work.
Bring them evidence, not opinions
Adoption numbers, eval results, incident counts. An AE armed with your telemetry defends the renewal without you in the room, and evidence is the only thing that travels well through a commercial conversation.
A meaningful share of FDE postings are pre-sales-shaped rather than build-shaped: demos, proofs of concept, technical qualification.1 Neither is worse. But a pre-sales-weighted role has a different rhythm (many customers, shallow, quarter-driven) from a delivery-weighted one (few customers, deep, milestone-driven), and the interview rarely makes the split explicit. Ask what fraction of the last quarter was spent pre-sale versus post-sale. See FDE vs solutions engineer for the full comparison.
The services trap, and the arithmetic behind it
The failure mode of the whole model. It is visible in numbers long before it is visible in morale.
The trap: deployment work grows, each engagement is bespoke, nothing is reused, and the company gradually becomes a consultancy with a software company’s cost base and a consultancy’s margins — without ever deciding to. a16z’s framing is that the services cost is worth paying for the moat.8 The trap is paying the cost and not getting the moat.
The arithmetic is simple enough to do on a napkin, and worth doing on yours. The numbers below are an illustrative worked example, not market data — put your own in:
loaded cost of one FDE ~$300k/yr (salary + benefits + travel)
deployments per FDE per year 3
→ deployment cost ~$100k each
# the ratio that decides whether the model works
ACV of a deployment $150k → services eat 67% of year-one revenue ✗
ACV of a deployment $600k → services eat 17%, renews at ~95% ✓
# and the multiplier that actually saves you
reuse: work that ships as product → next deployment costs 0.6×, then 0.4×
no reuse → every deployment costs 1.0× forever
Signals the model is working
- Deployment N takes measurably less time than deployment N−1.
- Work done for one customer ships as product for the rest.
- Engineers rotate off deployments and the systems keep running.
- The product roadmap contains items whose origin was a customer engagement.
- You can name what the last deployment contributed to the product.
Signals of the trap
- Every customer has a fork, a branch, or a private repo.
- Nobody can leave an account without the account degrading.
- The word “utilisation” appears in your performance review.
- “We’ll productise it later” has been said for four consecutive quarters.
- Headcount grows linearly with customer count, and nobody finds that alarming.
Write the generalisation memo at the end of every deployment: what we built, what was genuinely customer-specific, what should be product, and what it would cost to make it so. One page. It is the single artefact that converts bespoke work into a compounding asset, it takes an hour, and it is the reason some FDE orgs get faster while others get bigger. It also happens to be excellent evidence at promotion time — see is this role worth it for the honest career picture.
The renewal starts nine months early
Renewal is decided long before the renewal meeting. By the time procurement schedules it, the outcome is largely determined by whether the system is used, whether the champion is still employed, and whether anyone can state the value in a number. The FDE controls two of those three.
Baseline exists and adoption is instrumented
If you cannot say what the world looked like before you arrived, you will be arguing from anecdote at the worst possible moment. This is the whole subject of proving value.
A second champion exists
Single-champion deployments die when that person changes job, and in a large enterprise the odds of that over an eighteen-month engagement are not small. Deliberately build a relationship with someone in a different reporting line.
Their team can run it without you
The handoff milestones from incidents and on-call. A customer whose own people operate the system renews; a customer who feels dependent negotiates.
The business review has happened at least twice
Evidence delivered on a cadence, in their language, to the person who signs. A first business review held during the renewal window reads as a sales meeting, because it is one.
Expansion is discussed, not defence
The healthiest renewal conversation is about the next workflow. If the meeting is about justifying the last one, the work that decided it happened months ago.
Some deployments should not renew. The workflow was wrong, the sponsor left, the value never materialised. An FDE who says that internally — early, with evidence — is far more valuable than one who keeps a doomed account alive for two extra quarters. Roughly 95% of enterprise AI pilots reportedly produced no measurable P&L impact,17 and some of those were kept breathing by exactly this reluctance. Calling it is a senior act, not a failure.
These are all conversations
Scope pushback, bad news, a stakeholder whose incentives oppose yours — the roleplay simulator runs them with a trust meter.
Quick answers
What should an engineer look for in a statement of work?
Six clauses cause nearly all the pain: deliverables stated as nouns you could point at rather than verbs; acceptance criteria that are measurable with a named approver and a review window; an assumptions block listing everything needed from the customer with dates, plus a line saying delays shift milestones day-for-day; an explicit out-of-scope list; a real change-control process; and IP terms that let you reuse what you build. Review the SOW before it is signed, not after.
What is the services trap in AI and enterprise software?
It is when deployment work grows, every engagement is bespoke, nothing is reused, and the company becomes a consultancy with a software cost base and consultancy margins without ever deciding to. The services-led-growth argument is that services cost is worth paying for the moat it creates; the trap is paying the cost and not getting the moat. The diagnostic is whether deployment N takes less time than deployment N-1.
How should a forward deployed engineer work with an account executive?
Treat it as an information trade rather than a border dispute. They know the budget holder, the renewal date and the competitive picture; you know what is actually possible and what a request costs. Ask directly whether a request comes from users or from the deal — both are legitimate and get engineered differently. Answer "yes, and here is the cost" rather than "no", and establish that nothing technical goes into a proposal without an engineer reading it.
How is forward deployed engineering work priced?
Four common models: bundled into the software licence (no timesheets, but your cost is invisible and scope creeps); fixed-fee professional services (forces written acceptance criteria, but every discovery becomes a change order); time and materials against a cap (honest about uncertainty, but introduces utilisation targets); and outcome-based fees (perfectly aligned, but the measurement becomes the negotiation). Ask which model your employer uses — it determines how your time is measured.
When does work on a renewal actually start?
Roughly nine months before it. By the time procurement schedules the meeting, the outcome is largely set by whether the system is used, whether the champion is still there, and whether anyone can state the value as a number. Milestones: baseline and adoption instrumented at M-9, a second champion in a different reporting line by M-6, the customer team able to operate the system by M-4, and at least two business reviews delivered by M-3.
Sources
Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.
Cited on this page
- Bloomberry — “I analyzed 1,000 forward deployed engineer jobs” — posting growth, builder/pre-sales/internal split. bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/
- a16z — Services-Led Growth — the margin-for-moat thesis behind FDE hiring. a16z.com/services-led-growth/
- Nabeel S. Qureshi — “Reflections on Palantir” — first-hand account of forward-deployed work, including the Airbus engagement. nabeelqu.co/reflections-on-palantir
- MIT NANDA “State of AI in Business” — 95% of pilots with no measurable P&L impact — widely reported; figure cited via press coverage rather than a public PDF. techcrunch.com/2026/07/30/forward-deployed-engineers-are-the-ai-industrys-latest-talent-obsession/
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.
More Handbooks
- The Prompting HandbookA friendly, hands-on field guide for everyday humans — learn the CRISP framework, spot bad prompts, practice with real recipes, play a drag-and-drop game, and test yourself with a quiz. No code required.Read →
- The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
- The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
- 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
- 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
- 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
Explore more from Vibe Engines
Get the next one in your inbox.
New handbooks, system-design walkthroughs, and tools — straight to your inbox. No spam, unsubscribe anytime.