Blog
/
FDE ops

How to staff an FDE team

26 min read
Table of contents
Section oneSection two

The hiring wave is documented. The staffing math is not. Indeed postings for forward deployed engineers sat 5,230 percent above their January 2025 baseline by April 2026, and Bloomberry counted 1,165 percent year-over-year growth across a thousand job posts. Leaders who own the function now face a quieter question those headlines do not answer: how many of these people do you actually need, against which accounts, next to which sales engineers, and with enough slack that a vacation or a resignation does not become a customer incident.

This guide is the headcount manual. It is for the person who has to defend a hiring plan in a budget meeting, not the person writing the job post. How to run an FDE team covers reporting lines, rituals, metrics, and the first ninety days. This one stays on staffing: the ratio, the sixth hire, the SE mix, pods versus pooled as a hiring shape, and coverage for the weeks when someone is not there. If you are still defining the role, start with what a forward deployed engineer is and come back with the job in hand.

The work sets the headcount, not a published ratio

Every leader asks the same first question: how many accounts per FDE? The honest answer, which this guide will not dress up, is that no trustworthy public benchmark exists. The discipline is too young, the work varies too much by product, and the companies that have run this longest do not publish a ratio. Palantir, which coined the role, describes a model in which a Delta is part of a team that directly supports one customer, with the mandate "one customer, many capabilities." Salesforce's program, as Exponent tracks it, embeds pods with a single enterprise customer for engagements of roughly three months. Those are engagement models at companies whose deals can absorb a team per logo. They are not a staffing ratio for a growth-stage product company whose FDEs cover a book of accounts.

Treat any blog, recruiter, or vendor who quotes "the industry standard is X accounts per FDE" as selling a number they cannot source. We looked. It is not in the job-post analyses, not in Palantir's engineering blogs, not in the BLS occupational data, and not in the FDE compensation writeups. The ratio is a function of four variables you can measure in your own shop, and the only defensible headcount plan is the one that falls out of those measurements.

The four variables:

  1. Integration depth. An account with one thin connection and an account with a dozen deep ones are different jobs wearing the same logo. Count live builds, not logos.
  2. Deal-stage mix. Pre-sales proof-of-concept work burns attention in bursts. Live-account maintenance burns it steadily. A roster that is 70 percent POC and a roster that is 70 percent production will not carry the same account count, even if the product is identical.
  3. Platform leverage. A team whose customer builds deploy in minutes, with credentials vaulted and versions retained, covers more than a team whose work lives on laptops. The ops backbone is secretly a capacity decision. The short version of that backbone lives in the FDE ops platform guide; the operating version is in how to run the team.
  4. Customer temperament. One regulated enterprise with a change-advisory board can consume a whole engineer's calendar. A self-serve-adjacent customer who wants a webhook and a Slack alert cannot.

Until you have those four in numbers, any headcount request is a guess wearing a spreadsheet.

Accounts per FDE: a model you can run, not a number you can copy

Because there is no public benchmark, the useful artifact is a capacity model with labeled assumptions, not a claimed industry average. Run it on your last quarter of actual work. If you do not have a last quarter, run it on the last six closed accounts and be honest that the sample is small.

Start with hours, not accounts. For each live customer, estimate monthly maintenance hours: the time spent on break-fix, small changes, security questionnaires, and relationship maintenance. For each new account, estimate hours to first production value: discovery, build, deploy, and the first two weeks of babysitting. Then apply a utilization cap, because an FDE who is 100 percent billed against accounts has no time for the work that makes the function compound: pattern extraction, product feedback, and covering a colleague.

A worked example, labeled as an illustration, not a benchmark. Suppose a mid-complexity product, a team whose builds already ship through a real deploy path, and a mix that is half live accounts and half new work. If live accounts average eight hours of maintenance a month, a new account takes forty hours to first value, and you cap each FDE at twenty-four customer-facing hours a week so the rest goes to patterns and coverage, then one FDE has roughly one hundred customer-facing hours a month. That budget can hold, in this illustration, something on the order of eight live accounts in a quiet month, or four live accounts plus one new account in a month that includes a first-value push. Change any input and the output moves. Double the integration depth and the live-account count halves. Put the same people on laptop deploys and the new-account hours climb, which is how teams that look staffed on paper still miss first-value dates.

