Blog
/
FDE ops

How to run an FDE team without putting a ticket tracker between your engineers and your customers

18 min read
Table of contents
Section oneSection two

Thousands of companies are standing up forward deployed engineering teams right now, and almost none of them inherit a playbook for running one. The hiring wave is documented: Indeed postings for the role grew 5,230 percent above their January 2025 baseline by April 2026, and Bloomberry counted 1,165 percent year-over-year growth. The management wave is not documented anywhere, because the discipline of running this kind of team, FDE ops, is roughly eighteen months old outside the handful of companies that invented the role.

This guide is the operating manual we wished existed: how to structure the team, where to put it on the org chart, what rituals keep it healthy, which metrics mean anything, and the operational backbone underneath all of it. It is written for the person who owns the function, whether your card says VP of Engineering, Head of Solutions, or CRO, and it assumes the thing you care about is the thing the role exists for: deals unblocked and customers live, without your engineers drowning in the operational debt their own success creates.

Start from what the role actually is

The best description of the original model comes from someone who lived it. Nabeel Qureshi, an eight-year Palantir veteran, describes in Reflections on Palantir how the company split engineering into forward deployed engineers embedded with customers and a core product team behind them, with FDEs typically onsite at customer offices three to four days a week. The design bet was that engineers who live inside a customer's business processes acquire knowledge nobody else has, and that knowledge flows back into software that actually solves the problem.

Two properties of that model matter for everyone copying it now. First, FDEs are engineers, not support: they ship production code, and the customer's environment is their codebase. Second, the model only compounds if what the field learns flows backward into the product and forward into the next deployment. A team of brilliant individuals whose work evaporates after each deal is not an FDE team; it is a very expensive fire brigade.

Which is why running the team well is mostly about managing artifacts, not activity. Your engineers will generate customer-specific code at a pace that surprises you. The whole management game is making that output visible, safe, and reusable while never slowing the engineers down, and it is the reason this guide keeps returning to operations rather than process.

Where the team reports

There is no settled answer, but there are honest tradeoffs. Teams that report into sales move at deal speed and never lack executive air cover, at the cost of engineering standards drifting and career paths dead-ending. Teams that report into engineering keep code quality and leveling, at the cost of sprint-cadence gravity: the FDE who needs to ship a customer fix today gets asked to wait for the release train, and the role's entire reason for existing erodes.

The pattern that works at companies doing this well is a hybrid: the team lives in engineering for standards, hiring, and career ladders, with a hard commercial contract, meaning named accounts, deal-stage commitments, and a dotted line to the revenue leader who depends on them. What makes the hybrid stable is separating the codebases: FDE work ships through its own lane rather than the product pipeline, so engineering leadership governs how work is built without governing when a customer gets their fix. If every customer commitment has to transit the product backlog, you have rebuilt the bottleneck the role was hired to remove.

Structure: embedded, pooled, or pods

At one to three FDEs, structure is a spreadsheet: names next to accounts. The real choice arrives around five, and it is between three shapes.

Embedded assigns each FDE to a small set of named accounts for months at a time, the original Palantir shape. It maximizes context and customer trust, and it is the right default for six-figure accounts with deep integration surface. Its failure mode is key-person concentration: each account's entire technical memory lives in one head, which is survivable only if the team's artifacts are organizationally owned rather than personally held.

Pooled runs FDEs against a shared queue of integration work across accounts. It load-balances beautifully and keeps nobody blocked on vacation schedules, at the cost of the deep context that makes forward deployed work valuable. Pooling suits high-volume, lower-touch customer work, and it quietly turns your FDEs into an internal agency, which is fine if that is what you meant to build.

Pods pair the two: a small group, often two FDEs plus a solutions lead, owns a book of accounts together. Salesforce's program runs a version of this, with pods embedding with a single enterprise customer for engagements of roughly three months. Pods buy shared context with built-in redundancy, and for teams past eight to ten FDEs they are usually where you end up.

Whichever shape you pick, write down the one rule that survives all of them: every account's builds, credentials, and versions belong to the team, not the individual. Structure decides who does the work; custody decides whether the work outlives the assignment.

A note on presence, since it shapes hiring and burnout alike: the original model was physically embedded, with Palantir FDEs onsite three to four days a week, and some enterprise programs still run field-heavy. Most new teams land on a lighter default, remote-first with deliberate onsite moments: kickoff, the first production launch, and quarterly reviews. Decide your posture explicitly and put it in the job post, because "occasional travel" discovered to mean weekly flights is the fastest way to lose the senior FDE you just spent a quarter recruiting.

The ops backbone: five verbs, decided once

RAND's study of AI project failure, built on interviews with 65 experienced practitioners, found the root causes are overwhelmingly organizational rather than technical, and its list of five causes includes one that should stop every FDE leader cold: underinvestment in infrastructure, including the machinery to deploy completed models. That is this section. Most FDE teams fail operationally before they fail commercially, and the failure is always the same shape: customer-specific code accumulating on laptops, credentials in personal password managers, and an estate nobody can enumerate.

