What breaks when a forward deployed engineering team scales?

THE SHORT ANSWER

Five things, in the order they usually show up. The handback stops being read, because one product manager can read ten packets a year and nobody reads two hundred. The engineers end up on islands, because the manager and tech lead layer arrives late. The maintenance tail eats the team, because shipped workflows stay attached to whoever shipped them, and in Milos Mandic's State of FDE 2026 survey twelve of 24 FDEs already spend more than a tenth of their week on delivered systems. The reporting line fragments, because a new region gets stood up under sales. And the bench appears, because the plan was written in headcount and demand arrives in deployments. Palantir's Q3 2026 call, where Alex Karp said the company cannot satiate demand and has to re-resource because it lacks the bandwidth, shows the alternative: 686 US commercial customers, revenue per customer up 88 percent, pilots converting at 5x to 15x, contracts starting at $25 million, and a platform that keeps what the engineers built. An FDE org scales by needing fewer engineers per deployment, not by hiring the hundredth.

The FDE org at 100 is where every shortcut taken at 10 comes due, and the shortcuts all have the same shape: a person was doing what should have been a system. One PM read the packets. One senior engineer mentored the rest. One FDE maintained what one FDE shipped. The hundredth hire is where the person runs out.

Palantir's call is the week's evidence that even the inventor doesn't scale by headcount. Karp's answer to not having the bandwidth was bootcamps, $25 million starting contracts, and a platform that keeps the work. Not a req.

Part 14 of The FDE Transition walks the five failures and what to count instead: What Breaks in the FDE Org at 100. The handbook chapter on building the FDE team has the four decisions that decide whether the team exists in a year.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-11-04 · 1 min read