Three rules for using a model like this without lying to yourself.

Count builds, then convert to accounts. Two customers with one build each and one customer with fourteen builds are not three units of work. If you only track logos, you will hire late for the heavy accounts and early for the light ones.

Separate pre-sales hours from production hours. POC work that never graduates is a sales cost, not an FDE capacity plan. If a large share of FDE time is being spent on unqualified evaluations, the fix is a qualification gate, which the operating guide covers, not another hire. Adding headcount to absorb unqualified deal flow is how FDE teams become unpaid professional services.

Re-run the model when the product changes. A new connector, a new regulated vertical, or a new POC motion changes the inputs. A ratio you set in Q1 is a hypothesis, not a policy.

The leading indicators that the current ratio has broken, which appear before anyone uses the word capacity: time-to-first-value trending up across two consecutive new accounts, estate-review items sitting unresolved for more than two weeks, and FDEs declining PTO because they cannot name a coverage person. Hire against those signals. Do not wait for a churned customer to make the case.

When to hire the sixth

The first five hires are usually argued from pipeline: we have more accounts than names. The sixth is usually argued from coverage, and leaders who miss that distinction staff a team that looks busy and is one absence from an outage.

At one or two FDEs, staffing is a founder problem wearing an engineering title. At three to five, you can still run names-next-to-accounts in a spreadsheet, and every absence is covered by goodwill and late nights. Five is the last headcount at which informal coverage still pretends to work. It is also the size the operating guide flags as the moment structure becomes a real choice. This section is not that choice restated. It is the hiring trigger.

Why five is the trap, in arithmetic rather than culture. On a five-person team, one person out is a 20 percent capacity cut. Two people out, which is a planned vacation overlapping a sick week, or a resignation overlapping anyone else's PTO, is 40 percent. The BLS National Compensation Survey finds that 80 percent of private-industry workers have access to paid vacation, and the BLS paid-vacation factsheet shows that after one year of service, 31 percent of private-industry workers receive 10 to 14 days. After ten years, 31 percent receive 15 to 19 days, and 20 percent receive more than 24. FDEs at the senior end of Indeed's $170,000 to over $200,000 band are not the one-year cohort. They take the leave they have earned, or they leave the company. A staffing plan that only works when nobody is out is not a staffing plan.

The sixth hire is the first one that makes a coverage pair possible without emptying an account. With six people you can run three pairs, or two pods of three, so that every account has a named primary and a named backup who has already touched the work. That is a staffing geometry, not an operating ritual. The rituals that keep the geometry honest (the estate review, the quarterly handoff drill) live in how to run the team. The hire is what makes those rituals more than theater.

Hire the sixth when any two of these are true:

  • At least one FDE is the sole person who can deploy a change at two or more revenue-material accounts.
  • Planned PTO in the next quarter cannot be covered without moving an account to someone who has never shipped on it.
  • Time-to-first-value has risen on two new accounts in a row, and the cause is attention, not product.
  • A resignation in the current roster would force a cold-start handoff on a live customer. The procedure for that day is in the departure playbook; the staffing job is to make that playbook a drill rather than an incident.

Do not hire the sixth to "get ahead of pipeline" if the first five are still absorbing unqualified POCs. That hire will be eaten by the same overflow. Fix the gate, then hire.

Sales engineers vs FDEs: a mix, not a rebrand

A large share of the hiring wave is a labeling problem. Bloomberry's analysis of 1,000 FDE posts found that companies use the title for three different jobs: a builder FDE who writes production code inside customer environments (about 60 percent of posts), a sales-engineer-plus role rebadged as FDE (about 30 percent), and an internal-tools role that should not use the title at all (about 10 percent). In the builder posts, zero percent mentioned a quota, 8 percent mentioned on-target earnings, and 70 percent mentioned equity. That is engineering compensation, not sales compensation.

