How Do You Build an FDE Team?

There is nothing so useless as doing efficiently that which should not be done at all. — Peter Drucker

When a company's AI project can't get off the ground, the first reflex is usually the same three questions: Is the model not strong enough? Add a couple of algorithm engineers. Are the people wrong? Swap out the team. Are the tools falling short? Buy a whole platform.

The money gets spent, the people get swapped, the tools get upgraded — and the project is still stuck exactly where it started.

This chapter makes the case that what's actually missing may be a role that owns the result, start to finish. Once that's diagnosed, the answers to when to hire, how many, and how a team grows from there tend to surface on their own.

I. Diagnose First: What's Actually Missing

Behind that opening three-question reflex — model not strong enough, people not right, tools not keeping up — sit at least three different diseases, and they call for completely different medicine.

Cause one, the wrong problem was chosen. You picked a problem not worth solving (it never cleared Chapter 6's five filters) — this is a direction disease. Swapping people doesn't fix it; re-choosing the problem does.

Cause two, the engineering walls didn't get scaled. The problem and the direction are both right, but people are falling on Part Three's eight walls — data and permissions never got sorted, integration never got wired through, outcomes can't be proven, results can't be turned into trust — this is an engineering disease, and what it needs is delivery engineering capability.

Cause three, nobody owns the result. The system went live and nobody uses it — this is an organizational disease, and what it needs is a role that owns the result end to end.

Of the three causes, only the first might call for swapping people. Most of the time the right answer is adding a role, not replacing a team.

A recommended diagnostic tool: run a post-mortem on failed projects. Take failed projects one by one and attribute each against the eight walls (Chapter 9) plus the four responsibility segments (discovery, production engineering, business adoption, product feedback) — attribution clustered around "couldn't build it" points to a model-and-engineering-capability problem; clustered around "nobody uses it" points to a missing owner of the delivery loop. The same diagnosis made it into the official language of Accenture and Microsoft's 2026 announcement of a joint forward-deployed engineering practice: what's stalling enterprise AI isn't technology — it's having someone who can put engineering capability in the right place.¹

II. Three Signals on Timing

Once the gap is diagnosed, the second question is whether to build now. Wait for three signals before hiring.

Signal one, there's a clear business problem. Not "let's explore AI a bit" — a problem you can actually state: which step, what it costs, who's under pressure about it (Chapter 6). "We want to do AI" is where a budget starts, not where a team starts.

Signal two, there's a business-side sponsor willing to invest. Executive backing, the business side contributing people, data, and time (Chapter 16's two gates) — delivery without an internal ally is a parachute drop, and parachute drops have a very low survival rate.

Signal three, you've already run one trial. Even if it was an outside vendor's Minimum Viable Deployment (Chapter 7) — the company has at least seen once what "problem to production" actually looks like, and knows what it wants.

When the three signals aren't all there yet, the right move isn't to hold your breath for headcount — it's to buy a small service first: an outside assessment, a single-point delivery, letting someone else's delivery help you assemble the missing signals (that market gets its own treatment next chapter). Building a team is a heavyweight commitment; don't stake it on uncertainty.

III. The First FDE: Profile, Placement, Evaluation

Once the signals are there, hire the first person. Three decisions determine whether it works.

Profile: senior, not junior. The first FDE needs strong engineering-delivery capability plus strong business-reconstruction capability (the first two of Chapter 24's three pillars need to be strong; the third can be developed on the job). It can't be a junior hire — a junior needs a team around them to grow inside: the new hire from Japan in Chapter 23, still two months into her customer-confirmation phase, had a team standing behind her;² drop that same person straight into an unsupported solo post, and you're leaving her to thrash alone in deep water. The first FDE has to be someone who can build their own scaffolding.

Placement: the business-delivery line, not a pure technical line. Report to a business or delivery leader, not a research line — the reporting line decides what gets responded to first. At the same time, define the interface with the product team from day one, even if it's only a once-a-month feedback review (the minimum version of Chapter 22's mechanism). Without that interface, the first hire slowly turns into an outsourced team.³

