What Kind of Person Is Cut Out for FDE?

The fox knows many things, but the hedgehog knows one big thing. — Archilochus, as quoted by Isaiah Berlin in The Hedgehog and the Fox

Ask online what capability an FDE role actually needs, and you get two answers, arguing loudly with each other.

One side: business knowledge can be learned on the job, technical skill can't — technical skill is the hard bar, business is the soft one.

The other side flips it: building is already handed off to agents, so business understanding is the truly scarce thing.¹ Both sides sound absolutely certain. Which one should you believe?

Don't rush to a verdict — they're both answers the same market gave, at two different stages, from two different vantage points.

The real test only comes into view once two frameworks are in place: the three pillars, which say what's required, and the two-layer structure, which says what depreciates and what compounds. By the end, you'll see that each of those competing claims has hold of only one of the two layers.

I. The Three Pillars: An Intersection, Not a Single Specialty

FDE capability sits at the intersection of three pillars.²

Pillar one, engineering delivery. Not algorithm research — the engineering that gets something running: integration, permissions, evals, operations, all of Part Three. It's the first rebuttal to the "FDE talks its way through" image: in the on-site samples, engineers put three-quarters of their time into engineering and model optimization; people who only talk don't survive the first wall.³

Pillar two, business understanding. Breaking down a customer's vague goal into a process that can actually be measured. It builds in three levels: level one, understanding industry vocabulary; level two, reading the logic of a workflow — why this company's order routes the way it does; level three, the scarcest one, reading incentive structures — whose performance rating rides on this process, whose interests the new system will disturb. That third level is the mirror image of Chapter 16's "three kinds of not understanding": someone who doesn't understand the organization can't do this job at the executive level.

Pillar three, project-driving ability. Knowing who signs off, who's affected, and whose resistance needs handling. One practitioner puts "executive-level understanding" right at the front of the capability map, calling it "the first door" — fail to get through it, and none of the other capabilities have anywhere to go; his metaphor is door, process, muscle — train nothing but muscle, and you're still stuck outside the door.² This is the field-operator's version of Chapter 15's three cast members: supporters, influencers, and the people who stand to lose.

The three pillars are abstract; one company's actual hiring bar puts them on concrete ground.

Cresta's FDE lead has one clear "who we don't hire" rule: no junior FDEs — a project site usually has only one or two people co-creating with the customer, and someone without enough track record can't build trust. In his hiring language, the three pillars map onto three concrete layers: technically, you have to be "a solid developer who has built and tested AI agents"; on communication, you need "hard-earned, credible customer-facing experience" — able to talk with the other side's CTO, IT director, and security lead, and able to break a complicated problem down for someone non-technical; the rest comes down to being dependable, resilient, and able to carry uncertainty — he prefers founding engineers, people who've been through real turbulence (his term for the ideal hire is a "mini-CTO": hands-on, able to write code, able to talk to customers, thoroughly dependable).⁴

The three pillars are an intersection, not a full house on every subject: clear the bar on all three, and your strongest one sets your style — a strong engineering pillar leans delivery-type, a strong business pillar leans discovery-type (the two roles in Section III), a strong organizational pillar leans driver-type. "The full-stack superhuman who does everything" is a misconception — the three strengths each form their own school.

The three pillars aren't a fixed recipe either — the weighting shifts with market structure. The Silicon Valley sample puts three-quarters of its time into engineering;³ a Chinese practitioner who has served more than thirty enterprises splits the job into consulting, sales, engineering, and coaching instead, with engineering ranked third — sixty percent of the time goes to business and relationships.⁵ The difference isn't about who's right; it's about whether a product foundation exists (Chapter 18): a strong foundation absorbs the complexity for you, so engineering time naturally converts into delivery; without one, consulting and sales become the bottleneck instead. What the reader should learn isn't which ranking to memorize — it's how to judge which ranking fits the market they're actually facing.

One more relationship worth spelling out: the three pillars are the job-level expression of "the composite capability a build needs." The pillar model was never describing a superhuman — it's a breakdown map for a small team's capability. In team form, the three pillars can sit in different roles — Chapter 26's Chinese trio (business analyst, AI architect, business coach/embedded team) is exactly one small team with each pillar as its own long suit; in individual form, all three pillars press down on a single person.

II. Two Layers: What Resets to Zero, What Compounds

More important than the ranking is the time dimension.