Palantir has been explicit about the distinction for years. In Dev versus Delta, a Palantir hiring manager records the internal split: Devs build one capability for many customers, Deltas enable many capabilities for one customer, and a common misconception is that a Delta is a consultant. The Deltas in that post insist they are deploying a software product and doing significantly more engineering than consulting work. A Palantir day-in-the-life describes the same job as embedding with a customer to configure and extend the platform, not to run a demo motion.

Sales engineering is a real, older occupation with its own labor market. The BLS occupational outlook for sales engineers counted 56,800 jobs in 2024, a median wage of $121,520, and 5 percent projected growth from 2024 to 2034. Forward deployed engineering is not a BLS occupation yet. You are not hiring from a surplus pool of FDEs. You are hiring engineers into a customer-facing seat, in a market where software developer employment is itself projected to grow 15 percent from 2024 to 2034, much faster than the average for all occupations. Confusing the two seats wastes both.

The mix that holds:

Sales engineers own the technical win. They scope, demo, and run the evaluation. Their scarce resource is cycle time across opportunities. Their success metric is qualified deals unblocked, not production uptime. If you have SEs, send them to the sales engineer page for the motion; do not rewrite their job as FDE work.

FDEs own production in a named environment. They write the customer-specific code that keeps running after the signature. Their scarce resource is depth in a small set of accounts. Their success metric is time to first value and whether the estate survives them. The career-shaped comparison is in FDE vs software engineer.

The handoff between them is a written gate, not a vibe. A deal earns FDE time when it has size, complexity, and a named champion. Everything before that gate is SE work, including POCs that are still really demos. Everything after it is FDE work, including POCs that are the first version of production. Mixing the two without a gate produces the most expensive failure in this function: the FDE who is always in a sales cycle and never in a customer's production systems.

A practical starting mix for a company that already has a sales-engineering function: keep the SE team sized to the opportunity pipeline, and size the FDE team to live accounts plus the qualified POC load that will become live. Do not convert SEs into FDEs by changing the title. Bloomberry is blunt that if the job has a quota, it is sales engineering, and if the person hands off after the sale, it is not forward deployed work. Hire builders for the builder seat. The living list of companies hiring FDEs is the market map of who you are competing with for those builders.

If you do not yet have SEs, do not make the first FDE absorb the entire pre-sales queue. That is how a single hire becomes a bottleneck on both pipeline and production, and how you end up hiring the second FDE to cover the first one's demo calendar.

Pods vs pooled is a staffing choice

How to run an FDE team already describes embedded, pooled, and pod structures as ways to operate. The staffing question is different: which shape are you hiring into, because the job post, the interview, and the seniority mix all change with the answer.

Hiring into embedded means you recruit people who will sit on a small set of named accounts for months. Palantir's original shape, onsite three to four days a week in Nabeel Qureshi's account, and still the right default for six-figure accounts with deep integration surface. Staffing implication: you hire for depth and temperament, you accept slower ramp, and you must budget coverage separately, because the person who holds the account is the person who holds the account. Embedded without a coverage hire is key-person concentration with a headcount number attached.

Hiring into pooled means you recruit people who will pick up integration work across accounts from a shared queue. Staffing implication: you hire generalists, you can load-balance PTO, and you will slowly lose the context that makes forward deployed work valuable unless the artifacts are organizationally owned. Pooled staffing suits high-volume, lower-touch work. It is also how an FDE team quietly becomes an internal agency. If that is what you mean to build, say so in the job post. If it is not, do not staff as if it were.

Hiring into pods means you recruit in complementary pairs or trios: two FDEs, sometimes plus a solutions lead, who own a book of accounts together. Salesforce's program is the public version of this, pods embedding with one enterprise customer for about three months. Staffing implication: you do not hire "an FDE." You hire the next chair in a pod, which changes the bar. The second person in a pod can be earlier in their career if the first is senior. The first person in a new pod should not be. Pods are the geometry that makes the sixth hire pay off, because a pod of three with a backup in another pod is the first structure in which a departure is a reassignment rather than a reconstruction.

