How to Staff an FDE Team

Reporting line, staffing unit, metrics, and load ceiling — once these four are decided, an FDE team stops being another name for "premium outsourcing."

Most companies get the first step of staffing an FDE team wrong: they hire. People get hired into the existing org, and six months later the team has turned into a delivery department — because none of the four constraints were decided: reporting line, staffing unit, metrics, and load ceiling. This article is about how to set those four.

After reading, you should be able to answer:

What an FDE team becomes when it reports to sales, delivery, or product, respectively
Why "two people as a pair" beats "one all-around hero"
How many customers one person can carry at most, and what happens past that

Reporting line: hang it in the wrong place and the role changes

Under sales, the team gets eaten by the win rhythm and turns into pre-sales — because the only question asked at quarter end is "can this deal close?" Under delivery, it gets eaten by tickets and SLAs and turns into outsourcing — because the only question asked is "which site is this person at this week?" To keep it feeding the product, the person who owns the product roadmap should own it, or it should report to product/engineering leadership.

Palantir worked early because FDE was its growth engine itself, reporting directly to the founding team with no sales quota to defer to. a16z's review gives the same advice: treat FDE as part of the product, not just a delivery step.a16z-palantirization The reporting line is how that advice lands in the org chart.

Staffing unit: pairs, not heroes

The single-person staffing failure mode is fixed: the person's technical capacity gets drained on site, with no time to think about what should sink into the platform, and the team ends up a collection of lone operators fighting their own battles — capability lives in people, not in the system.

Palantir's staffing is paired: Delta (the forward-deployed engineer who builds it) plus Echo (the deployment strategist who owns the mission, senior customer relationships, and the adoption path), backed by Dev (platform engineering).a16z-forward-deployed The key to the split isn't what each person does; it's that one of the two has "did what we learned get back to the platform" as their KPI — if both are writing code and fighting fires, the feedback loop never happens.

Small teams without two people to spare can still keep the role split: have the engineer reserve a non-negotiable block each week to turn field gaps into product requirements or connectors. The roles can be merged; the function can't disappear.

Metrics: no quotas, so what do they carry?

The external market is clear: in 1,000 FDE job descriptions, the share with sales quotas is 0%.bloomberry-fde-jobs But "no quota" doesn't mean "no numbers." Three are enough:

Reusable assets: each project leaves behind at least one thing the next customer can use directly (connector, template, eval set, migration script).
Activation and renewal: for accounts you take over, did real 30/90-day usage go up? This is the live launch ≠ activated judgment applied to an individual.
Feedback adoption rate: of the issues raised to product, how many actually made it into the roadmap? Counting issues alone produces junk requests; measure adoption.

Don't measure "travel days" or "hours on site" — that's exactly the ruler that turns FDE into outsourcing.

Load ceiling: how many customers per person

FDE value comes from "going deep on multiple problems in one customer," and going deep needs continuous attention. Industry pods commonly run at the dozen-people scale; two customers per person at once is the norm, and a quality cliff starts at the third: on-site visits turn into check-ins, and delivery regresses into tickets.

Set the ceiling by stage: lighthouse customers in the validation phase need dense on-site presence — not a single extra account; in the replication phase, two or three isomorphic customers can be given to the same pair — as long as they run off the same playbook. The judgment basis isn't headcount; it's "does this person have time to write down their field insight?" If there's no time to write it down, you're burning your most expensive asset.

Hiring: three observable signals

The three capability layers (technical breadth, translation, ownership) are broken down in Three Capabilities, Not One. Here's how to test them:

Give them dirty data and watch what they ask. Strong candidates ask "which system reconciles this table" and "who maintains this field," not which model to pick first.
Ask for an example of them changing the customer's process. Someone who only takes orders becomes premium outsourcing on site; someone who can tell you how they moved a customer from "what they thought they wanted" to "what actually helps" is this role.
Ask what they do without a product foundation. Someone who answers "just write scripts to hack it together" — check whether they'll sink those scripts into the platform. Someone who answers "define the scope and say no to part of it" is more likely to hold the boundary.

Degrees, big-company tenure, and model-tuning skills are all weak signals.

Three questions to self-check

Who does your FDE report to? Does this person's quarterly goals include one line that says "the product got stronger because of the field"?
After the last project ended, what did the customer keep besides the system? Did the team gain one asset it can move to the next customer?
At the current customers-per-person ratio, who has time to write down the field gaps? If the answer is "nobody," what you lack isn't headcount — it's the feedback mechanism.

The cost, as usual, up front: this org design is more expensive than "hire two capable people." Paired staffing means the first project feels like you're paying for an extra person. Reusable-asset metrics mean near-term delivery gets slower. A load ceiling means turning down deals you could have signed. These three expenses are the ticket to "replicable" — skip them and you stay forever at the hero-based scale, and heroes leave.