The backbone is five verbs, and the leader's job is making each one a decision rather than a per-engineer improvisation:

  1. Deploy. One sanctioned path from working code to running code, measured in minutes. If the sanctioned path is slower than the customer's patience, engineers will route around it, and you will learn about your real deploy path during an incident.

  2. Host. Customer builds run somewhere owned and monitored, never on the laptop that built them, never on a VM whose existence depends on one person's memory.

  3. Vault. Customer credentials go into custody where engineers reference but cannot read them. This single decision converts your security review from a per-engineer trust exercise into an architecture answer.

  4. Version. Every customer build retains its history, so "what changed" has an answer at 6pm on a Friday.

  5. Hand off. Transferring an account's work is an operation with a runbook, not a two-week pairing marathon that never happens before the departure date.

We maintain a full evaluation of the platforms that can carry this backbone in the FDE ops platform guide. The short version: Archway is the purpose-built option, where bridges deploy in minutes with no core-product change, credentials sit in an AES-256 vault with zero-access custody, every version is owned by the org, and moving an account is a reassignment of org-owned bridges, not a rebuild. Two bridges are free, which for a team lead means the backbone can be piloted on one real account this week without a procurement cycle. Speed for the people who ship; custody and control for you. The integration-shaped view of the same backbone decision is in the platforms comparison for customer integrations.

The ratio question, answered honestly

The first spreadsheet question every leader asks is "how many accounts per FDE?" and the honest answer is that no trustworthy published benchmark exists yet; the discipline is too young, and the ratio is really a function of four variables you can measure in your own shop. Integration depth: an account with one thin bridge and an account with fourteen deep ones are different jobs wearing the same logo. Deal-stage mix: pre-sales POC work burns attention in bursts, while live-account maintenance burns it steadily. Platform leverage: a team whose builds deploy in minutes and share reusable patterns covers multiples of what a laptop-era team covers, which is why the backbone decision above is secretly a capacity decision. And customer temperament: one regulated enterprise with a change-advisory board can consume a whole engineer's calendar.

The practical move is to instrument rather than adopt: track live builds per account, hours per account per month, and time-to-first-value per new account for one quarter, and your own ratio falls out with confidence no blog post can offer. Then watch two leading indicators for the moment it breaks: time-to-first-value trending up across two consecutive new accounts, and estate-review items going unresolved for more than two weeks. Both appear well before anyone says the word "capacity," and both are cheaper to answer with a hire than with a churned customer.

Rules of engagement with sales

The relationship with sales makes or breaks the function, and it runs best on three written rules rather than goodwill.

A qualification gate before FDE time. FDE attention is the scarcest resource in the building, so define when a deal earns it: deal size, technical complexity, and a named champion are the usual bar. Every hour spent on an unqualified deal is an hour taken from a customer who already pays you, and without a gate, the loudest AE owns your roster.

Scoped commitments, written down. What the FDE will build for the POC, what "done" looks like, and what becomes a paid engagement if the deal closes. The one-sentence scope kills the two silent killers: the demo that grows into an unpaid implementation, and the promise made verbally in a room the FDE never entered.

POC work ships on the same backbone as production work. The temptation is to treat pre-sales builds as throwaway, and it is exactly backwards: a POC that closes becomes production on its first morning, and a POC built on a laptop becomes production debt on the same morning. Building POCs on the platform means the win converts in minutes instead of being rebuilt, which changes the economics of every technical evaluation you run.

Handled this way, sales stops experiencing the FDE team as a bottleneck to lobby and starts experiencing it as deal infrastructure with an interface. That is also the framing that survives budget season.

Rituals that keep the team healthy

Process should be light, but four rituals earn their calendar slots.

The weekly estate review, thirty minutes. The team walks the list of what is live at which customer: new builds, broken builds, drift, upcoming changes. This is the single highest-leverage meeting an FDE team runs, because it converts private knowledge into shared knowledge on a cadence. If assembling the list takes longer than the meeting, that is your backbone telling you it is missing.

The deal debrief, after every launch. What did the customer need, what did we build, what should the product absorb, what should become a reusable pattern? This is the Palantir feedback loop in miniature: the field teaching the roadmap. Skip it and your FDEs solve the same problem forty times; run it and the fortieth deal closes in a week.

The handoff drill, quarterly. Pick one account, simulate the departure of its owner, and time how long a colleague takes to assume it: find every build, access every credential path, redeploy one change. Teams that drill this discover their gaps in an afternoon; teams that do not discover them during a resignation. The full procedure lives in our handoff playbook.

Product office hours, biweekly. A standing slot where FDEs bring field patterns to product and platform engineering. This is where the routing rule gets applied: work a second customer will use exactly as built goes to the roadmap; work that stays one-customer stays in the FDE lane. The discipline of sorting at intake keeps bespoke requests from stalling the roadmap and productizable requests from being rebuilt as snowflakes.

Metrics that mean something

