Why "Hire a Few FDEs" Is a Big-Ledger Decision, Not a Small One
"This customer matters — let's hire two FDEs first."
You should invest in a business that even a fool can run, because someday a fool will. — Warren Buffett
"This customer matters — let's hire two FDEs first."
In a project meeting, that sentence sounds almost unobjectionable. The customer needs a deep deployment, sales doesn't want to lose the deal, and the existing engineering team has no spare capacity. Two people who can sit on-site and put out fires look like the fastest fix.
But once the hiring decision is made, the question stops being just "two more salaries." When the next customer shows up, do you hire two more people again? Can the code they wrote, the processes they got running, and the experience they built up for this customer carry over to the next project?
"Hire a few FDEs" looks like a staffing question on the surface. What it's actually deciding is what the company will grow on going forward. This chapter works exactly that ledger.
I. Sort the Small Ledger from the Big Ledger Before You Write Anything Down
The small ledger is the hiring lens: what's this person's background, how capable are they, what salary do they need, can they handle being on-site. The big ledger is the input-output lens: what's this team's input-output structure? How does it change as the customer count grows? What does it turn the organization into?
Lined up side by side, the difference is obvious. The small ledger asks, "what does this person cost per year"; the big ledger asks, "for every additional customer, how much does cost rise and how does gross margin change." The small ledger asks, "can he handle the customer"; the big ledger asks, "can what he built for this customer be used by the next one." The small ledger asks, "how many people does the team need"; the big ledger asks, "does team size have to grow linearly with the number of customers."
This book's position is clear: answer the big ledger first, the small ledger second. If the big ledger doesn't add up, no matter how well you answer the small ledger, you're just hiring people into the wrong organization. This is also the prerequisite for Chapter 26 (when and how to build the team) — every detail of organizational design grows out of the ledger in this chapter.
II. Six Metrics That Put the Big Ledger into Numbers
The big ledger can't just be a posture — it has to be calculable. Six metrics, each clarifying two things: how to calculate it, and what a healthy number looks like.1
First, Deployment Leverage: how much customer revenue can one FDE get into production? The numerator is customer revenue newly reaching production; the denominator is the number of engineers deployed on it. It answers this business's most basic question: how much can one person carry?
Second, Time to Value: how long from signing to the customer's first measurable business result? A reference range: validating a Minimum Viable Deployment runs in weeks (2–6 weeks), a full deployment in months (1–4 months); if this period keeps stretching out, that's the first sign something's wrong with the methodology or the platform.2
Third, Cost to Serve: how much engineering effort do the deployment phase and the post-launch period each require? This one has to be counted in full — hidden items like travel, support, and rework are the easiest to miss.
Fourth, Expansion Effect: do customers with an FDE involved grow faster than those without one? Of an existing customer's new revenue, how much requires no new delivery work? This one tests the logic that "deep service buys expanded trust."
Fifth, Product Leverage: how much of the work done for one customer turns into a capability that later customers can reuse? If a platform component saves two months on every future deployment, it's creating leverage at the company level.
Sixth, and the one to watch most closely: the Customization Decline Rate. The Nth customer's customization volume should be significantly lower than the first customer's — if it doesn't drop for three customers running, check the product feedback mechanism immediately. Chapter 21 works through this one in depth; for now, just get a first impression of it.
You don't need to track all six at once — watching the three to five most relevant to your current stage beats a dashboard that covers a whole wall.2 But an organization that watches none of them is doing the small ledger with its eyes closed (see Figure 19-1).
Figure 19-1: The FDE big ledger runs on six interlocking metrics, not just new revenue.
III. The Cost of Heroics
Of the six metrics, Deployment Leverage is the first to expose "heroics" for what it is.
What's a heroic FDE: extremely capable individually, carrying everything alone — give him the hardest deal, the hardest customer, the firefighting. At ten customers, the hero is an asset to the company: his name is the word-of-mouth, and his presence alone brings three deals back from the dead. But at a hundred customers, the hero is a disaster for the company — because organizational capability lives in him personally, not in process or product: he can't carry a hundred customers, he can't teach a hundred engineers (the knowledge is in his head), and when he leaves, a corner of the company caves in.
A deeper trap than the individual hero is hero culture. A forward-deployed team with no boundaries becomes the default dumping ground for "everything in the organization that doesn't fit anywhere else": sales shoves in features it already promised, product shoves in gaps it can't fill, engineering shoves in integrations it doesn't want to build, customer success shoves in escalated complaints — soon, every kind of work gets dumped here, and in the end it's all held up by a few heroes: a handful of standout engineers keeping customers alive through sheer force, with the business depending on people instead of systems. It runs fine at ten customers. At a hundred, it seizes up.
The fix is in Chapter 22 — turning individual capability into product capability — but for now, note this down: a hero is a linear-growth asset, and this business either compounds or decays; there's no linear gear. One practitioner put it as clearly as it gets: the best forward-deployed organizations work to eliminate their own jobs — building templates, building tools, turning customer-specific code into configurable platform capability, and continuously pushing the role toward higher-value problems (see Figure 19-2).1
Figure 19-2: As customers grow, heroic headcount locks gross margin down; only reusable assets make the curve fork.
IV. McGrew's Two Ledgers
You can't talk about the big ledger without McGrew — he's the most successful person to have lived this model firsthand, and the most precise in walking through its numbers. On a podcast, he gave two separate accounts.3
The first, about KPIs. He drew a distinction between two strategies: in a product-market-fit strategy, you want to do less work per customer, lower costs, and keep contract size flat; the FDE strategy is the opposite — you want to drive contract size up, doing increasingly valuable things for the same customer, and because the work is more valuable, it's acceptable to keep a certain level of customization per customer. So the internal yardstick is contract size, not necessarily work per customer.
At first hearing, this seems to contradict "declining customization" — wasn't customization supposed to go down? Hold on — the tension is real, and Chapter 21 takes it on directly: the right measure for the decline is customization's share of delivery, not absolute hours. When the contract grows and the unit of customization stays flat, the share still falls and gross margin still improves — the two readings are measuring the same health.
The second is about the path to margin. He said that a new deployment for a customer can actually lose money early on; the longer you stay with that customer, the more the product fits their needs through the discovery process — you no longer need a large group camped on-site figuring things out — and you've earned the right to work on bigger problems. So the cost per unit of value you deliver falls, and margin flips from negative to positive — it might take a year, it might take several.3
This ledger explains one thing: why a mature FDE organization is willing to "lose money" on the first few customers — that's not bad math, it's treating early losses as an investment in product discovery, a bet that the contract grows over time. It also adds a timeline to the six metrics: it's normal for every metric to look ugly on the first two customers — what matters is the direction, not the starting point.
V. A Three-Year P&L Comparison
Here's a demonstration table you can swap your own numbers into and recalculate.
Two similarly sized vendors start from almost the same place: three customers each, comparable contract value per customer, six-person teams each. Vendor A tags every customization request from day one, reuses connectors starting with the third customer, and by the fifth customer runs half its processes through configuration; Vendor B builds every deal from zero, because "the customer's in a hurry, reuse is too slow."
Year one, Vendor B's revenue is higher — no reuse means more person-days, and more person-days can be sold directly.
Year two, the fork appears: at Vendor A, the delivery cycle for customers six through ten shortens by 40%, marginal cost compresses toward product cost, and delivery gross margin climbs from 30% toward 60%; at Vendor B, gross margin is locked below 30% by labor cost, and team size has to grow linearly with customer count.
Year three, Vendor A's output per person is more than double Vendor B's, and services added at renewal for existing customers cost almost nothing to deliver; Vendor B's three most senior engineers burn out and quit — the four customers they'd been carrying each need two new engineers to spend half a year finding their footing again.
The specific numbers above aren't real, but the mechanism behind the fork is: gross margin climbing from the 20–30% of the pure-labor phase to above 60% once platform reuse kicks in — "an FDE business whose margin doesn't climb is a consulting firm."2
VI. Build, Buy, or Blend
With the ledger settled, it comes down to a decision. A manager facing "should we have our own FDEs" is really choosing among three options.1
Build: fits when your differentiation lives in delivery (in your market, deep deployment is part of the product) and leadership accepts ugly metrics for the first year or two. Failure mode: a boundary-less team becomes a breeding ground for hero culture (Section III of this chapter), or you push ahead before platform capability has taken shape.
Buy: procure forward-deployed capability from an outside vendor, project by project. Fits when demand is intermittent and the scenario isn't core. Failure mode: knowledge never accumulates inside your own organization, and the second project is bought again from zero (none of the three exit conditions from Chapter 17 are present).
Blend: build for core scenarios, outsource for peak demand. This fits the widest range of conditions, but its failure mode is also the most hidden: the in-house team slowly gets "spoiled" by outsourcing and hollows out. The test is whether the in-house team keeps holding on to the hardest customers.
None of the three options is better or worse — the only question is fit with the big ledger. The one wrong option is the fourth one: hiring without ever having done the math (see Figure 19-3).
Figure 19-3: Choosing build, buy, or blend isn't a matter of preference — it's a matter of the problem, reusability, and the responsibility you can carry.
VII. Don't Do This at Home
Last is McGrew's warning-off: his first, second, and third pieces of advice are the same sentence — don't do this at home.3 The weight of that line comes from who's saying it: the most successful practitioner to carry this model from Palantir to OpenAI is the one delivering the loudest warning in the room.
Put that line back inside this chapter's frame, and it turns out to be the last test of "big-ledger thinking": working the big ledger might, in the end, produce the answer "don't do this." That's not a failure — it's the most valuable output the ledger can give. Every company that wants to do FDE should first ask itself whether it can live with that answer; a company that can't bring itself to ask is probably already in the hole.
The big ledger settles the structure, but a finer-grained ledger is still waiting: for each individual contract, how does the money actually get collected? The next chapter takes up how to charge for it.