Leading FDEs

What the evidence covers

The limits first, because they are severe. Nobody has studied how FDE teams should be managed: there is no data on how many engagements an FDE can carry, how many FDEs one manager can lead, which team shapes ship more often, or which metrics predict a good engagement. Nothing is at T1, and the T2 material is self-reported: headcount, the share of internal hires, and one executive describing his own team. The rest is two manager job posts (primary evidence of what employers ask for, T4 as evidence of how the job is done) and a few relayed accounts of other teams. Everything else here is the book's own argument. The template at the end is built on the five conditions in When Engagements Fail and the four commitments in Judgment Under Pressure. It is a practitioner's design, not shown to work.

The argument is this. An FDE manager does not run a team of engineers who happen to sit at customers. The manager runs a portfolio of engagements. Three decisions are theirs alone: which customers get an FDE at all; whether each account's load-bearing commitments still hold; and whether field work reaches the product. A team managed on hours used or billed will drift toward services, whatever its charter says, because services is what fills hours. Jarvis says he watched the same drift in consulting firms that meant to become product companies, pulled back by "the short-term lure of services revenue" (quoted in Origins and Economics; T4, one practitioner's experience). Each section below is one place where the manager either resists that pull or quietly gives in to it.

The job, as the posts write it

Two posts define the job more precisely than any article does. Anthropic's first FDE Manager post calls the job "a player-coach role with a strong bias toward leadership". The manager stays close enough to "review architectures, debug production issues, and pair with your team when it matters", but "your primary impact will come from the people you hire, the standards you set, and the culture you create". The duties are a portfolio job in all but name. The manager will "Staff and oversee customer engagements across your team's portfolio, making resource allocation decisions that balance customer needs, team development, and business priorities", and will work with account teams "during the pre-sales process to qualify engagements, scope work, and inform statements of work". It also asks for "repeatable playbooks, starter repositories" and "engagement reviews". Delivery logistics and stakeholder management sit with a separate role, Engagement Managers (Anthropic, Manager, Forward Deployed Engineering; T4).

OpenAI's post is more direct about how the manager is judged: "Your success will be measured by how consistently your team ships, how clearly you deliver signal to Research and Product, and how durable your team and delivery model prove to be." The manager must "Define how we staff and support field teams" and still "Write and review production-grade code" (OpenAI, Manager, Forward Deployed Engineering - NYC; T4).

Neither post mentions utilisation, billable hours or revenue per FDE; 17.6 argues they are right. Both want the manager to keep coding, which raises the first practical question: how much? A rule of thumb, this book's and untested: review, pair and unblock, but never own a heavy phase of an engagement yourself. A manager who owns an eval climb stops reading the portfolio for weeks, and nobody else reads it. If you would rather raise the bar on other people's work without owning their careers or the staffing plan, the Staff FDE path in Levels, Burnout and What Comes Next is the other door.

Capacity is strategy: choose the accounts

The first portfolio decision is which customers get an FDE, and someone else often makes it. Sales promises an engineer, one is free, and the account is staffed before anyone asks what it is for. Origins and Economics argues that every FDE is a bet that today's field work becomes tomorrow's product. A manager who lets sales choose the accounts has let sales choose the bets.

Jarvis gives the clearest public account of choosing deliberately. OpenAI splits its FDE capacity "by those two levers": design partners for a definite product hypothesis, such as customer service or clinical-trial document authoring, and industries like semiconductors or life sciences where the problems teach the model something. Origins and Economics sets out the economics (Altimeter Capital, interview with Colin Jarvis, November 2025; T2, a vendor executive describing his own team). His advice to anyone building such a team is the manager's part: "be very clear as to like what the purpose of this FDE team is", and "be prepared to say no at some very difficult times like when you know somebody's going to offer you a lot of money to do something that's not strategic" (same source; T4, advice).

Most employers are not labs, but the rule applies: every account should say what it teaches the product. Then add Part II's filter. An account that will not accept the terms in Before the Engagement (one KPI the sponsor owns, data access by day 5, an end date, a price) is unlikely to reach production, however strategic it looks. So the staffing question has two halves:

• What will we learn? Name the product hypothesis, or the pattern you expect to reuse. "It is a big logo" is a sales reason, not an answer.
• Can it land? Check whether the five conditions from When Engagements Fail are present, or have a named person who will provide each by a date. Ask this before staffing, not in month eight.

An account that fails both gets the self-serve product, a partner, or a polite no. One that can land but teaches nothing is services work. Selling it may be a sound business decision, but make it openly; staffing it quietly with an FDE means nobody decided.

Team shape and load

The few published team shapes agree on one thing: on a large account a second role carries the strategy, the relationship or the logistics, so the engineer can build.