Evaluation: on results, not hours. Acceptance metrics plus adoption metrics (Chapters 8 and 15), not lines of code or day-rate utilization — misaligned evaluation turns an FDE into an ordinary developer. This is the organizational version of Chapter 2's third test: someone who sells time isn't accountable for a result; whatever you measure is what the person becomes.

IV. Outside Reference Points (I): Two Roles, Three Functions

There's no standard answer for building a team, but there are a few highly credible reference points. The first is two modern shapes for splitting the roles.

The discoverer/deliverer pair (the profiles quoted in Chapters 1 and 24): the Echo-type on-site analyst owns discovery and relationships; the Delta-type deployment engineer owns delivery — hire the two roles separately, by profile, and don't expect them to swap.⁴

Three functions and an account model: one applied-AI company organizes itself into three blocks — engineering (platform and infrastructure), go-to-market (the acquisition funnel), and applied AI (the bridge: catch a warm opportunity, define proof of value, get the agent into production). Applied AI then splits into two roles of its own — the Agent PM, who carries the account from proof of value all the way through production and beyond, technical enough to build an agent themselves without having to write production code; and the forward deployed engineer, who writes code, feeds lessons back into the product, and needs enough commercial sense to sit directly in sales conversations — because "the person who's actually going to build the thing is the most credible voice in the room."⁵ Another company's variant (Cresta) gives a staffing ratio: one forward deployed product manager runs two to three FDEs, and a PM can manage multiple projects at once; once the team scales, they also deliberately grow specialists by industry (healthcare insurance, say) and by technical domain (payments, search) instead of expecting everyone to be a generalist.⁶

Put the two samples together, and the lesson is: "the one who understands the customer" and "the one who can deliver" should be two clearly defined roles from day one — either two separate positions, or one position wearing two explicit hats. Pile all those requirements onto one person and expect them to be great at everything, and you'll struggle to hire anyone at all.

V. Outside Reference Points (II): The Chinese Version — the Trio, and the Extreme Case

The second set of reference points comes from the Chinese market and from the giants. The Chinese version gives a more complete answer for building a team: not splitting the work in two, but fusing three specialties into one small unit.

The deepest version comes from Lingyang — Alibaba's enterprise AI unit — and its "organizational trio" (background and case details in Chapter 18). Their view: "our approach isn't one person, it's an organization" — finding one person with all that talent is "extremely hard."⁷ The organization splits into three roles: the business analyst owns direction, driving toward business outcomes — orchestrating a 260-plus-step customer-service workflow, finding AI's best working pattern, setting eval standards; these people come from industries like beauty, appliances, and automotive. The AI architect owns the technology, translating business problems into model selection and system design — what size of model to use, which step needs a human in the loop, which step the machine takes over. The customer-side coaching team owns the business, an embedded coaching function — the best customer-service reps and top sales performers are pulled from the customer's own staff to give continuous feedback and coach the AI, with the vendor deliberately stepping back here.⁷

Set this beside Palantir's Echo/Delta split, and the structure is the same underneath, cut differently:

	Palantir Echo/Delta (U.S. version)4	Lingyang's Trio (Chinese version)7
Direction: what to do	Echo — on-site analysts and account managers	Business analyst: outcomes, process orchestration, eval standards
Technology: how to build it	Delta — deployment engineers	AI architect: model, data, system design
Business: how to use it well	Implicit in Echo's relationship work	A formal third role: customer-side coaching team, continuous feedback

