Foraging: Paved With Good Intentions
Forward-deployed engineers are not an alternative to a platform. They are only survivable on top of one.
Every argument about forward-deployed engineers is an argument about the platform underneath them, and almost nobody says so out loud.
Palantir has been the exhibit for two decades. The mainstream view was that it was a glorified consultancy wearing a technology company’s valuation. Joe Lonsdale, one of its cofounders, has written that the criticism rested on a true observation. A lot of their engineers did spend a lot of their time sitting with customers.
Their CTO, Shyam Sankar, had a one-line answer he repeated for years. FDEs eat pain and excrete product.
I should be transparent that this is the problem space I work on at Typeface, and we are early into our own version of it. So I have a stake in how this resolves. What makes Sankar’s line worth keeping is that it is conditional. It only describes a company that has somewhere to put the pain. Take away the second half and you have a consultancy with better engineers, which is exactly what everyone thought Palantir was.
The Headline and the Article
This week the argument came back with a number attached. Newcomer published “Decagon Hit $100 Million Betting Against Forward Deployed Engineers”, and it moved the way contrarian things move: on Jesse Zhang’s own post it drew 843 likes against 1,300 bookmarks. People filed it faster than they endorsed it.
Then you read what Zhang actually wrote, which is not a rebuttal of forward deployment at all. His closing instruction is “go forward-deployed early. Get the signal. Put your engineers in front of customers forever.” Earlier he is more emphatic: “So yes, send engineers. Sit in the room. Watch your thing break in ways your tests never imagined.”
His actual argument is about a different verb. “The trap is not starting. It’s not stopping.” Once you know what the user journeys are, he says, you should start taking the FDEs out. You will not want to. His reason: “not because anyone makes a bad decision, but because keeping them around is easier in every single sprint.”
That is a much better argument than the headline it arrived under, and it lands where Palantir landed, restated by someone selling against Palantir’s imitators.
The Conversion Rate
Here is the mechanism Zhang traces, and it is the part I would put on a wall.
Palantir’s early Gotham deployments were deeply bespoke, each one built to answer a single intelligence question for a single unit. What Palantir did next is the whole trick: they encoded the problems they kept seeing as platform primitives. The ontology, object models, permissioning, workflow engines, provenance tracking. Those primitives became Foundry, Foundry became the thing you could sell commercially, and Apollo and AIP followed the same path.
As that matured, standardized deployments cut the need for custom work and gross margins climbed into the eighties. Many of the FDEs migrated into core engineering. They famously turned down contracts where the customer wanted Accenture with better software.
The sentence that should have been the headline is Zhang’s own: “The pain was the input to the product, not a cost of sale.”
That only works if something on the other side can receive the input. This is the condition nobody argues about because it sounds like plumbing, and it decides the economics. Forward deployment on top of an extensible platform compounds, because what the deployment team learns has somewhere to go. Forward deployment without one accumulates.
Watch what happens in the second case. Every customer gets a snowflake. Every snowflake needs maintenance. The cost of that does not arrive as a line item. It arrives eighteen months later as a codebase nobody wants to touch and a customer who cannot change anything without opening a ticket.
A customer of Sierra’s, quoted in the Newcomer piece, described that end state as a black box. Any new journey meant going through forward-deployed engineers who kept getting staffed onto someone else. After switching to Decagon, the same customer’s own non-technical staff stood up seven new journeys in about a month.
Worth knowing where that account comes from: a competitor’s article, quoting a customer that competitor won. I keep it because the mechanism it describes is the one everything else here predicts, not because of who is telling it.
Zhang has a sentence for the standard this implies, and it is the one I would hold a roadmap against. Each deployment should make the next one easier.
The Trap Is Not Starting
The reason this is hard is that the failure feels good while it is happening.
Zhang is precise about why, and the precision is the useful part. Keeping the FDEs lets you avoid every hard product tradeoff. You never have to decide what the product does, or which of two customer requests wins, or where the configuration surface ends.
Nobody has to say no to anyone. No painful architectural call gets made. The customer is delighted, this sprint, every sprint.
What you have bought at that point is every drawback of the model and none of the discovery benefit. Cost to serve stops declining. Margins stay capped. Growth becomes bounded by hiring. And, in the line that should sting, every bespoke fix in the field is a product decision you chose not to make.
Zhang separates two jobs that look the same from outside. Both put an engineer at a customer site writing customer-specific code.
Building an integration into their ticketing system is one job. Somebody already decided what should exist and you are making it exist. Sitting in the room to find out what the product should be is the other. Nobody knows yet, and what you carry back is the answer.
The first is implementation. It has to happen, and it ends when the ticket closes. The second is discovery, and it ends with something in the product.
Give both the same title and a growing services team stops looking like a rising cost of sale. It starts looking like investment. Zhang’s line: “Bundling the two under one title is how companies convince themselves a growing services org is a product investment.”
Note the verb. Convince themselves. Nobody has to be lying for a company to end up believing this.
The exception is worth naming, because the rule as stated is too clean. Some deployments never graduate, and should not. A regulated environment with a data model that exists nowhere else, a segment where the remaining work is irreducible: those are real, and pretending otherwise is its own kind of dishonesty.
What I would insist on is that every gravel road gets a graduation path attached the day it is built. Deciding not to pave one should happen out loud, with a reason, by someone who could have decided otherwise. The failure mode is the exception nobody declared, taken a hundred times by default.
Nikesh Arora puts the buyer’s version more bluntly: if a startup needs forward-deployed engineers to sell into the enterprise, the product is not finished. His test is whether the engineer’s work folds back into the product. Anu Bharadwaj’s write-up of an ICONIQ panel turned it into something you can read off an org chart.
At Anthropic the role reports into go-to-market. At Ramp it sits inside engineering and contributes directly to product code. Ramp’s placement is what passing the test looks like structurally.
Gravel Roads and Highways
So the real question is what you pair them with, and who has standing to say no.
What we are trying at Typeface is FDE squads alongside platform squads. The FDE squads build gravel roads: get to a customer outcome by whatever path works, fast, and own whether that customer succeeds. The platform squads come behind and turn the roads worth keeping into highways, and they own repeatability and scale.
I should be careful about how much I claim here, because we are at the start of this. It is a bet we have placed, not a result we have. Ask me in two quarters whether the platform squad had the standing to refuse anything, or whether it quietly turned into a backlog for whatever the FDE squads shipped last.
The reasoning behind the bet is the part I will defend. An FDE squad optimizing for one customer will always make choices a platform team would not. That is fine. The point of a gravel road is to find out where the traffic goes before anyone pours concrete.
Rough roads are the expected output. The failure is leaving them rough, letting the count grow, and waking up with a hundred private routes and no network.
Which is why I think the two have to be staffed as a pair rather than as a sequence. If the platform squad is a promise about next quarter, the gravel roads harden into permanent infrastructure and you have quietly become a services company carrying a software multiple. If it exists and is allowed to refuse things, forward deployment becomes product research you cannot buy any other way. Real customers, real logic, real edge cases, found by people whose job is to make it work rather than to make it general.
After I had written that down, I went back and looked at the illustration at the top of Zhang’s article. It is two figures standing where a dirt track turns into a paved road with a painted centre line. We arrived at the same picture independently, which is usually a sign the metaphor is carrying an argument rather than decorating one.
The Odd Find (Or Is It?)
Heinz has released a ketchup lid with a dose selector on it. Three settings: Like, Love, and Crazy Love.
It went out on August 10, a limited run in the US and UK, and the stated origin is years of people arguing online about the correct amount of ketchup per portion. Nick Tran’s read is the one I would keep: Heinz is unusually good at leaving the formulation alone and doing the work in the packaging. The Dipper fry box was the same move, and it went to eleven countries.
The part the coverage skips is that the Love Lid is an accessory bundled with a bottle, not a change to the bottle anyone buys. Kraft Heinz did not innovate on ketchup. They innovated on the argument about ketchup.
This is Sankar’s line loose in a condiment aisle. The pain belonged to customers, Heinz went and ate it, and what came back out was a lid. The formulation never moved, and the formulation is the platform. Then the part that matters: they knew which one to pave. The Dipper earned eleven countries, the Love Lid stayed a limited run, and nobody pretended otherwise.
The argument itself is a year old. Tal Hoffman, replying under Zhang’s post, quoted himself from September 2025: “to FDE, or not to FDE: that is the question, AI startup founders, 2025.” His comment was “*2026 apparently.”
It keeps recurring because the headline version is unanswerable and the real version is uncomfortable. Nobody can tell you whether to have forward-deployed engineers. What they can ask is what got built into the product the last time one of them came back, and most teams do not like the answer enough to go looking twice.