Founding FDE at Glean: why the job ad asks for 0-to-1 experience, not just deployment
In this role, what you build for a customer goes into Glean's product. Engineers who are used to installing an existing product will struggle to get through the screen.
In brief
- Glean's job ad states plainly that the Founding FDE's main job is to create products from zero to one, and that what the engineer builds will go into Glean's product.
- Thomas Otter points out that FDEs billed to the customer serve the project, not the product. Glean has chosen the opposite model.
- To apply, you need evidence that you have built production software yourself while requirements were still vague. Being good at deployment is not enough.
“Your primary job is to create products from 0 to 1.” That line comes from Glean’s job ad for a Founding Forward Deployed Engineer, and it puts the weight on creating products rather than just deploying what already exists.
A later line in the ad is clearer still: what you build will go into Glean’s product. The person in this role is therefore more than an extension of the product team. They sit at the source of the roadmap.
This matters because the FDE title is being used very loosely. Thomas Otter warns in his writing on the profession that many FDE roles are really deployment or pre-sales with a new label.
Glean’s ad shows what a “real” FDE role tests for, and why experience installing an existing product, however well done, is not enough to get through the screen.
Why good deployment is not enough
In a deployment role the product already exists. The question is how to make it work in the customer’s environment. Glean’s ad assigns a different task: find the biggest unsolved business problems at its most strategic customers. At that point there is no product to install.
That is why the ad sets one core requirement: you have built production software from scratch in an ambiguous environment. The key word is “ambiguous”.
A deployment engineer works from an existing specification. A 0-to-1 engineer has to write that specification, often after a few conversations in which the customer has not yet put into words what it needs.
Otter describes exactly this kind of work. In his view, FDEs suit work where the scope is uncertain, when you are building something nobody has built before.
Otter’s test: project or product?
Otter also offers a short test: if FDEs are billed to the customer, they work for the project, not the product. The reason is easy to see. When the customer pays for an engineer’s time, both sides are motivated to deliver exactly what the contract says, and nobody has a reason to turn the solution into something reusable.
Glean has chosen the opposite. The line “what you build will go into Glean’s product” is a commitment about its operating model, not just recruiting copy. Underdog, in its 2026 career guide, describes the same idea: FDEs turn chaos on the customer side into product knowledge the company can reuse.
Put Glean’s ad next to Otter’s warning and you get a table for examining any FDE job ad:
| Aspect | Deployment role labelled FDE | Glean-style Founding FDE |
|---|---|---|
| Starting point | An existing product that needs installing and running | A business problem nobody has solved |
| Output | A finished project for one customer | Software that then goes into the core product |
| Who pays for the time | Usually the customer, per project | The company, because the results feed the roadmap |
| Experience to prove | Configuration, integration, support | Building production systems from scratch when requirements are vague |
| Who you work with | Support and sales teams | A Forward Deployed PM, C-level executives |
The left-hand column is not less valuable work. It is simply a different job, needing a different CV and leading to a different career path.
Picture a week at a customer
Suppose the strategic customer is an insurer whose legal team spends hours every week hunting for clauses in contracts. A deployment engineer will ask: which storage systems should we connect to, and how should permissions work? Those are the right questions, but they start from the product.
A Founding FDE asks about the business first: which decision is being delayed, what the company loses from the delay, and who signs off. The real problem may not be search at all, but comparing new contracts against the standard template.
The engineer then builds a small agent, writes an eval suite from the legal team’s real cases, and puts it into production only when the eval scores are reliable enough.
The final step is what separates the two roles: reworking the solution so a second and third customer can use it too. Under Glean’s model, that is the moment something built for one customer becomes a feature of the whole product.
A pod, a seat next to leadership, and a lot of flights
Glean’s ad, posted on General Catalyst’s jobs board, says the role works in a pod with a Forward Deployed PM and acts as technical partner to the customer’s C-level executives.
That structure says a lot. Having a PM alongside means the engineer does not carry all of the product-shaping alone, but they still have to argue as an equal about what to build.
The ad also asks you to work with the autonomy and accountability of a founder. In practice, nobody hands you tickets. You choose the problem, and you own the consequences if you choose wrong.
There is a concrete personal cost as well: the role requires 25–50% travel. If your family situation does not allow that, know it before you enter the interview process. Do not leave the question until you have an offer.
The AI part is not decoration
The ad’s minimum is more than four years in technical roles with a track record of shipping software to production. But it also names a specific area of experience: agent development, evaluation frameworks and deployment at scale.
These three belong together for a reason. Anyone can build a demo agent in a week at a customer. What separates a real 0-to-1 engineer from a demo builder is evals: do you know when an agent is good enough for production, and can you prove it to the customer’s leadership?
So if you are moving across from backend or data engineering, do not stop at learning how to call a model’s API. Learn how to write eval suites from real data and how to monitor agents as traffic grows. That is what ads like this one are testing.
How do you prove 0-to-1 on paper?
Most engineering CVs read like a list of technologies and systems worked on. For a role like Founding FDE at Glean, that format hides exactly what the recruiter needs to see.
They are not asking whether you know Kubernetes. They are asking whether you have ever started from a problem with no solution and finished with software that real people use.
Write up each important project in four beats: the business problem, where things were ambiguous at the start, what you built yourself, and where it was reused afterwards. The last beat is the one most people skip, yet it is the one that answers Otter’s question: did you work for the project or for the product?
When reading job ads, run the test in reverse. If an ad only talks about configuration, onboarding and demo support, it is a deployment role, whatever the title says.
If it talks about building from scratch, about the roadmap and about working with customer leadership, you are looking at a product role, and you need your 0-to-1 story ready.
The word “Founding” in the title sounds like an honorific. Read Glean’s ad closely and it turns out to be an interview question: have you ever created something that did not exist before, when nobody could tell you what it should look like?
Was this article useful?
Thanks for the feedback!