Whichever shape you staff for, write the custody rule into the hiring plan: every account's builds, credentials, and versions belong to the team. Structure decides who does the work. Custody decides whether the work outlives the assignment. That is FDE ops stated as a staffing constraint, and it is why software to manage FDE teams is a headcount conversation, not a tooling afterthought.

A note on presence, because it changes who you can hire. Palantir's public writing still describes field time as part of the job: a couple of days a week at the customer premises in one Delta's account, and onsite three to four days a week in Qureshi's. Bloomberry found travel required in 68 percent of FDE roles. Most new product companies land lighter: remote-first, with onsite for kickoff, first production launch, and quarterly reviews. Put the actual posture in the job post. "Occasional travel" that means weekly flights is how you lose the senior FDE you spent a quarter recruiting, and a failed senior hire is a two-quarter hole in a six-person plan.

Coverage for PTO and departure

Coverage is not a culture speech. It is a staffing line. If the plan only works when the full roster is present, the plan is short by at least one person, and probably by a platform.

PTO coverage. Name a backup per account before the out-of-office goes on the calendar, not after. The backup should have shipped one change on that account in the previous quarter. If they have not, the PTO is uninsured. On a five-person team this standard is harsh, which is the point of the sixth hire. On a pooled team the backup is whoever is free, which only works if the artifacts are findable. On a pod, the backup is the other chair, which is why pods are a coverage design as much as a customer design.

Departure coverage. An FDE leaving is not a normal engineering departure. The work is production, the credentials are the customer's, and the replacement market is the one in which Indeed postings grew more than fifty times a January 2025 baseline. Backfilling the seat can take months. The estate cannot. The 30-day procedure lives in the handoff playbook. The staffing implication is earlier: every account should already have organizational custody of builds, credentials, and versions, so that a resignation is a reassignment plus a note, not archaeology. Handoff on Archway is exactly that operation, same-org reassignment, a note, and retained versions. Teams that do not have some version of this will spend their next departure reconstructing tribal knowledge from a laptop.

The coverage ratio, stated without fake precision. You need enough people that one planned absence and one unplanned absence can overlap without an account going dark. For a team whose accounts are embedded and deep, that is hard to do under six. For a team whose accounts are thin and pooled, it is possible earlier, at the cost of context. Do not copy a number. Copy the test: pick next quarter's PTO calendar, mark the resignations you would survive, and see which accounts fail the test. Those accounts are unstaffed, even if they currently have a name next to them.

Who to hire, and at which level

The job-post data is the hiring spec. Perspective AI's analysis of 1,000 FDE posts found core engineering in 95 percent or more, LLM application skills in 80 percent or more, and customer-facing discovery in 70 percent or more. Bloomberry's split of posts that specify experience is mid-weighted: 12 percent entry (0-2 years), 60 percent mid (3-5), 20 percent senior (6-8), 8 percent staff-plus. That is a recruiting constraint. It is not a prescription that your six-person team must be 60 percent mid-level. It tells you that the market is not producing a junior bench, so a plan that depends on three new-grad FDEs is a plan that will miss its start dates.

Level on trust radius, not code volume. A junior FDE ships inside an account someone else owns. A mid-level FDE owns accounts. A senior FDE owns accounts plus a pod. A staff FDE owns the patterns, the drills, and the parts of the operating guide your company actually adopts. On a six-person team, a defensible mix is one staff or lead, two seniors, and three mids, with juniors only if a senior has explicit capacity to apprentice them. Invert that mix and you will spend the year managing heroes.

Budget for the market you are actually in. Broad-market pay sits at Indeed's $170,000 to over $200,000. Bloomberry's median disclosed base is $173,816. At the AI labs, total compensation runs $350,000 to $550,000 for mid-to-senior roles. The BLS median for software developers, quality assurance analysts, and testers was $131,450 in 2024. FDE pay is a premium on that baseline, which is the market pricing the customer-facing half of the job. If you cannot match lab compensation, compete on scope and equity, and be honest in the offer about travel. The companies hiring now are your competitors for candidates, not just a list for applicants. For people converting into the seat, how to become a forward deployed engineer is the conversion manual; do not rebuild it inside the staffing plan.