The domain layer: an industry's processes, vocabulary, and data shapes. Switch industries and it resets to zero — retail's restocking logic doesn't transfer to finance's risk control.

The meta-capability layer: problem decomposition, baseline measurement, acceptance design, accountability management — the four items already native to this layer. Add one more, deeper still: the capacity to learn itself. Models, frameworks, and industry jargon all change year over year; new terms and new workflows never stop appearing. What resists depreciation most in the meta-capability layer isn't what you've memorized — it's how fast you can absorb something new, and whether you're willing to keep letting new things in. Openness itself is a meta-capability. Cross-industry compounding — Chapter 8's acceptance contract, Chapter 12's eval method — carries over unchanged when the industry changes; new tools and new jargon draw on that same "relearn from scratch" muscle (see Figure 24-1).

Figure 24-1: Fitting the FDE role isn't about acing any single subject — it's about the intersection of three capabilities and the assets that compound.

The samples back this up: what transferred for the twelve-year engineer who moved into the new role clearly wasn't any industry knowledge — it was engineering meta-capability: production instincts, a nose for where things break, a feel for systems.⁶ The same logic holds for an FDE who moves from retail to manufacturing: the domain layer resets, the meta-capability layer travels.

The investment implication is direct: training and hiring budgets should tilt toward meta-capability — industry knowledge can be bought (consultants, expert interviews, a few months on-site grow it naturally); meta-capability can't. This is also the answer to the two opening claims. The first, "business can be learned," holds at the meta-capability layer. The second, "business understanding is the scarce thing," holds at the domain layer and the incentive-structure layer at once. Both layers are right — put together, they're the whole picture.

III. Discoverer and Deliverer: Two Kinds of People, One Role

Above the three pillars sits another layer of division inside the role itself — within the same FDE team, discoverers and deliverers are two different kinds of hires. McGrew has sketched both profiles — discoverer and deliverer. Chapter 1 already defined this split; here's what it means for hiring:⁷

Discoverers (the Echo type): the classic profile comes from the domain itself — his examples are a former army officer, someone who spent years deep in healthcare, seasoned domain veterans. And they have to be rebels: people who understand exactly how things are done today and are convinced it isn't good enough. Why does it have to be a rebel? Because the new software has to deliver a 3x or 10x step change to be worth the effort of building at all — a domain expert who's made peace with the status quo can't see why it has to be that big a jump, and can't talk anyone else into it either.

Deliverers (the Delta type) — and the anti-profile cuts closer to home: a craftsman engineer is the wrong hire. Someone seduced by getting the abstractions exactly right, by code built to stay maintainable for a decade — the deliverer's job is to write a prototype that actually runs, fast, absorb a lot of pain doing it, and accept that the first version is usually thrown away and rewritten (McGrew's own words, already quoted in Chapter 7 at the point about what happens to MVD code). Temperament and background have nothing in common with the discoverer's, and the two can't be swapped.

That anti-profile will land hard for engineer readers, but read it correctly: it isn't saying craftsman engineers are bad — it's saying the craftsman's values are mismatched to this job's delivery rhythm. A prototype exists to test a problem, not to be handed down through generations.

IV. What a Senior Engineer Brings — and Where the Gaps Are

Put the three pillars and the two roles together, and the checkup for a senior engineer moving into FDE writes itself.

The natural strength is system-level judgment. One lesson from the Chinese delivery front line: when packaging a capability for a customer, the hardest part isn't the packaging itself — it's knowing what to package, which takes architectural judgment, and needs a company's mid-level or senior staff involved from day one, in an architect's capacity.⁸ A decade of accumulated engineering instinct happens to fill exactly this gap.

The common weak spot is project-driving ability: used to answering for code, not used to answering for people; used to writing it yourself, not used to watching someone else write it; and least used to all, starting work with no clear spec — because there is no spec on-site. So the weight of transition training should sit on the weak spot, not the strong one: sending engineering backbone staff to sit through customer meetings, run requirements interviews, and take a complaint or two does more good than teaching them new technology ever would.