The difference concentrates in the third row: the U.S. version splits in two (discovery/delivery), and "business coaching" is an implicit part of Echo's job; the Chinese version promotes it to a formal, third role — because the benchmark business knowledge is scattered on the customer's side (Chapter 18's "the benchmark performer as the default"), and without folding the customer's own people into the build, the model never gets calibrated right.

A more elastic version of this also comes from the Chinese market. One practitioner has said that what a Chinese enterprise doing AI transformation actually needs is three roles — project manager, engineer, product manager — and those three roles can be one person, two people, or a whole team; there's no requirement to formalize headcount.⁸ At bottom it's the same point: you need someone who understands the business and can translate requirements for the AI engineers. How the three roles get combined depends on company size and how strong the signals are (the three signals from Section II) — with the signals just barely in place, one person wearing all three hats can still get things started; once the signals are solid, split it into three positions. The trio is the standard form; the elastic combination is its cut-down version.

The extreme case: Accenture and Microsoft's joint practice — a scale of thousands of AI-skilled engineers, official language calling it taking AI "from idea to production in days, not months," acting as "the gateway for enterprise AI transformation."¹ A reference point, not a template to copy — thousands of people is the shape delivery takes after it's been industrialized, not the shape it starts in.

Set the two sets of reference points side by side, and two shared points stand out. First, the complete form of FDE isn't one person, it's a built team — special-forces style: small, multiple specialties fused together, embedded on the front line, accountable for the mission's result. A solo FDE is that team's cut-down form; Section III's "the first FDE" is exactly about which pieces to keep when you cut a team down to one. Second, an FDE has to have an institutionalized feedback channel into the product team — without one, delivery quietly turns into outsourcing, a warning that holds across every market.³

VI. How a Team Grows From One Person

Once the first hire is standing on solid ground, how does the team grow?

Step one, get the smallest possible loop running. One FDE, one product-side point of contact, and half a platform-support person (a share of a backend/infrastructure engineer's time) — run two or three complete deliveries through it. What this step validates isn't the person, it's the loop itself: problem definition → delivery → adoption → feedback, the full chain walked through once, inside the company.

Step two, scale against the bottleneck, not against a plan. Deliveries are queuing up — add an FDE. The same kind of customization keeps recurring (Chapter 21's trigger signal is lit) — add product-side headcount and fold the customization into the platform. So many customers that service quality is slipping — first ask whether it's a people bottleneck or a feedback-loop bottleneck (if it's the latter, adding people only adds chaos). Review every step of scaling against Chapter 19's six metrics — scale by watching the direction of the implementation-leverage ratio and the customization-decline rate, not by feel (see Figure 26-1).

Figure 26-1: Team growth isn't stacking headcount — it's letting collaborative mechanisms and platform capability gradually absorb what used to be on-site responsibility.

The reverse of this path is "hire a twenty-person delivery department in one shot" — headcount arrives before the loop does, and the organization hardens into a headcount-heavy shape before it ever develops the habit of feeding lessons back. Chapter 19's hero-culture trap and consulting-style trap both grow out of exactly this shape.

VII. Three Anti-Patterns

The close, as always, is a mirror.

Chasing the trend into a headcount line. A competitor has an FDE, so we need one too — the organizational version of Chapter 3's "outsourcing in a new coat, a passing fad." A role created without the signals in place always ends up as old implementation wearing a new title.

Hiring and then neglecting. You hire the person, hand them a customer, but give them no business-side interface, no feedback channel, no results-based evaluation — miss two of those three, and you're training talent for your competitors. The resignation letters from people like this are usually written politely; the real reason never makes it onto the page.

Managing FDE the way you'd manage a consulting firm. Evaluate by the day, schedule by utilization rate, treat feedback time as "not real work" — every management move borrowed from a consulting firm, while still expecting a productized result. Whatever you measure is what you get; manage by hours, and hours are what you'll get.

The company's side of the loop closes here. One group is left: people who don't join a company at all, who work on their own — can an individual go independent, part-time, or found a business doing FDE work? Next chapter.

---

Footnotes

1. Accenture Newsroom, "Accenture Launches Microsoft Forward Deployed Engineering Practice to Help Organizations Scale AI Across the Enterprise" ↩ ↩²

2. "I Thought FDE Meant Fighting Alone at the Customer Site" — What Two Months on the Job Actually Looks Like ↩

3. @deployengineer (Bhaulik Patel), essay series ↩ ↩²

4. Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩ ↩²

5. "Inside an Applied AI Company" (Pace long-form post) ↩

6. Silicon Valley 101, Episode 240: "The Hottest New Job in Silicon Valley — FDE" ↩

7. Silicon Valley 101, Episode 248: "China-Style FDE, with Alibaba Lingyang's Peng Xinyu" ↩ ↩² ↩³

8. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