Where the team reports is an operating question, covered in how to run an FDE team. The staffing implication is narrower. Bloomberry found 45 percent of posts describing FDE as its own dedicated team, 38 percent inside engineering, 14 percent in GTM or sales, and smaller shares in customer success or solutions. Candidates can read those reporting lines. A role posted under sales with a quota, even a soft one, will attract SEs and repel builders. Post the seat you intend to fill.

Platform leverage is a headcount decision

Leaders treat tooling as a line under headcount. For this function the order is backwards. The same four-variable model that sets accounts per FDE has platform leverage as an input. A team that deploys in minutes, cannot lose a credential into a personal password manager, and can reassign an account in an afternoon covers more work per person than a team that cannot. That is not a vendor slogan. It is why RAND listed underinvestment in deployment infrastructure among the root causes of AI project failure, from interviews with 65 experienced practitioners. The failure mode is operational: completed work that cannot be deployed, maintained, or handed off. An FDE team with no ops layer will look understaffed forever, because every new account adds hidden hours of archaeology.

Archway is the purpose-built version of that layer. A bridge is a serverless function that connects your product to one customer's systems, written in JavaScript, deployed in minutes with no core-product change. Credentials sit in an AES-256 vault with zero-access custody. Versions stay with the organization. Handoff is a same-org reassignment, a note, and the versions. Two bridges are free, then $45 per bridge per month. AI-powered coding help lives in the editor; it is a feature, not the product. There is no deal tracker and no separate continuity module. The product is deploy, host, vault, version, and hand off.

Put two real accounts on the free tier before you argue about the seventh hire. If minutes-to-deploy does not change what an FDE can cover, you have a product or process problem, not a platform one. If it does, you just bought capacity without adding a fully loaded FDE salary. That is the staffing conversation finance actually understands. The business case page is the champion kit for that meeting.

A first-year headcount plan, compressed

Seats 1 and 2. Hire a senior builder who has shipped in someone else's environment, and a second person who can be the backup on day one, even if they are mid-level. A single FDE is not a team. It is a key-person risk with a customer list. Skip the junior hire until there is a senior with time to apprentice. Put both people on a real deploy path in month one, not in month six.

Seats 3 to 5. Hire to the capacity model, not to the pipeline story. Add people when time-to-first-value is rising or when live-account hours exceed the utilization cap, not when sales wants a dedicated engineer for a logo that has not signed. Keep SEs in the SE lane. Write the qualification gate down. Start naming backups per account even though you do not yet have enough people for the standard to be comfortable.

Seat 6. Hire for coverage. This is the person who makes pods or pairs possible, who makes PTO real, and who makes a resignation a reassignment. Do not fill this seat with another hero. Fill it with someone who can pick up an estate they did not build, which is a different interview from "tell me about a deployment you owned."

After six. Revisit shape before you revisit count. If you are still running names-next-to-accounts, adding a seventh person will not fix the geometry. Move to pods or to an honest pool, using the operating guide, then hire into that shape. Past eight to ten, pods are usually where companies end up, which is a staffing forecast, not a culture preference.

Through all of this, keep the two documents next to each other. This page decides how many people and of what kind. How to run an FDE team decides how they work. The departure playbook decides what happens when one of them is gone. The jobs list is where you see who else is hiring the same people this quarter. Staff against the work, against coverage, and against a market that is growing faster than any BLS occupation will describe. The engineers were always going to be expensive. The expensive failure is hiring them into a plan that only works when nobody leaves the room.

If the backbone is still a collection of laptops, fix that before the sixth offer goes out. See what Archway does. The first two bridges are free, and the capacity you get back is the cheapest FDE you will hire this year. Engineers joining 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.