• Salesforce says some of its FDEs "are starting to work in pods that consist of one deployment strategist and two FDEs". Pods "focus full-time on one client for about three months", and "Many work individually with a customer" (Salesforce, November 2025; T4, the company describing itself).
• Glean puts its Founding FDE "in a pod with Forward Deployed PMs" (Glean, Founding Forward Deployed Engineer; T4).
• Anthropic pairs the team with Engagement Managers (17.2; T4).
• Cresta's FDE lead, in an interview with the Chinese tech outlet 硅谷101, describes FDEs paired with Forward Deployed Product Managers, who are responsible for the agent's behaviour and capability level and also handle requirements, risk escalation and upsell (硅谷101 via Tencent News, June 2026; T4, one interview).

The design point is What an FDE Is's point about ownership. A partner role can take logistics, calendars and much of the executive relationship, but not the threshold or the "not now" list, or the FDE becomes a builder working to someone else's scope. When you design a pod, write down who agrees the threshold; if it is the strategist alone, the role has changed.

On load, the evidence is one remark: the Cresta lead says each FDE currently carries "两到三个项目" (two to three projects), which tools might raise to five or six over time (same interview; T4, a single team's estimate and a forecast). Distrust anyone who claims a better number; a count of accounts is the wrong unit anyway. An account in its eval climb absorbs an FDE; an account in steady state after handoff needs an hour a week. The working rule this book proposes is to count phases, not accounts:

• Heavy: discovery, scoping, data access, the eval climb, the build. At most one per FDE at a time.
• Medium: staged rollout, the handoff drill, writing the product brief.
• Light: support after handoff, and scoping an expansion with a sponsor who already has a threshold owner.

In practice that allows one heavy phase plus one or two medium or light ones per FDE, which happens to match the Cresta count; treat the match as weak support, because nobody knows how his projects are phased. The rule is untested. Its logic is Part II's: the heavy phases are where the four commitments are negotiated, and an FDE with two of them at once will give one up in whichever meeting comes second. Its most useful property is that it exposes hidden load. An account that is "heavy on paper, idle in fact" is a stalled engagement, and it should appear in the review as a signal, not as spare capacity.

Hiring and onboarding

Hire on behaviour, not on the skill list. The Skill Map argues that posts screen well for technical and customer behaviour and barely at all for product and judgment, and the manager is the person who can correct that. In practice, probe the two domains the CV cannot show: "Tell me about a threshold you agreed and missed. What did you do the week after?" and "What did your last engagement change in the product, and who decided?" Getting Hired covers the loops from the candidate's side.

Salesforce built its team from three internal groups, "engineering, professional services, and customer success", and says "Around 40% to 50% of FDE movement at Salesforce is internal" (Salesforce Newsroom, above; T2, self-reported). Cresta's lead goes the other way on seniority: he hires no junior FDEs ("我这边是不招任何初级的FDE"), because a project usually has only one or two people on it and a junior struggles to win the trust of the customer's CTO. He wants a new hire in a project within "两到三个礼拜" (two to three weeks) rather than after two or three months of training (硅谷101, above; T4). His reason gives you the test for your own team: if an engagement will put someone alone in front of the customer's senior people, hire for that, or staff the engagement so nobody is alone. Salesforce's onboarding runs to six weeks, with two of training and four on the job (Salesforce Newsroom; T2). Neither shows its approach works better; together they bracket the choice between training people who know your product and hiring people who know the field.

The sceptics' strongest evidence is a hiring failure. The engineer in Orosz's reporting who called the job "a typical IT services mindset" and "quit 4 weeks later" is set out in What an FDE Is; the detail that matters to a manager is that the company wanted them "more on the engagement lead side" (Pragmatic Engineer, March 2026; T4, one engineer quoted of the two Orosz spoke to). Read from the manager's side, the candidate was sold one job and given another. The fix is cheap. Show every finalist a filled weekly review (17.7) with the names removed. It shows the load, whether anyone writes briefs, and who agrees thresholds. A candidate who walks away after reading it would have quit in week four.

Measure what the thesis measures

Services businesses measure utilisation, because hours are what they sell, and FDE teams inherit the habit from whoever funds them. It is structurally the wrong measure. The behaviours that separate an FDE from a contractor all lower it:

• walking from a scope that cannot land;
• declining an account that teaches nothing;
• setting days aside for a product brief;
• handing over so thoroughly that the customer stops calling.

The behaviours that raise it are staying on as the operator, saying yes to every extension, and rebuilding the same pipeline for the third customer. Pay a team on utilisation and you are paying for the services collapse that The Skill Map describes.

The investors who champion the model say something similar about quotas. a16z writes that "It's rare to find implementation leads that want to carry a quota, and that can also lead to counterproductive behavior" (a16z, "Trading Margin for Moat", June 2025; T4, opinion). OpenAI's post names its three measures: shipping, signal and durability. Here is a countable version, built from Part II. It is the book's proposal, not a validated scorecard:

Two rules keep it honest. "Early calls" must count as a success; if stopping an engagement shows up only as a lost account, the team stops calling failures and the portfolio fills with stalled work. And never add the six into one number: a team can cross every threshold and teach the product nothing, and an average would hide it.

A newly promoted manager should settle three questions with their own boss in the first month, in writing, before the first quarterly review settles them by default:

• Who decides which accounts get an FDE? If the answer is "sales, and you staff it", the choice in 17.3 is not yours, and the portfolio will drift.
• What is the team measured on? Get the six measures, or your version of them, agreed, including that an early call counts as a success.
• Who receives product briefs, and by when do they decide? A brief with no named receiver is a field log nobody reads.

The template: the weekly account review

Anthropic's post lists "engagement reviews" among a manager's cadences and says nothing more about them. Here is one design. It puts every account's load-bearing commitments on one page, showing what no single FDE can see: two engagements hit by the same product gap, one FDE carrying two heavy phases, a sales promise about to consume next month's capacity. Run it weekly, five minutes an account; anything longer becomes a decision with an owner.

WEEKLY ACCOUNT REVIEW                        week of: ____________
Manager: _______________   FDEs: ____   Live accounts: ____

Rules: five minutes per account. Any commitment not OK gets a
name and a date. Two signals inside four weeks: schedule the
post-mortem this week. Count phases, not accounts.

ACCOUNT: _________________   phase: _____________________________
  Threshold     written? Y/N   owner: __________   status: ______
  Commitments   threshold __  data path __  sponsor __  exit __
                (OK / AT RISK / GONE; for each not OK:
                 restorer ____________  by ________)
  Signals, 4wk  _________________________________________________
  FDE load      FDE: _________   phase weight: heavy/medium/light
                other phases this FDE carries: _________________
  Product loop  field log? Y/N   brief: _________  reuse: _______
  Decision      continue / reset / post-mortem / walk / staff
                owner: ____________   by: ________

(repeat the block for each account)

PORTFOLIO
  FDEs with more than one heavy phase: __________________________
  Requests waiting for an FDE: ___________________________________
    learn: product hypothesis / research / reuse / none
    land:  KPI owner / data by day 5 / end date / price  Y/N each
  Signal to product this week: ___________________________________
  Decisions to take upward: ______________________________________

That week's page, filled in, with ranges only:

WEEKLY ACCOUNT REVIEW                       week of: month 8, wk 2
Manager: the lead (part-time)   FDEs: 2   Live accounts: 2 (+1 req)

Rules: five minutes per account. Any commitment not OK gets a
name and a date. Two signals inside four weeks: schedule the
post-mortem this week. Count phases, not accounts.

ACCOUNT: the insurer, auto    phase: post-handoff (since month 5)
  Threshold     written? Y   owner: claims dir.   status: met
  Commitments   threshold OK  data path OK  sponsor OK  exit OK
  Signals, 4wk  none; overrides still improving suggestions
  FDE load      FDE: FDE 1     phase weight: light
  Product loop  field log? Y   brief: month 5, decided (build)
  Decision      continue      owner: insurer ops   by: n/a

ACCOUNT: the insurer, property   phase: expansion scope (month 6)
  Threshold     written? N   owner: head of property, unnamed
  Commitments   threshold GONE  data path OK  sponsor GONE  exit OK
                (restorer: COO, threshold owner + labelled set
                 within a few weeks, or walk)
  Signals, 4wk  steering moved twice, then skipped; "let's see
                what it can do first"; labelling a fraction done
  FDE load      FDE: FDE 1     phase weight: heavy on paper, idle
  Product loop  property docs logged; no brief yet
  Decision      post-mortem   owner: the lead   by: next invoice

ACCOUNT: second insurer   phase: pilot, eval climb (months 6-8)
  Threshold     written? Y   owner: their claims lead   status:
                below threshold; re-measure date agreed
  Commitments   threshold OK  data path OK  sponsor OK  exit OK
  Signals, 4wk  none
  FDE load      FDE: FDE 2     phase weight: heavy
                other phases this FDE carries: none
  Product loop  started from template; a fifth to a third reused;
                mixed-packet failures recurring here too
  Decision      continue      owner: FDE 2   by: re-measure date

PORTFOLIO
  FDEs with more than one heavy phase: none (FDE 1's is idle)
  Requests waiting for an FDE: new account, AE promised a free,
    open-ended PoC on document search
    learn: none (search is in the product already)
    land:  KPI owner N / data by day 5 N / end date N / price N
  Signal to product this week: mixed packets seen at 2 insurers;
    second column for the month-5 brief
  Decisions to take upward: no FDE for the new account; offer
    30-day paid pilot or self-serve. If property stops, FDE 1 to
    the template work for 2-3 weeks, then next engagement.

Three lines carry the decisions. "Heavy on paper, idle" turns a stalled account from spare capacity into a signal. "learn: none" and four "N"s make the refusal criteria the account executive can read, not the lead's preference. And mixed packets appear under two accounts, which neither FDE could see alone: the second customer that turns a finding into a product decision, as Feeding the Product argues.

Failure signals for a manager

These show up across the portfolio, so only the manager sees them.

One more is hard to see from inside: the best FDEs are always on the stickiest accounts. A customer who never lets a strong engineer go has turned the vendor into its operator. Rotate the FDE out on a planned date; if the account cannot survive it, the handoff never happened.