Two companies' hiring philosophies confirm each other, and also pull against each other. Jove Zhong (Cresta) won't hire any junior FDE, only people who have built and tested AI agents; Vincent Lu (Ventus AI) has hired two people still in school — one fresh out of high school on his way to Harvard, one who left NYU without finishing — but he admits himself it "falls a bit short," because at an early-stage company the FDE has to independently carry customer communication and project management, and "without having tripped over a few things yourself, it's hard to develop any sense of project management."⁹ Put the two hiring lines together, and they confirm this chapter's point that the three pillars are an intersection, not a full house — but the bar can't drop: Cresta filters on track record, Ventus manages the risk by admitting the gap up front; different paths, but neither dares put someone in the seat who hasn't been tested on project-driving ability — exactly the weak spot this section names, and neither company can dodge it.

The hiring-funnel numbers are worth citing too: Jove Zhong's team has received 7,000 résumés for a single opening, and issued fewer than 20 offers.⁹ That number confirms this chapter's opening point — the intersection of the three pillars isn't a framework a writer worked out after the fact; it's a real filter in active use on the hiring floor, and it filters harder than most people would guess.

V. Self-Check: Are You a Fit

Twelve questions to check yourself against — not a personality test, don't treat the result as a verdict. For each, score yourself 2 for "often," 1 for "depends," 0 for "almost never."

1. Given a vague goal ("just get this handled"), I can break out the first step on my own.
2. After getting interrupted, I can pick my train of thought back up quickly.
3. Talking with someone from an unfamiliar business, I can find the thing they're actually worried about.
4. I can walk someone with no technical background through a technical plan clearly enough for them to decide.
5. When there's no right answer, I'm willing to make a call on limited information and own the outcome.
6. I want to be accountable for the result, not just the quality of the code.
7. When a customer calls me at midnight, my first reaction is to solve the problem, not to feel annoyed.
8. I can hold more than three things in my head at once without dropping any of them.
9. Seeing someone else's business process in disarray makes my hands itch to fix it.
10. I can accept that the first version of a plan may get thrown away and rebuilt later.
11. I'm willing to spend time on relationships — meals, small talk, favors — and treat it as part of the job.
12. Starting over from scratch in a new industry excites me more than it scares me.

18 or above: the groundwork for the three pillars and the psychological bar are basically in place — worth trying (Chapter 25 gives the path). 12 to 17: some of the conditions are there; see where the points are missing and use the three trials from Chapter 23, Section VII, to fill the gap deliberately. 11 or below: this isn't a capability shortfall, it's an open question of fit — read the second-thoughts checklist in Section VI before deciding.

VI. A Second-Thoughts Checklist

One last thing, held in reserve for balance: three kinds of people should think twice before moving into FDE. Note — this isn't a capability problem, it's a fit problem — a mismatch is a lose-lose.

People who prefer deep, focused work on a single problem. This job's default state is high-frequency switching (Chapter 23) — routine for some people, a constant drain for anyone who prefers deep focus.

People who need a clear spec before they can start. On-site, you write the spec yourself, and it changes once you have. Waiting for clean instructions is a luxury this job doesn't offer.

People willing to answer only for code, not for results. This job is graded on whether the customer's business actually changed — code is just the means. Anyone who treats the means as the whole boundary of their responsibility will go quiet in every retro where "the system worked but the business didn't move."

VII. The Company's View: If You Can't Buy It, Grow It

Beyond the individual view, look at FDE from the company's side.

Composite talent is either too expensive or not up to par — most companies end up having to grow it themselves.¹⁰ The internal training path matters more than hiring here: engineering backbone + on-site rotation + shadow delivery — pull people with strong meta-capability roots out of the engineering team, put them on rotation with real customers for one or two quarters, have them shadow a senior FDE through the full process first, then let them independently carry one small customer's complete loop.

The capability model is set. Next comes a very practical question: for an engineer already on the job, how do they actually walk the path from writing code to owning results — the next chapter is the transition path.

---

Footnotes

1. "FDE Engineer 101: Bridging the Gap Between AI and Business" (Chinese-language compilation video) ↩

2. "100 Questions About FDE" (open-source ebook) ↩ ↩²

3. Baseten, "What I Learned as a Forward-Deployed Engineer Working at an AI Startup" (Het Trivedi) ↩ ↩²

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

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

6. Hacker News, "A Week in the Life of a Forward Deployed Engineer" (10 customers, 50 hours) ↩

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

8. Yilu Tongxing (一路瞳行), Episode 134: "From AI Assistant to Digital Employee" ↩

9. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩ ↩²

10. "Anyone Out There Actually Doing FDE Work?" (linux.do thread) ↩