The trap in measuring FDE teams is importing metrics from adjacent functions: ticket velocity from support, story points from product engineering, utilization from consulting. All three reward the wrong behavior. The role exists to unblock revenue and keep customers live, so measure the path to those outcomes:

  • Time to first value per customer: contract signature to first working integration in production. This is the number the role was hired to compress; watch its trend, not its absolute.

  • Deals unblocked: opportunities where FDE work removed the technical objection, counted with your sales leadership so the attribution survives scrutiny.

  • Builds per account and per FDE: not as a quota but as a capacity model; it tells you when to hire long before anyone complains.

  • Custody coverage: the percentage of live customer builds on the sanctioned backbone, with vaulted credentials and retained versions. This is your operational-risk dial, and it should read from your platform, not a spreadsheet.

  • Handoff time: measured by the quarterly drill. If it exceeds a day, the account is a liability wearing a success story.

Two numbers to watch as context rather than targets: the share of engineer time spent customer-facing, which the hiring market now writes into 70 percent of FDE posts as a hard requirement, and the roadmap tax, hours of core product engineering pulled into customer-specific work, which the FDE lane exists to drive toward zero.

Hiring and leveling

The job-post data gives you the hiring spec: Perspective AI's analysis of 1,000 FDE postings found core engineering in 95 percent or more of posts, LLM application skills in 80 percent or more, and customer-facing discovery skills in 70 percent or more and climbing. Hire for the trio, and weight the third more than your engineering instincts want to: you can teach retrieval patterns faster than you can teach a person to enjoy ambiguous rooms.

Budget honestly for the market. Indeed pegs broad-market pay at $170,000 to over $200,000, and AI-lab total compensation runs $350,000 to $550,000 for mid-to-senior roles. If you cannot match lab compensation, compete on the two things startups actually have: scope and equity. Our living list of companies hiring FDEs doubles as a market map of who you are competing with for candidates.

Level on trust radius, not code volume: a junior FDE ships builds inside an account someone else owns; a senior FDE owns accounts; a staff FDE owns the patterns, the drills, and the parts of this guide your company adopts.

The three failure modes to watch for

Shadow ops. The sanctioned path got slow, the laptop got fast, and the estate forked. You detect it in the estate review when a customer mentions an integration nobody in the room recognizes. The fix is never policy; it is making the sanctioned path the fastest path, which is an infrastructure decision.

Hero economics. One engineer holds five critical accounts in their head, everyone knows it, and the org treats it as a staffing win instead of an outage in progress. The knowledge-capture disciplines in our tribal knowledge guide exist for exactly this, and the quarterly drill is your early-warning system.

The agency drift. The team gets so good at bespoke delivery that nothing flows back: no patterns, no product signal, no compounding. Symptoms: the fortieth integration takes as long as the fourth. The deal debrief and product office hours are the antidotes, and custody coverage is what makes reuse physically possible, because you cannot reuse what you cannot find.

The budget conversation

Once a quarter, someone in finance asks what the FDE team costs and why, and leaders who answer in engineering vocabulary lose ground they do not recover until renewal season. The defensible framing is the one this whole guide points at: the team is deal infrastructure, and its budget line buys three things finance already values. Revenue mechanics: deals unblocked and time-to-first-value compressed, reported from your metrics with sales countersigning the attribution. Risk retirement: custody coverage as a percentage, which converts "we have engineers" into "we can show any customer's auditor where their credentials live," a sentence procurement teams repeat internally. And roadmap protection: hours of core product engineering not consumed by customer-of-the-week work, which is the quiet number CTOs care about most.

Tooling belongs in the same frame. A platform line item priced per bridge is small against any of the three numbers above, and the argument writes itself from the incident you did not have: one departure handled as an afternoon instead of a quarter pays for years of it. Leaders who bring this framing to budget season report the rarest outcome in infrastructure funding: finance asking whether the team needs more.

The first ninety days, compressed

Days 1 to 30: inventory reality. List every live customer build, where it runs, who holds its credentials. Expect this to be harder than it sounds; that difficulty is your baseline. Days 31 to 60: stand up the backbone. Pick the platform, move two real accounts onto it end to end, and time the difference. Days 61 to 90: institutionalize. Start the estate review and deal debrief, run your first handoff drill, publish the routing rule, and set the metric baselines.

Ninety days in, you should be able to answer, from a screen rather than a memory: what runs where, who can touch what, and what happens if anyone resigns tomorrow. Put those three answers in your first quarterly review; they are the whole function, stated as facts. That is what running an FDE team means. The engineers were always going to be excellent; the team is what survives them. If you want the backbone half solved before the quarter starts, see what Archway does; the first two bridges are free. Engineers on the team can start from the FDE page.

Sources and notes

A long list of live bridges: approval rules, usage reports, data migrations, SLA alerts, reconciliation, provisioning and compliance exports

Deliver hyper-personalized software at scale

Start free

Product

ProductSecurityPricing

Legal

Terms of UsePrivacy PolicyPurchase Terms

© 2026 Archway. All rights reserved.