From FDE to founder: which habits carry over and which must be relearned

In June 2025 Garry Tan, chief executive of Y Combinator, advised founders to think of themselves as “forward-deployed engineers”. In other words, YC is holding up the work of the engineer embedded with the customer as a model for the startup founder.

That advice raises the opposite question, and for many engineers it is the more practical one: if founders should work like FDEs, will a few years as an FDE turn you into a founder?

The short answer is: only halfway. What transfers is how to find a problem worth solving. What does not transfer on its own is how to turn a solution for one customer into a business with leverage. If you are weighing an FDE role as a stepping stone to starting a company, the second part is what you need to practise deliberately.

The founder factory is real, but the evidence is thinner than the legend

The story that “Palantir is a founder factory” has some basis. An analysis by the fund Concept VC of founders who came out of Palantir found that FDE was the most common background. Named examples include Quinn Slack, co-founder of Sourcegraph and a former FDE at Palantir.

But the authors themselves concede that their sample is not rigorous, may be incomplete, and that Palantir job titles are inconsistent. Mati Staniszewski of ElevenLabs is described on that page as an FDE in one place and a Deployment Strategist in another.

Nabeel Qureshi, who worked as an FDE at Palantir for about eight years, was the guest on an episode of the podcast on Lenny’s Newsletter whose title calls Palantir a “founder factory”.

The episode notes say that nearly a third of Palantir’s PMs went on to start companies. Note that this refers to PMs, not FDEs, and that it is a summary line on the page rather than his own words.

Concept VC also leaves an important question open: it is unclear whether this flow of founders will continue as Palantir hires aggressively over the next few years. A role filled in bulk struggles to keep the quality of experience it offered when it was rare.

So the title by itself does not produce founders. What produces them is a specific set of habits that FDE work forces you to practise.

What carries over: discovery one customer at a time

PostHog identifies the core difference: an FDE does product discovery and product development with one customer at a time, unlike a typical software engineer.

That is exactly the job of an early-stage founder. YC partners describe the tactic in concrete terms: at the second meeting, the person on the customer side should see a demo you built from what they told you at the first.

The fund CRV also argues that the FDE role is strongest during the search for product-market fit, and that at that stage the founders and core team should do the on-site work themselves.

Imagine you are an FDE at a logistics company. At the first meeting, a warehouse manager complains that every morning goes on an hour of reconciling orders between two systems. A week later you come back with a reconciliation script running on their real data. It has no interface; it simply prints a list of mismatched orders.

The second meeting then takes a different turn. Instead of describing the problem in general terms, they point at individual lines: this one is right, that one is wrong because of a rule you did not know about. You have just learned more than three customer interviews combined would have taught you.

Gyani, a former Palantir engineer turned AI founder, names the accompanying habit: always build the smaller version of the problem first, because you can always expand later. Pratap Ranade, another Palantir alumnus, adds the market logic: solving one problem gets you invited into the next.

In the example above, the reconciliation script is the ticket that gets the warehouse manager talking about vehicle dispatch. Ranade sums it up in one line: good products are ultimately built in the field. These three habits, listening on site, demoing fast and shipping small to be handed bigger problems, carry over to the founder role almost intact.

What does not carry over on its own: leverage

Qureshi describes Palantir’s core model as solving a very large, very valuable problem for one customer, then abstracting that solution into a product. The sentence has two halves. As an FDE at a large company, you mostly practise the first.

The second is usually someone else’s job. The fund Flybridge describes the division of labour: FDEs bring patterns from the field back to HQ, where the product team packages them into reusable features for other customers. When you start your own company, there is no HQ to receive those patterns. There is only you.

What happens if you skip the second half? Flybridge warns that the FDE model is profitable only with leverage, meaning high-value contracts and reusable insight. Without those two things, a company slides into a labour-intensive, unscalable, low-margin model.

Go back to the logistics example and suppose you have quit to go out on your own. The first customer needs the reconciliation script, the second needs it adapted to a different data format, the third needs a new rule added. If you rewrite most of the code every time, you are selling hours, not a product.

The founder’s question is which parts of those three jobs are the same. Only when you can extract that part into something a fourth customer can install in a day do you have leverage.

PostHog adds a blunt condition: the point of an FDE strategy is to win the right to solve bigger problems. If the standard product-market fit playbook already works, you should not use FDEs. Founders from an FDE background are prone to the opposite mistake: sitting with customers by reflex even when the market is ready to buy a self-serve product.

Two columns in the same experience

Put these perspectives together and the same FDE experience splits into two distinct parts:

Capability	FDE role at a large company	When you are the founder
On-site discovery	Practised daily with one customer	Transfers directly, and you must do it yourself rather than delegate it
Demo from the previous meeting	A way to win more scope	A way to close deals fast
Ship small, expand gradually	A delivery habit	Transfers directly, becoming a land-and-expand strategy
Abstracting into a product	Handled by the product team at HQ	Your own job, with no one to take it over
Economics of the model	Carried by the parent company	Without leverage, you become a low-margin services company
Knowing when not to sit with the customer	Rarely needs deciding	Must be decided early, depending on whether the PMF playbook already works

The first three rows are capital you take with you. The last three are what you must practise in addition, the sooner the better.

What engineers should build up now

If starting a company is a long-term goal, choose FDE jobs by the right-hand column, not just by title.

When reading a job description, look for wording that shows FDEs feed back to the product team or write shared code themselves, not just “integrate and support customers”. A role that lets you do only the first half will teach you a services trade, not a founder’s trade.

In daily work, get into the habit of logging whether each customer request is specific to one customer or needed by several. After a few months, that list is a draft product roadmap, and it is the abstraction exercise Qureshi treats as the core of the model.

On your CV, do not just write that you “deployed solutions for customer X”. Tell the full loop: one customer’s problem, the small version you shipped, and which part of it was later reused for other customers. A recruiter or investor reading that line will see that you have covered both halves.

Garry Tan’s advice is valuable precisely because it describes a way of working, not a job title. If you have worked as an FDE without ever having to answer “how long would it take the fourth customer to install this?”, you have learned only half of the founder’s trade.