Two proposals land on the same buyer’s desk in the same week. Vendor A quotes $180K for the platform and a separate $60K statement of work for implementation. Vendor B quotes $240K, and the order form says a dedicated forward-deployed engineering team is included. Assume the work behind both is identical. The same kind of engineer spends the same eight weeks inside the customer’s data warehouse, their SSO, and their network policies.
The buyer still reads those two proposals very differently. Vendor A’s SOW says the product is complicated enough that you have to pay someone to install it. Vendor B’s line says you’re buying a premium product that comes with its own engineers. One reads like a tax, and the other reads like white-glove service. I think that difference in perception explains more of the forward-deployed engineer boom than anything about the job itself.
An old job with a new name
Back in June I wrote about splitting post-sale ownership along the architecture line, and I called the technical half “the FDE-shaped job, whatever your org decides to call it.” I want to come back to the naming part, because the name is doing a lot more work than most people admit.
Embedded technical people who get a product load-bearing inside a customer’s environment are not new. We’ve called them Customer Success Architects, Solutions Architects, TAMs, resident engineers, and on-site consultants. IBM, DEC, and HP had people on customer sites decades before anyone said “forward deployed.”
The title came from Palantir, whose first customer was the CIA and whose second was the Army. The term is lifted straight from military usage. My theory is that it stuck because it sounded right to that buyer. A program office would rather hear that engineers are being deployed forward to the mission than approve a line item for professional services. I can’t prove that was the intent, but it fits the economics. Palantir reportedly charged millions per contract to fund its FDE corps and accepted lower margins to do it. The labor didn’t go anywhere. It moved inside the contract.
So when a company announces an FDE team now, the first thing I want to know is where the cost has gone.
The part worth copying
I’d still stop anyone from writing FDEs off as professional services in a nicer jacket. The best embedded teams treat field deployments as product research. Palantir is the famous example. When something broke inside a customer, the fix became part of the platform. After Foundry launched around 2016, many FDEs moved back into product engineering and brought what they’d learned in the field with them. The embedded team existed to teach the product what it needed to become, and it was supposed to get smaller as the product caught up.
Palantir wasn’t the only one doing this work. At Chef Software we had a Customer Success Engineering team, led by a wonderful human named Irving Popovetsky and staffed with people who loved the product and loved hard customer problems. Everyone called them the Smokejumpers, because that’s what they were. Our CSMs and CSAs owned long-term value realization and handled technical issues as they came up. When a customer hit something nobody else could solve, the Smokejumpers dropped in. Sometimes that meant heavy custom development for a customer running on mainframes that nobody knew how to automate.
One customer was trying to manage configuration across a fleet of bike rental stations. Each station was a small compute environment with a cellular connection back to the company’s servers, and it checked in on a fixed schedule to see if there were any changes. Chef used a pull model, so the basic design suited the problem. The catch was that we had never configured embedded hardware like that. Our whole playbook for when something went wrong assumed we could push into a server sitting on a network, and a bike station on a scheduled cellular link gave us no way in.
We went in, for free, and built a working solution alongside the customer’s engineers. Then we fed what they learned back into the product. The features that came out of it made Chef work better for any system that was embedded or only connected some of the time, like the servers on a cruise ship. One customer’s odd problem turned into a capability we could offer a whole class of customers we hadn’t been able to serve well before.
That return path is what made the team worth the cost. I’ve said for years that manual effort is where value goes to die. Do something by hand once or twice, but by the third time, figure out how to automate it or remove it completely. A good embedded team embodies that principle, but with a headcount budget attached.
Where the cost lands
Go back to the two proposals. Vendor B’s buyer feels better about the total cost of ownership. Vendor B’s CFO should feel worse. The eight weeks of engineering still got paid for. They just moved out of a services line with its own margin and into the cost of revenue on the subscription, where they drag down gross margin on every account that needs them.
That’s a good trade when the work is teaching you something. The Smokejumpers were free to the customer, and that was the right call, because nearly every engagement was discovery work. They weren’t staffed on every deployment. They showed up when something new needed to be done.
It’s a lousy trade when the work is the same implementation you did last quarter and the quarter before that. Bundle repeatable work, and you’re subsidizing a product gap indefinitely, while telling the board the margin hit is temporary.
I’ve made the other call too. Where I’ve run implementation as its own paid offering, the reasoning was that repeatable work should be scoped and priced so everyone can see what it costs, because that visibility creates the pressure to engineer it away. Neither bundling nor charging is right as a blanket policy.
The Bundle Test
Before hiring an FDE team or renaming the one you already have, answer three questions.
The cost line. Where does the cost land: in the price, on a services SOW, or inside the gross margin? If you can’t point to the line, your finance team will find it eventually and ask a less friendly version of the question.
The return path. What flows back? Every recurring fix, script, connector, or config pattern an FDE writes needs a destination: the product backlog, a supported template, or a written decision to keep it bespoke. If field work stays inside one customer’s environment, you’re paying engineering rates for consulting output.
The burn-down. Does it get smaller? The hours it takes to get a new customer load-bearing should fall with each cohort as the product absorbs what the field keeps rebuilding. If that curve stays flat, you’ve built a services business and priced it like software.
One clarification that ties back to the June post. The burn-down applies to getting new accounts load-bearing. A deep account still needs a deployment owner who can change the integration when the customer’s environment shifts, and that ongoing ownership requires its own budget and its own conversation. What should become cheaper with every cohort is the first 120 days.
Two ways to get it wrong
The Title Swap. Sales engineers and implementation consultants get new titles and new comp bands at a median posted salary near ~$190K. The services SOW disappears from the order form, and nothing else changes. The work is the same, the output is just as bespoke, and nothing flows back to the product. Deals look cleaner for a few quarters. Then someone in finance breaks out the cost of revenue by segment and finds enterprise accounts carrying a gross margin nobody agreed to.
The Permanent Pilot. The team is real and good, but every deployment is still custom. Nobody owns turning field patterns into product, so each new customer starts from roughly zero, and FDE hours per new account stay flat year over year. Customers love the experience, and the unit economics never improve. The first time growth slows, the team gets cut as a cost center, and the field knowledge walks out the door with it.
One failure renames the cost without changing it. The other pays the cost and never collects on it. The return path prevents both, and it’s the first thing that gets skipped when the deployment queue is long.
The number that tells you which one you built
Track one thing: deployment burn-down.
For each quarterly cohort of new accounts that needed hands-on deployment, add up the engineering hours it took to get each one load-bearing in production. Same definition as last time: wired into live integrations and daily workflows, the kind of thing that would take the customer’s engineers real work to pull out. A pilot doesn’t count. Divide by the number of accounts in the cohort and plot it over time. Then pair it with one ratio your CFO will care about, deployment cost as a percentage of first-year ACV.
A falling curve means the product is learning. A flat curve means you’re selling services and pricing them as a product. A rising curve means your deals are getting more bespoke faster than the team can productize, and you want to see that before the board does.
So run it on your last four cohorts. If you don’t log deployment hours, that’s your first finding, and it means no one at your company can currently say whether the FDE team is getting cheaper.
Further reading: The Pragmatic Engineer on forward deployed engineers, a history of the FDE role and its lineage, and Sitreps to SteerCos on the Palantir effect.
The Prompt Library
Each prompt runs on the Bundle Test above, including the load-bearing definition. Fill the braces with your data, and where you don’t have a value, write “unknown” so the model lowers its own confidence instead of guessing.
Prompt 1: Bundle Test Audit
ROLE
You are a post-sale finance and operations strategist at a technical B2B
software company. You evaluate whether hands-on deployment work (FDE,
implementation, solutions engineering) is packaged and funded correctly.
Your principle: deployment labor never disappears. It lands in the price,
on a services SOW, or in gross margin, and it should shrink over time as
the product absorbs repeated work.
DEFINITIONS (apply exactly)
- Load-bearing: in production and embedded in the customer's workflows or
integrations such that removing it would take real engineering effort on
their side. A pilot, trial, or single-user login is NOT load-bearing.
- Repeatable work: a task performed on 3+ deployments with substantially
the same steps.
- Discovery work: a task that surfaced a product gap, new integration
pattern, or requirement not previously seen.
- Bespoke work: custom to one customer with no expected reuse.
INPUTS
- How deployment is packaged today: {bundled / paid SOW / mixed / unknown}
- Deployment team size and fully loaded cost: {detail or "unknown"}
- New accounts deployed per quarter: {number or "unknown"}
- Avg deployment hours per account, last 4 cohorts: {data or "unknown"}
- Mix of work (repeatable / discovery / bespoke): {estimate or "unknown"}
- How field learnings reach the product today: {process or "none"}
- Gross margin by segment: {data or "unknown"}
REASON IN THIS ORDER
1. Cost line. Where does deployment cost land today? Estimate its impact
on gross margin for the affected segment. Show the math and state every
assumption.
2. Return path. Is there a working mechanism for field work to become
product? Cite evidence from the inputs, or say there is none.
3. Burn-down. Is hours-per-account falling, flat, or rising across
cohorts? If the data is missing, say so plainly.
4. Packaging fit. Given the work mix, should repeatable work be charged,
productized, or eliminated? Should discovery work stay bundled?
5. Risk + confidence. Give a risk level (High/Medium/Low) that the current
model is quietly compressing margin, and a SEPARATE confidence score
(1-10). State in one line what is capping confidence.
RULES
- Never treat bundled deployment as free. Always locate the cost.
- Treat "unknown" as unknown and let it lower confidence.
- Recommend ONE change, not a list.
OUTPUT
Verdict line, then a compact block: Cost line | Return path | Burn-down
trend | Packaging recommendation | Risk + confidence (with the cap reason)
| The one change | The data point that would most raise confidence.Prompt 2: Field-to-Product Classifier
ROLE
You review a log of deployment tasks and decide where each one belongs:
in the product, on a priced SOW, or nowhere. Your goal is to find the
work the product should absorb so the next deployment is cheaper.
DEFINITIONS
- Repeatable: performed on 3+ deployments with substantially the same
steps. Candidate to productize, template, or charge for.
- Discovery: surfaced a product gap or new pattern. Keep it bundled, and
it MUST produce a backlog item or a written decision.
- Bespoke: one customer, no expected reuse. Question whether it should
have been accepted in scope.
INPUT
Deployment task log: {task, account, hours, description, recurrence
count if known}
PROCEDURE
1. Classify each task. When recurrence is unknown, mark it "needs
verification" rather than guessing.
2. Group repeatable tasks into patterns. For each pattern, total the hours
spent in the period and estimate the hours saved per future deployment
if it were productized.
3. For discovery tasks, check whether a backlog item or written decision
exists. Flag any with neither as a broken return path.
4. For bespoke tasks, note the account and whether a scoping decision
upstream could have prevented it.
RULE
Anything you infer rather than draw from the log, label as an assumption
to confirm.
OUTPUT
A. Top 5 productization candidates ranked by hours saved, each with a
confidence score (1-10) and what is capping it.
B. Discovery work with no return path.
C. Bespoke work as a share of total hours, and what it implies about how
deals are being scoped.
D. One sentence: is this team building product, or re-delivering it?Agent Workflow: Deployment Burn-Down Monitor
ROLE
You are a standing agent that runs monthly against deployment and account
data. You own one job: report whether the cost of getting new accounts
load-bearing is falling, and escalate when it isn't. Operate by exception.
DEFINITIONS
- Load-bearing: in production and embedded in workflows/integrations such
that removal would take real engineering effort. Pilots, trials, and
single-user logins do not count.
- Cohort: accounts that began hands-on deployment in the same quarter.
- Burn-down: average deployment hours to reach load-bearing, per cohort.
INPUTS (each run)
- Deployment hours by account, with start date and load-bearing date
- First-year ACV by account
- Fully loaded hourly cost of the deployment team
- Productization changes shipped since last run
- Last run's output (for the diff)
PROCEDURE
1. Compute burn-down per cohort, plus deployment cost as a % of
first-year ACV.
2. Compare the newest complete cohort to the prior two. Label the trend
falling / flat / rising, with a confidence score (1-10). Small cohorts
lower confidence.
3. For outlier accounts (hours > 1.5x the cohort average), identify the
tasks that drove the overrun and classify them repeatable / discovery /
bespoke.
4. Match shipped productization changes to the tasks they should have
eliminated. Did hours actually drop on those tasks?
OUTPUT
A. Burn-down by cohort and cost-to-ACV ratio.
B. Diff since last run. A human reads this first.
C. Outliers, with the driver behind each.
D. Productization changes that did not reduce hours as expected.
ESCALATION CONTRACT
- Two consecutive flat or rising cohorts: escalate to post-sales and
product leadership.
- Deployment cost exceeds {threshold}% of first-year ACV for a cohort:
escalate to finance.
- Any account in deployment more than {N} days without reaching
load-bearing: escalate to its Account Owner.
GUARDRAILS
- Never count a pilot as load-bearing.
- Never infer hours that aren't logged. Missing data is a finding.
- Prefer "needs verification" over a confident wrong trend. A false
"falling" is the expensive error here.If your company runs FDEs bundled, paid, or somewhere in between, I want to hear how the math is actually working out. Reply or leave a comment.