On 30 June, AWS announced a dedicated Forward Deployed Engineering organisation backed by $1 billion, staffed in the thousands, sending pods of five or six engineers into customer environments on 45-day cycles. On 2 July, Microsoft went bigger: $2.5 billion for a new operating business called Frontier Company, embedding 6,000 industry and engineering experts at customers, with $1.2 billion of that earmarked for headcount alone.

That capped a six-week stretch in which OpenAI stood up a deployment organisation with TPG, Advent, Bain Capital and Brookfield behind it at a $4 billion valuation, and Anthropic formed a $1.5 billion services venture with Blackstone, Hellman & Friedman and Goldman Sachs.

A year ago, when I moved into this role, forward deployed engineering was barely known outside Palantir. Explaining my job at a birthday party took a while. Today, four of the largest technology companies in the world have put roughly $5 billion of committed capital behind it in six weeks, with OpenAI’s deployment company valued at another $4 billion on top. Gartner projects that 85% of tech providers will have an FDE programme as a core AI delivery model by the end of this year.

The demand side of this market is now settled. The supply side is the question nobody has answered.

Run the numbers

Microsoft wants 6,000 people embedded at customers. AWS says thousands. Salesforce has reportedly committed to hiring 1,000 FDEs. Postings on Indeed went from 643 in April 2025 to 5,330 in April 2026. The consultancies have piled in too: by one tracker’s count, Deloitte, Accenture, KPMG and BCG together post more FDE roles than any single product company except Google.

Set that against the existing pool.

When I analysed close to 2,000 FDE practitioner profiles for the State of FDE report, one pattern was unmistakable. The population of people with real years in this role is small, and it is overwhelmingly Palantir-shaped. The company had a decade-long head start, and until recently it was more or less the only place you could accumulate this specific kind of experience.

Where are those people now? The evidence here is anecdotal, but it lines up with what leaders in the space keep telling me. The practitioners with genuine depth, meaning multiple deployments across multiple environments and the scar tissue to prove it, mostly fall into two groups: they are already inside the companies that moved early, or they have gone independent and run their own shops. Not every experienced FDE is spoken for. But if your plan requires hiring a thousand of them this year, the maths does not work.

Experience in this role accumulates one deployment at a time. Demand grows by press release.

Manufacturing the role

So companies will do what companies always do when a labour market runs dry. They will manufacture the workers.

That happens in three ways, and all three are already visible.

The first is relabelling. Solutions architects, sales engineers and implementation consultants are being rebadged as FDEs, sometimes with the job description barely touched. The consultancy posting numbers are the clearest evidence. A firm that posts dozens of FDE roles in a quarter did not suddenly discover forward deployment. It renamed a practice it already had.

The second is retraining. This is where the big money goes. Microsoft’s $1.2 billion headcount budget explicitly includes AI-readiness training for existing staff, and the unit will be staffed primarily by people already inside the company. AWS says it will fill roles through a mix of external hiring and internal moves, which lands differently when you remember Amazon has cut more than 30,000 corporate jobs since October. A meaningful share of the new FDE workforce will be existing employees walked across an internal bridge.

The third is new pipelines. Companies in the training business will spin up FDE cohorts and certifications the same way they did for cloud, for data science, and for prompt engineering. Give it a year and there will be a certificate for this.

None of this is scandalous. Every discipline that grows this fast industrialises its own production, and Palantir itself never waited for experienced FDEs to appear. It hired sharp graduates and built them, and Priya Khandelwal made the case convincingly when we spoke about why new grads make great FDEs. Trainability is not the problem.

The problem is definitional. When a 6,000-person Microsoft unit, a Deloitte bench and a rebadged solutions architect all carry the same title, the title stops carrying information. Vlad Shulman warned about exactly this in our conversation earlier this year: once the term detethers from the original intent, candidates self-select against the label, employers hire against the label, and everyone ends up sailing wherever the wind blows.

Worth naming, too, what the industrialised version actually looks like. A pod of five engineers on a 45-day clock is a different animal from an engineer embedded in one customer for a year. The first optimises for repeatable delivery. The second optimises for learning, the thing that made the role valuable to product companies in the first place. Microsoft seems to understand the distinction, because its own announcement pointedly distanced the effort from the FDE label. At some scale, the honest description of what the hyperscalers are building is consulting with better tooling. That is a fine business. It is just not the same job.

The self-serve objection

There is a longer-term question sitting underneath the hiring one, and it deserves a straight answer.

The case against the role’s durability goes like this. FDEs exist to close the gap between a general product and a specific environment. Every deployment teaches the product something. The product absorbs the lessons, becomes more self-serve, and the gap the FDE was hired to close disappears. The role designs itself out of a job.

Per product, that is exactly right. It is also the point. The FDE who makes a product self-serve has done the job well, and the reward for doing the job well is that this particular gap no longer needs them.

Per economy, the logic inverts. Gaps are not a fixed quantity that gets worked down to zero. Every new capability that ships creates a new frontier of environments it does not yet fit, and the practitioners who closed the last gap move to the next one. The role is self-terminating per product and permanent in aggregate. That has been the pattern for every implementation discipline before this one, and nothing about AI suggests it breaks here.

If anything, the coming years look like they will add a category of work rather than remove one. The same Gartner analysts projecting 85% adoption of FDE programmes also project that 70% of enterprises will abandon agentic AI projects born from FDE-led engagements within two years. Read one way, that is an indictment of the whole model. Read another, it is a forecast of the workload. Thousands of systems are about to be built at speed, by pods on 45-day clocks, handed over, and left to drift as models change and upstream systems move underneath them. Somebody will have to go back in. The remediation wave has not started yet, and it will need people who understand why the first deployment decayed.

Which version survives

The question I keep turning over is not whether the role survives. Between the capital committed, the posting curves and even the abandonment forecasts, its survival looks assured for the foreseeable future.

The question is which version of it survives, and whether the word still means anything once the money has been spent. Take the original Palantir model: one engineer, embedded deeply in a single customer, feeding everything they learn back into the product. That version is scarce and slow to develop. The second version is the industrial one now taking shape at the hyperscalers, pods of five or six on 45-day clocks, built for repeatable delivery at volume. It is about to outnumber the original many times over.

There is a third version too, and it is the one I know from the inside: a single practitioner spread across ten or more clients at once, spanning logistics, insurance, finance, manufacturing and wholesale. It trades the depth of the year-long embed for a breadth nobody inside a single vendor gets to see. The same failure modes repeat across industries that have never spoken to each other, and recognising them early is the entire value. This version appears in nobody’s hiring plan, because it cannot be hired in bulk. It gets built one practitioner at a time, and increasingly it operates independently.

All of it will get called FDE. Only the first is what the term was coined for.

A year ago, almost nobody knew what a forward deployed engineer was. A year from now, everybody will have an opinion, and I suspect very few of those opinions will describe the same job.

It is the kind of brief that sounds like ambition and works like a trap. There is no version of that sentence an FDE can deliver, because there is no point at which it is finished. You could spend three years inside that mandate and still not be able to say the thing is done, because nobody defined what done would look like before you started.

Compare it to a real outcome. Get the time to process an exception down from two days to twenty minutes. Take a workflow that currently needs three people reviewing every case and get it to one person reviewing only the cases that genuinely need a human. Those have an end. You can stand in front of them and know whether you got there.

The difference matters more than it looks, because the FDE’s only reliable instrument for knowing they have finished is a feeling. And that feeling only works if the finish line was drawn in advance.

The loop

The work has a shape, and it repeats.

You arrive knowing almost nothing about the customer. Sometimes not much about the domain either, though that part is less important. The first weeks go into getting deep enough into how their operations actually run to find the highest-value problem you can solve, the one where the cost is real rather than just annoying. Then everything narrows onto solving it.

That stretch is intense and fast and completely absorbing. You are learning a business from the inside and building the thing that changes it at the same time, and there is nothing else like it.

And then you get there. The outcome lands. The numbers move. The people who were sceptical start using it without being asked.

And you deflate like a balloon.

There is a version of the next few months where you stay. You hold the account, you answer the questions, you make small incremental improvements, you sit in the standups. You can do this. Plenty of FDEs do. But it is not the work that pulled you into the role, and the flatness you feel is not a character defect to manage. It is information.

The case for moving on

Naval Ravikant has talked about getting bored easily, the pattern of finding a challenge, getting good enough at it, and then needing the next one. He landed on angel investing partly because it suited that wiring. The FDE role runs on the same engine. The appetite for a problem you do not yet understand is what makes you good at the front of an engagement, and it is the same appetite that makes the maintenance phase feel like wearing someone else’s coat.

This connects to something I have argued before, that FDE teams are an investment in discovery rather than a services business. If that is true, then an FDE’s time is close to the most expensive research budget the company has. Spending it on steady-state maintenance is less an act of loyalty to the customer than a misallocation of the one resource that exists to find the next thing worth building. The boredom is that budget objecting to being parked.

The case for moving an FDE on is not really about keeping them entertained. It is that every new engagement is another source of product input, and those inputs are the whole point. A new problem, a new operation, a new set of edge cases, that is where the patterns worth building into the product actually surface. The more times an FDE goes through the loop, the more of that signal they generate. Leave them on one account refining what already works and the stream slows to nothing. You are paying a discovery cost and getting maintenance in return.

Where the work actually ends

So where does the FDE’s job end.

Not at the demo. I want to be careful here, because it would be convenient to claim the work finishes the moment the solution technically functions and the boring part belongs to someone else. It does not. Adoption is the FDE’s job. Earning the trust that gets people to route their real work through the thing is the job, and it takes longer than the build and it is rarely fun. An outcome nobody uses is not an achieved outcome.

What is not the FDE’s job is everything after that. Maintenance. The steady-state support, the small fixes, the questions that have settled answers now. That should sit with a separate team, the way it did before we started blurring these lines, or increasingly with an agent that can absorb the long tail of small requests. The FDE got the customer to the outcome and made it stick. Keeping it running is genuinely different work, and it does not need the most expensive person in the building.

None of this is a prohibition. You can keep the FDE on the account. You can take the open-ended mandate and bill against it month after month. There is nothing wrong with any of that, and for some companies it is exactly the right business to be in. But it is a services business, and the honest thing is to call it one. The problem is never that an organisation does support work. The problem is an organisation doing support work while telling itself, and its investors, that it runs an FDE team. Once that happens the label stops meaning anything, and you lose the one thing the model was meant to buy you, which is discovery.

Worth saying that moving on does not have to mean leaving the customer. The next challenge is often inside the same organisation, a different process, a different outcome, a fresh problem worth the immersion. What it cannot be is the same solution on a drip.

Telling the difference

The danger in all of this becomes obvious the moment you say it out loud. Boredom is not a precise instrument. It can show up early, before the outcome is actually achieved, before any trust has been built, at exactly the point where the unglamorous adoption work begins. Following it then is not discipline. It is abandonment dressed up as temperament. The hard part is telling the two apart, knowing whether you have gone flat because the defined outcome is genuinely behind you, or because the fun part is over and the patient part has started. The first is a signal to move. The second is a signal to stay.

Which is why the defined outcome carries so much weight. It is the only thing that lets you trust the feeling at all. If you agreed up front what done looks like, and adoption was part of that picture, then the deflation afterwards is real data. If you never defined it, the boredom has nowhere honest to point, and you will either drift into permanent support or leave too early and call it instinct.

So the vague brief turns out to be the actual enemy. “Make us AI-native” does more than waste time. It removes the FDE’s ability to know when they are done, and a role that runs on knowing when you are done struggles to function without that line.

There is a simple test in all of this, for an FDE and for whoever runs the team. Look at the gap between an outcome landing and the FDE rotating onto the next defined problem. It should be short relative to how long the outcome took to reach. If they move on quickly, the model is working. If they are still on the same account a long stretch later, making small improvements, one of two things is true. Either the outcome was never defined, so nobody can tell it has been reached. Or it was reached, and the team has quietly become a services business that happens to use the word FDE.

Neither is fatal, and both are worth knowing. The deflation that follows a delivered outcome is the cheapest diagnostic you have for telling which one you are living in.

So the question is not really whether FDEs get bored. It is what your organisation does when they do.

The argument underneath it is one I keep circling in my own writing. The moment a demo works is the moment everything looks solved, and it tends to be the most dangerous point in the whole project, because the jump from “works when I drive it” to “works when real users do” isn’t a matter of polish. It’s a different problem entirely, and evals are how you bridge it. I’ve written before about the unknown unknowns problem, how the hardest part of this work is knowing when a system is quietly wrong. What follows is the disciplined engineering answer to exactly that. It goes deeper into the mechanics than my usual essays, the metrics and the tooling and the gate thresholds, and if you’re not the one wiring up the harness you can skim those and still take the shape of it. The shape is the point. Over to Kranthi.

There’s a moment in every AI project where the demo works. The retrieval is pulling relevant chunks, the model is generating coherent answers, and the stakeholders are nodding. This moment is dangerous.

It’s dangerous because the gap between “works in a demo” and “works in production” is not a linear improvement problem. It’s a category shift. In a demo, you control the inputs, you cherry-pick the questions, and you evaluate by gut feel. In production, real users ask unpredictable questions against messy data, and you evaluate by numbers you’ve committed to in advance.

The eval lifecycle is the structured process that bridges this gap. OpenAI’s enterprise whitepaper sketches it in a single table. Let’s build the full architecture.

Stage 1: Retrieval Evaluation

Retrieval Evals

Each stage has its own metrics, its own evaluation set, and its own continue/refine/stop gate. The lifecycle repeats at MVP, pilot, and production scale — with the evaluation set roughly doubling at each stage.

The question: Does the system reliably find the right information?

This is where most AI products fail first — not because retrieval is hard to build, but because retrieval is hard to evaluate well. A retrieval system that returns plausible results will pass casual inspection. A retrieval system that returns the right results for edge cases is what separates a demo from a product.

What you’re measuring:

Recall — of all the documents that should have been retrieved, what fraction did the system actually find? Low recall means the system is missing relevant information. For a Q&A agent over company docs, this might mean missing the updated policy while retrieving the obsolete one.

Precision — of all the documents retrieved, what fraction are actually relevant? Low precision means the model’s context window is polluted with irrelevant material, degrading downstream generation quality.

Mean Reciprocal Rank (MRR) — is the most relevant document appearing first, or buried in position five? Models pay more attention to what appears early in context. If your best document consistently ranks third, your answers will be worse than they should be.

How you build the evaluation set:

Start with 50-100 representative queries drawn from actual user conversations (or realistic simulations). For each query, a domain expert labels which documents should be retrieved. This labeled set becomes your retrieval ground truth.

This is tedious and irreplaceable. Automated approaches — using an LLM to judge retrieval relevance — are useful for scaling evaluations but unreliable for building the initial ground truth. The domain expert knows that “Q3 revenue guidance” should retrieve the board deck, not the press release. The LLM doesn’t know your organization well enough to make that distinction.

The gate decision:

Continue if recall ≥ 0.85 and precision ≥ 0.75 on your evaluation set. Refine if metrics are between 0.60 and 0.85 — this usually means adjusting chunking strategy, embedding model, or retrieval parameters. Stop if recall is below 0.60 — the retrieval pipeline needs fundamental rework before downstream evaluation is meaningful.

Track token costs at this stage. Retrieving too many documents burns context window space and money. Retrieving too few misses information. The right balance is specific to your use case.

Stage 2: Summarization and Grounding Evaluation

The question: Does the system synthesize clear, consistent, useful, and cited answers? Did it follow the right steps and access the right data?

This is the stage where the whitepaper’s description — “evals on traces/logs + SME review” — is most dangerously compressed. “SME review” alone can mean anything from “my colleague glanced at five outputs” to “three domain experts independently rated 200 outputs on a structured rubric.” The difference in quality assurance is enormous.

What you’re measuring:

Faithfulness — does the answer only contain claims that are supported by the retrieved context? An answer can be correct according to the model’s training data but unfaithful to the retrieved context, which means it’s hallucinating in a way that’s invisible to the user. This is the most important metric in the entire eval lifecycle and the one most teams measure poorly.

Relevance — does the answer actually address the question? A faithfully grounded answer that doesn’t answer the user’s question is useless.

Completeness — does the answer cover all the relevant information from the retrieved context? Partial answers erode trust over time even when they’re technically accurate.

Citation accuracy — if the system claims “according to document X,” is that claim actually in document X? Citation errors are trust-destroying because they’re verifiable — a user who checks a citation and finds it doesn’t match will never trust the system again.

How you build the evaluation:

For each query in your evaluation set, have domain experts write the “gold standard” answer — the response a knowledgeable human would give. Then compare model outputs against these references.

Automated faithfulness evaluation is one of the areas where LLM-as-judge approaches are genuinely useful. Have a separate model (not the one generating the answer) check whether each claim in the output is supported by the retrieved context. Tools like RAGAS, DeepEval, and TruLens provide frameworks for this, but the key insight is: use a different model for evaluation than the one generating answers. Models are unreliable judges of their own outputs.

The gate decision:

Continue if faithfulness ≥ 0.85, relevance ≥ 0.80, and citation accuracy ≥ 0.90 on a sample of 200+ queries. Refine if faithfulness is between 0.70 and 0.85 — this usually means adjusting the system prompt to enforce stricter grounding, or improving the retrieval stage to provide better context. Stop if faithfulness is below 0.70. A system that hallucinates in 30%+ of responses is not ready for any form of user testing.

Stage 3: Guardrail Evaluation

The question: Does it stay within approved data, tone, and safety guidelines?

Guardrails get treated as an afterthought in most AI projects — the safety review that happens the week before launch. That’s backwards. Guardrail failures are the ones that make the news, generate legal liability, and destroy user trust in ways that no amount of accuracy improvement can repair.

What you’re measuring:

Topic boundary compliance — does the system stay within its defined scope? A legal Q&A agent that starts offering medical advice has failed a topic boundary guardrail, even if the medical advice happens to be accurate.

Tone and brand consistency — does the system’s voice match organizational guidelines? A customer-facing agent that suddenly becomes casual or sarcastic when asked difficult questions has a tone guardrail failure.

Safety filtering — does the system refuse or redirect harmful, offensive, or manipulative inputs? This isn’t just about explicit toxicity — it includes prompt injection attempts, jailbreaking, and social engineering.

PII handling — does the system avoid exposing, generating, or echoing personally identifiable information? This is both a safety and a regulatory requirement.

How you build the evaluation:

Create an adversarial test set. This is distinct from the representative test set used in stages 1 and 2. Adversarial tests specifically probe boundaries: out-of-scope questions, prompt injection attempts, requests for information the system shouldn’t have, edge cases where tone guidance is ambiguous.

A strong adversarial test set has 100+ cases across these categories, built by people who actively try to break the system. This is one area where “red teaming” (having humans try to elicit harmful outputs) provides signal that automated evaluation cannot replicate.

The gate decision:

Continue if guardrail violation rate < 0.5% on the adversarial test set and < 0.1% on the representative test set. Refine if violations are between 0.5% and 2% — usually by tightening the system prompt, adding output filters, or restricting tool access. Stop if violation rate exceeds 2% on the adversarial set. Safety is not a gradient.

Every threshold in these three gates fits on one page: the continue, refine, and stop cutoffs, the failure signature for each gate, and the tooling for each. Download the Eval Gate Cheat Sheet

The Lifecycle Repeats at Every Scale

Here’s what the whitepaper mentions but doesn’t emphasize enough: this three-stage evaluation runs at every deployment gate, not just once.

MVP gate: Run all three stages on your evaluation set. Small scale (50-100 queries for retrieval, 200 for summarization, 100 adversarial). The goal is to validate the architecture, not achieve production quality.

Pilot gate: Re-run with production data from pilot users. The evaluation set should now include real queries you didn’t anticipate. Expand the adversarial set based on actual user behavior. Introduce latency and cost measurements — a system that takes 30 seconds per response won’t be adopted regardless of accuracy.

Production gate: Full evaluation suite plus continuous monitoring. This is where the eval lifecycle transitions from a build activity to an operational responsibility. The same metrics you used to gate deployment now become the SLOs your team monitors daily.

The whitepaper’s “once proven in a narrow scope, the same checks repeat at pilot and production scale” is correct, but it undersells the expansion that happens at each gate. Your evaluation set should roughly double at each stage. Your adversarial set should incorporate everything users tried during the previous stage. And your automated monitoring should replace the manual SME review that gates earlier stages.

The Tooling Stack

You don’t need to build this from scratch. The eval tooling ecosystem has matured significantly:

Retrieval evaluation: RAGAS and DeepEval both provide retrieval metrics out of the box. LangSmith and Arize Phoenix offer tracing that connects retrieval to downstream generation quality.

Faithfulness and grounding: RAGAS faithfulness metrics, DeepEval’s hallucination detection, and custom LLM-as-judge evaluations using structured prompts. Braintrust and HumanLoop provide platforms for managing evaluation datasets and running automated evals at scale.

Guardrails: Guardrails AI, NeMo Guardrails (NVIDIA), and Lakera Guard for safety filtering. LangFuse for observability and trace-level analysis.

End-to-end: LangSmith, Braintrust, and Arize Phoenix each provide integrated platforms that span all three stages, with tracing, evaluation, and monitoring in a single tool.

Pick one end-to-end platform and supplement with specialized tools where needed. The worst outcome is building a custom evaluation framework from scratch — you’ll spend months replicating what these tools provide on day one.

The Real Lesson

The whitepaper frames evaluation as Phase 4 — something that happens when you build products. That’s wrong. Evaluation is the connective tissue that links every phase.

Your Phase 1 data access decisions determine whether you can build a retrieval evaluation set. Your Phase 2 fluency programs determine whether you have SMEs capable of writing gold-standard answers. Your Phase 3 prioritization determines whether you’ve chosen use cases where evaluation is tractable.

The eval lifecycle isn’t a step in the process. It’s the process.

Most of the time, that is a reasonable thing to ask for, and a reasonable thing to build. Replication has a clear before and after, the value is easy to point at, and nobody has to renegotiate how the work is organised. I am not going to pretend that kind of project is beneath anyone. A lot of real value gets delivered that way, and for many problems it is exactly the right call.

But it is worth noticing what you are copying when you copy a process.

Most steps were built for people

A process is a record of the constraints that existed when it was designed. Someone could only hold so much in their head, so the work was split across three roles. Information could not move between two systems on its own, so a person was placed in the middle to carry it across. Nobody trusted the output of the first step, so a second step was added to check it. Over the years these accommodations harden into the way it works, and after long enough nobody remembers that most of them were answers to questions about human capacity rather than questions about the work itself.

The clearest version of this is almost a century old, and it is one of the most studied episodes in the history of technology. When factories first electrified, many of them simply swapped the large central steam engine for a large central electric motor and changed nothing else. The machines stayed lined up along the same shafts and belts, arranged for a building that had a single source of power in the middle. The productivity gains everyone expected did not arrive. They came later, once a generation of managers stopped treating electricity as a quieter steam engine and put a small motor on each machine, which meant the machines could finally be arranged around the flow of the work rather than the location of the engine. Economists have a name for the gap between having a technology and getting the gains from it, and electrification is the example they reach for. The power had been available for decades. The reorganisation was the hard part.

We are doing the early version of this now. We are dropping AI onto the spot where the old engine used to sit and asking why the numbers are not better.

The bigger win, and why it is rare

The projects I am proudest of are the ones where the customer gave me room to do more than replicate. The brief in those cases was larger than making a step faster. It was closer to a standing invitation: look at this end to end, and tell us which parts of it still need to be here. When that happens, the most useful answer is often that a step should not be automated at all, because it should not exist. The check that was added because the earlier step was unreliable is not needed once the earlier step is reliable. The handoff that existed to move data between two systems disappears when the same agent can read from both. You are not speeding the step up, you are removing it.

That is where the real gains live, and it is also the thing customers are slowest to allow.

I have learned not to read that reluctance as timidity. Removing a step is a far larger commitment than automating one. Automating a step leaves the shape of the work intact and gives everyone an easy way to roll back if it goes wrong. Removing a step means someone now owns the risk that the step used to cover, and it usually means crossing into another team’s territory, or touching headcount, or explaining to an auditor why a control is gone.

Some of those steps are there for reasons that are not visible from the outside. A lot of what looks like waste is scar tissue. The reconciliation, the second sign-off, the manual review that feels redundant, each one is often the residue of a specific time something went badly wrong, and the step is the organisation’s memory of it. You cannot tell from the outside whether a step is a relic of an old constraint or a guardrail protecting against a real failure. The only way to know is to understand why it was put there in the first place. That is why the room to redesign a process has to be earned rather than assumed. You get it by being right about the small things first, by showing you understand the work well enough to know which fences are safe to take down.

So the ideal and the reality sit some distance apart. In an ideal engagement, the customer hands you the whole process and the freedom to question all of it. In a real one, you start by automating the step you were asked to automate, and you earn the right to ask the larger question slowly, if you earn it at all.

The same logic, one level up

What is true of a single process is becoming true of whole companies.

A company being built now, with these tools assumed from the start, does not carry these accommodations inside it. It does not have the three roles that exist because one person could not hold it all, or the team whose entire job is to move information between systems. It is designed around what the technology can do, the way the rebuilt factories were designed around the flow of work. It has no old layout to defend.

An incumbent is the opposite. It is made almost entirely of steps that were shaped around people, accumulated over decades and defended by the teams who run them. Automating those steps one at a time makes the company faster at doing what it already does. It does not change the layout. A competitor that never had the layout in the first place can move in ways that bolting AI onto the old structure cannot match.

I want to be careful here, because the story of the AI-native upstart eating the incumbent is one that technology people have told many times, and it has disappointed at least as often as it has come true. Incumbents have things that are hard to copy: distribution, data, brand, the trust of customers who would rather not switch, and in regulated work a moat a newcomer cannot wish away. The displacement, when it comes, is usually slower and more partial than the people predicting it expect, and the incumbents that come out ahead are very often the ones that adapt, precisely because they can pair the redesign with assets a newcomer does not have.

But adapting and bolting on are not the same thing, and the distance between them is the whole story. The companies that treat this as a chance to redraw the layout will pull away from the ones that treat it as a faster engine for the layout they already have. That is less a prediction about which names survive than a prediction about which behaviour wins.

What this means if you do this work

If you build and deploy this kind of system for a living, that distance is the most important thing happening to your role, and it is worth sitting with what it implies.

Every established company now has a version of the same project in front of it, and it is not really an “add some AI” project. The harder version is this: work out which parts of how we operate were answers to old constraints, and rebuild around the parts that are left. That is an enormous amount of work, and it is exactly the kind of work that does not fit a product bought off a shelf, because the answer is different inside every organisation.

For most of corporate history, work like that meant hiring a consultancy, spinning up an internal team, or bringing in an agency, because the building itself took a lot of hands. That has changed. One engineer who is good at this, with the tools we have now, can carry what used to need a room full of people. The redesign that needs doing keeps growing while the cost of the person who can do it keeps falling, and that is usually what a wave looks like before it arrives. You are right in its path.

But demand is not the whole of it, and it is worth being honest about which version of this role is the one that matters. The building is turning into the easy part, the piece the tools increasingly handle on their own. What stays scarce is the judgement to look at how a company works and see which parts of it no longer need to be there, and the standing to take them out. The engineers who define this field will not be the ones who automate the fastest. They will be the ones who know what to delete.

You did plasma physics research at Cornell and presented at the American Physical Society. That is a long way from where you ended up. What pulled you away from physics?

You do all sorts of things early in your career. My first jobs were at an office supply store and being a soccer referee. But physics was the thing I fell in love with first. It was my favourite subject in high school, and I thought computer science was fun but more of a toy. You could make cute little programs, but I did not directly see it as a way to have a massive impact on the world. That was 2010, and I had not really been exposed to the world of startups or how fast tech could move.

So I went to Cornell as an engineering physics major. Plasma research was genuinely cool, the extremes of it, insane temperatures and conditions you cannot find anywhere in the world but can create with science, and then studying what happens as a result.

The turning point was a conference in Denver where we presented some of our work. The median age in the room must have been in the sixties, and there was not a lot of energy. The growth potential of the field, where it was heading, did not feel as promising as tech. Around the same time I got an internship at Google and saw the pace the company was moving at and scale of impact. That energy was hard to ignore.

You also spent a year at Oxford studying computer science and philosophy. That combination is uncommon in tech. Is there anything from the philosophy side you still use?

First, I have a pretty basic understanding of philosophy. But Oxford is one of the renowned places to study it, and part of what drew me in was the sense that I would never otherwise get to do something like that.

I do think philosophy and tech overlap more than people realise. A lot of the ideas around existential risk and effective altruism came out of that world. Nick Bostrom ran the Future of Humanity Institute at Oxford, and those ideas were a big part of the early discussions and culture at OpenAI, and arguably part of what led to Anthropic. My understanding is that a lot of Anthropic’s founding arc traces back to ideas in the sphere of existential risk and effective altruism, which came very directly from philosophy. So a company like Anthropic exists, in part, because of ideas from philosophy that found their way into tech. There is more overlap there than people give it credit for.

Leo’s path into FDE did not run through Palantir, the way many do. It ran through founding a company.

You are a former founder, not a career FDE. What about Ramp made this the right place to land after building your own company?

What I have found is that former founders often make excellent FDEs. As an early-stage founder you are talking to customers, building the product, and figuring out what to build. As an FDE it is very similar. You are talking directly to customers, working on unshaped and ambiguous problems, deciding whether to hack something together or build something robust, and doing a mix of customer, product, and engineering work. The tie between FDE and entrepreneurship is close in both directions. It is a strong fit for former founders, and it is also good training for anyone who wants to found a company later.

As for Ramp specifically, I had followed the company for a couple of years and had a lot of respect for it. It was one of the fastest-growing organisations I had seen, founded in 2019 and at an enormous valuation within a couple of years. By the time I had stepped back from my startup and was thinking about what to do next, I wanted to be somewhere that was going to grow, in an environment that rewards ambitious individuals, and where I could still draw on my startup experience. If I had gone to big tech or somewhere more mature, I do not think I would have been able to use everything I had learned, and I do not think I would have grown the way I have.

I am extremely bullish on the company’s trajectory and on what it offers ambitious builders. If your direct aspiration is to found a company, go and do that first. But if you want to see what high-calibre execution looks like, or you are early and do not yet have the conviction to start your own thing and want to build the skills and experience, and maybe meet a future co-founder along the way, this is a strong place for that.

A large share of FDEs at Ramp are former founders. That looks deliberate. What does founder experience give people that you cannot get from senior engineering experience alone?

It is less the fact of having been a founder and more what it implies about your character, skills, and motivations. The thing I care about most, and that a lot of people are thinking about now, is intrinsic drive. How genuinely motivated are you to achieve a business or customer outcome? That is hard to assess in an interview, so one of the best signals is what someone has actually done. Starting a company from scratch, and especially getting any traction, usually says something strong about ownership and motivation. Those are the characteristics that make people effective in front of customers, because they are driven to solve the customer’s problem and build good technology rather than just complete a task.

Ramp’s FDE function has grown from a handful of engineers to fifteen or twenty. I asked what changes at that size.

You have scaled the team from around five to fifteen or twenty. What do you have to pay attention to when you scale an FDE function?

My view is that FDE has emerged as a way to grow a B2B business, particularly through delivery to large customers. You cannot serve thousands of customers with dedicated humans, so the model is built around contracts large enough to justify dedicated engineering time. Scaling looks different at every organisation. Palantir is the extreme and the most mature.

Ramp’s FDE function is a little different from the more traditional version. We are oriented around unblocking our largest customers and helping us reach product-market fit in enterprise, rather than embedding a single engineer inside one customer for three to six months. Because we sit close to core product, it became impossible for everyone to be productive across the entire surface area. Ramp has a couple of hundred engineers, and no one can know every surface. So the way we scaled was to split into areas of specialisation and embed engineers in each. One team focuses on bill pay and procurement, another on the core card and reimbursement and expense experience, another on reading and writing data from Ramp in a low-effort, high-automation way.

Most leaders I speak to are trying to scale non-linearly, not just by hiring more people. Is there anything you can share about how you are approaching that?

The way you scale is by scaling with tokens, not headcount. Any time a human is doing something through their own cognition, you want that documented, you want the context available, and you want the read and write interfaces available to an agent, so that an agent can eventually do the work the human was doing. The fundamental requirement is getting context into a single place. We are heavy Notion users at Ramp, and I am excited about the shift from FDEs doing a lot of manual work to agents doing tasks on our behalf.

One concrete example. Every customer blocker or request for FDE involvement comes through a single Slack channel called FDE-Requests. In the past, someone from solutions or sales would write up notes and post them, and then we would wait, sometimes a day or two, for an FDE to pick it up, understand it, scope it down, and figure out what was needed. Now we have a Notion agent that searches our knowledge base, looks at past requests, categorises the new one, asks clarifying questions, and tags the submitter. We are starting the scoping process with an agent immediately.

To use a driving analogy, this is not full self-driving. It is closer to going from a manual to an automatic transmission. We are a long way from full autonomy on the request process, but that is the direction we are working towards.

In that fully automated world, what does an FDE actually do?

There will be plenty for FDEs to do. I am not worried about that yet. The first real challenge is managing the quality and token efficiency of agentic systems, and that architecture is not easy. Building high-quality agentic systems still takes real engineering. Agents do not just go and solve the world’s problems. You need people who understand how to do engineering well to craft and guide them. Eventually they may become stable enough that many people stop thinking about them, the way I do not think about TCP, IP, or DNS anymore. The internet just works, and we move on to the next problem.

The way the pipeline would look is a request comes in from solutions or sales, gets scoped down by an agent that is good at the back-and-forth of figuring out exactly what is being asked, possibly producing documents that go to the customer. Once you know the minimum viable request, another agent can scope the technical work by looking at the product roadmap, specs in flight, and where the feature would live in the codebase. Then a coding agent can execute and validate the change. You can imagine no human involvement from the moment a request comes in through to the feature being live. I think that is six to twelve months away.

Leo also runs Ramp’s Agent Developer Platform. He was clear it is separate from FDE, though it grew out of it.

You run the Agent Developer Platform too. How did that come about?

It is a little separate from the core FDE function, though it has roots there. On the FDE team we interfaced heavily with the developer API because we built on top of the platform, so we had a lot of opinions about it. I took on the developer API team about a year ago. It was clear that AI was going to massively change how you work with programmatic interfaces, so we started investing early in MCP and built our MCP server over a year ago. We ran experiments, including one a few months back where we had an agent try to run its own little business and use Ramp to pay for things. Those experiments into the boundaries of what the developer platform could be turned into what we now call the Agent Developer Platform. It happened gradually, and it originally came from FDE.

What changes when the customer interacting with the product is not a human but an agent?

It will still be a while, but we are seeing it more and more. MCP usage on Ramp has skyrocketed in the last six months. For about a year there were a lot of people building on MCP and almost no usage, but with Claude adoption took off. Having a good API is becoming a necessity. If you do not have one, you risk becoming obsolete.

At the same time, the interfaces humans see will become much more custom. If you think about the modalities for consuming information, audio has clear limits, text has limits too, and a two-dimensional visual representation on a screen is a very powerful interface that is here to stay. Humans will keep using software, but the experiences will become richer and far more specific to what the individual actually needs. A lot of the tedium people feel with software today, clicking through a checkout flow, waiting for something to load, should start to disappear.

Leo also invests and advises, mostly among founders he knows. I asked what he tells them about FDE.

You are an investor and advisor as well as an operator. What do you tell founders when they start thinking about an FDE team, and what do you pay attention to in the startups you work with?

Investing is a small part of my mind space. It started the way it usually does. Once you start a company and get some traction, your startup friends emerge, you exchange notes, you hire early employees who care about the world of startups, and many of them go on to found companies themselves. A lot of my first investments were friends and former early employees starting their own things. Living in San Francisco, you meet a new founder almost every day, so it is a fairly normal path.

The other part is knowing how much it means in the early days to have someone understand and support your vision. One of the first people who really believed in me and my co-founder back in 2020 was Ali Partovi at Neo, which has grown into one of the most impressive early-stage firms, early in companies like Cursor and Cognition and Kalshi. Having someone with some experience and standing say they get it, that they think you can do it, and then make introductions, meant a lot. Part of why you invest later is to pay that forward.

On FDE specifically, it is just a well-established business model now. If you are doing B2B, the biggest growth levers tend to come from landing large contracts, and that naturally puts you on the path to having an FDE function.

Most readers of this newsletter are still getting familiar with the role. Why do you think FDE is going to spread across so many companies?

It is the trend of the last year or two, and trends can change, but from what I can tell every early-stage B2B company with any enterprise ambition is creating something like FDE. They might call it something different. It is some combination of what large customers expect, how software is delivered, and how much easier coding agents have made the actual building. That mix of industry dynamics and the evolution of tech has created the role, and the growth has been an absolute explosion. I think it is roughly a hundred times year over year.

We finished where we started, with the path that got him here.

Last question. You have moved across physics, high-frequency trading, search, teaching, founding, FDE, and agents. Do you have a theory for why you have crossed so many domains, or did you just take what felt right at the time?

I actually don’t think my background is nearly as extreme as some people I’ve met, like a former colleague who dropped out of college, worked on video games, then high-frequency trading, then AI. I do not think my path is a wild outlier. Everyone is on their own path to find a place where the work aligns with their skills and values, and it took me a while to find what I was most passionate about. I have found something I feel I’m thriving in and highly aligned with now.

It is a big journey of self-discovery. Some people genuinely love big tech, the stability, the consistency, working on a specific set of problems that do not change dramatically over time. There is a wide range of archetypes for what people look for, and everyone should be seeking out the one that fits them, especially early on. Explore, and then exploit later.

Leo Mehr is Director of Engineering at Ramp, where he leads Forward Deployed Engineering and the Agent Developer Platform.

The coating project

We are working on a project in aerospace right now. The client receives metal parts that need to be coated according to a long list of industry specifications. Each part has its own attributes. The job is, given a part and the relevant specifications, to produce the exact sequence of steps to coat it correctly. A human engineer verifies the output before it lands in a system that walks factory workers through the steps on the shop floor.

I built it as a workflow.

Collection stage pulls the part attributes and the library of relevant specifications. Transformation stage does the structured extraction, the cross-referencing, the validation. Decision stage produces the ordered steps that get routed for human review. There are LLM calls at specific points where the work demands them. Everything else is deterministic.

It works. The client is happy with it. But sitting with it now, I think it probably should have been an agent.

The reasoning step is where the actual work happens. The combinations of part attributes and applicable specifications are too varied to enumerate, so the matching requires real judgement. I built deterministic plumbing around an LLM call that was making the only genuinely hard decision in the system, and then I added retrieval and validation layers because I wanted to verify each step in isolation. The result is more rigid than the underlying work needs to be.

An agent version would have given the model the tools to query specifications when it needed them and the room to iterate on partial matches. It would have been harder to verify. It would have shipped slower. And it would probably have been a better fit for the shape of the problem.

The direction of my errors

This is not an isolated case. If I am being honest about the direction of my errors, I have built workflows that should have been agents. I have not built agents that should have been workflows.

The cause is conservative bias. When I started building these systems, the models were less reliable, and every additional degree of freedom felt like risk. So I leaned toward deterministic flows with LLM calls at very specific points where I could verify each step. The systems shipped, the systems work, but some of them are more rigid than the problems they were solving.

I think this is also the bias I see most often in other practitioners. Engineers tend to over-constrain. We trust deterministic code more than probabilistic reasoning, and we reach for the workflow because it is easier to debug, easier to explain, and easier to defend in a postmortem.

That bias is becoming out of date faster than I would like to admit. The models today are reliable enough that some of the determinism I wrapped around them is doing more harm than good. It adds latency, it limits flexibility, and it papers over the fact that the genuinely hard part of the system is the reasoning step.

What changes now

If a coating project landed in my queue today, I would still draw the same shape. Collect the attributes, gather the relevant specifications, produce ordered steps, hand to a human. That part does not change.

What changes is how much determinism I would wrap around the reasoning stage. The question I would ask first is whether the work inside each stage is actually deterministic, or whether it requires reasoning over input I cannot fully anticipate. For the matching stage on coating, the answer is reasoning. That should have told me to give the model more freedom, not less.

The threshold for what counts as reasoning territory moves with the model. The systems I built when the models were less capable were workflows because I did not trust the models with more freedom. Today I would build some of them differently. The pace of model improvement now means architectural decisions in AI have a shorter shelf life than the projects that produced them. The build always has a sequel, and the sequel arrives sooner than it used to.

That framing is correct as far as it goes, but it’s also a tell. Frontier model capability has started to look an awful lot like a commodity, and the labs know it. Lock-in is the next move, and a multi-billion-dollar FDE army inside customer environments is the cleanest way to get it.

Capability is commoditising

There are at least half a dozen frontier-class models now, from OpenAI, Anthropic, Google, Meta, DeepSeek, Qwen, Kimi, and a few others, that swap places on benchmarks every few months. They’re all good. The marginal difference between the best model on a given task and the second-best is usually within the range of what a slightly better prompt or a slightly better retrieval pipeline would close anyway.

The economics tell the same story. Inference costs for equivalent quality are falling at something close to an order of magnitude per year. Anthropic’s gross margins came down to around 40% in 2025, from a projected 50%, and their break-even isn’t on the horizon until 2028. None of the frontier labs are profitable yet, and the unit economics on their consumer subscriptions are visibly under strain.

The Claude Code regression saga earlier this year is the cleanest community signal of where this is heading. Anthropic eventually traced the issue to three product-layer changes affecting Claude Code, the Agent SDK, and Cowork, while the underlying API was unaffected. Despite the post-mortem explanation, for me, Opus 4.6 was the peak, and the experience has felt downhill ever since Opus 4.7 shipped. The point is that we don’t actually know what we’re being served on any given day. The wrapper changed, and the people paying for it couldn’t tell. That isn’t unique to Anthropic. It’s the structural condition of paying a subscription for a service whose internals you can’t see.

When capability stops differentiating, and customers can’t fully trust that the thing they bought yesterday is the thing they’re getting today, the strategy has to shift. The play becomes embedding so deep in customer workflows that switching becomes painful even when it looks economically obvious. Microsoft did this for thirty years. The model labs are doing it on a compressed timeline.

Most enterprise AI work doesn’t need a frontier model

This is the part that doesn’t get said often enough. Most of what we actually deploy at enterprise clients isn’t frontier work. It’s classifying inbound emails into one of four categories. Extracting line items from invoices and matching them against purchase orders. Drafting first-pass replies to support tickets. Summarising call transcripts into action items. Routing tasks between systems. Reading a sales order and turning it into the right ERP transaction.

Almost none of this requires Opus 4.7 or GPT-5.5. A 7B to 70B open-weight model handles all of it well enough, and the gap between “well enough” and “best in class” usually shows up nowhere except in a benchmark sheet. The frontier earns its keep on a small slice of genuinely hard problems: novel agentic workflows, complex multi-step reasoning, edge cases that haven’t been seen in training, low-resource languages, long-context retrieval where every percentage point of accuracy compounds. In my work at Lleverage, across logistics, wholesale, manufacturing, insurance, and finance, that hard slice is maybe 5% of what actually lands in production. The other 95% is workhorse stuff that an open-weight model trained six months ago handles without anyone noticing.

I’ve been running Qwen, Gemma, and Mistral on my own hardware over the last few months. Not in production for any client yet, but enough to form a view. For the kinds of tasks I’d typically reach for a frontier API to do, they’re not quite as good, but they are good enough for the work most enterprises actually need done. Good enough is the only threshold that matters in production, and the gap to good enough closes faster every quarter.

A return to owning the machine

There’s a useful parallel here to the first wave of enterprise computing in the 1970s. The trailblazers were the companies that bought IBM mainframes when nobody else did, brought the machine in-house, built applications around it, and accepted the operational burden of owning the silicon, the workloads, and the upgrades. That model gave way to client-server, then to the cloud, where compute became something you rent. For two decades, owning the machine felt like an artefact of an older era.

I think AI is going to bend that line back. The companies that take this transformation seriously will, increasingly, buy ready-made machines for running LLMs and treat them as a core piece of their infrastructure, the way an earlier generation treated their first AS/400 or their first VMware cluster. Not for everything. But for the routine workloads that already touch sensitive data and don’t need a frontier model in the first place. The hardware exists in 2026 in a way it didn’t a year ago. NVIDIA’s DGX Spark, Apple’s M-series workstations, Lenovo’s ThinkStation PGX, AMD’s MI-series, and a handful of other options have made on-premise inference economical at a scale that wasn’t true even twelve months ago. A Quad DGX Spark setup runs roughly 18 to 20 thousand dollars and pays for itself in three to seven months for any team whose API spend regularly exceeds three to five thousand dollars a month.

The interesting consequence is that once you own the machine, the model running on it becomes a choice rather than a dependency. You can swap Qwen for Mistral for Gemma without re-implementing anything around it. The vendor relationship moves from the model layer down to the silicon, and silicon competition is, historically, a much healthier kind of competition than software lock-in.

The questions clients have started asking line up with this shift, even when nobody at the table uses these words. Where does the inference actually happen, on what continent, under what jurisdiction. Whose audit logs can you request. Whether anyone can promise the model isn’t being retrained on the data you’re sending it. A year ago these questions came mostly from engineering teams curious about latency. Now they come from procurement and compliance, and they tend to surface around the IT security review when somebody finally reads the fine print. The regulatory direction of travel reinforces the same shift. The EU AI Act’s high-risk obligations land in August 2026. France and Germany have launched a sovereign AI initiative with Mistral and SAP. The UK established a Sovereign AI Unit with up to £500 million of funding in mid-2025. The questions aren’t an early signal anymore. They’re the direction the rules are moving in.

Who actually does the wiring?

This is what explains why a $4 billion deployment company makes strategic sense even when frontier capability is commoditising. The bottleneck in enterprise AI isn’t the model. It’s everything around the model. The ERP that has no API. The operator whose tacit knowledge is the only documentation of how the process actually runs. The firewall rules that need re-negotiating with an implementation partner who left the client three years ago. The compliance team that needs to sign off on what data leaves which jurisdiction. The change management work that gets a sceptical operator to trust an agent’s output for the first time.

That’s the work. It’s what I’ve written about in almost every post on this newsletter. It’s unglamorous, slow, deeply context-dependent, and impossible to automate away. And it’s exactly what FDEs do. The reason OpenAI is willing to pay $4 billion to staff up an in-house FDE army is the same reason every AI company serious about enterprise revenue has been quietly building FDE teams for the last three years. The model is becoming the cheap part. Wiring it into a working system isn’t. The lock-in critique still applies, of course. Once an OpenAI engineer has spent six months inside a customer’s environment, mapping systems and building agents tightly coupled to OpenAI’s specific APIs, switching to a different lab stops being a model swap and becomes a re-implementation. That’s by design. It’s the same playbook every enterprise software vendor has run since SAP.

Which surfaces the bigger question. Who actually executes this transformation, across all these companies, globally?

Every mid-sized manufacturer, wholesaler, insurer, and logistics operator on the planet has to go through their version of what their bigger counterparts went through with the move from mainframes to client-server, and then again with client-server to cloud. The big four consultancies took the bulk of those last two waves. McKinsey, Bain & Company, and Capgemini being on the OpenAI Deployment Company cap table suggests they intend to take this one too. They have the relationships, the brand, and the procurement preference baked into thirty years of enterprise IT decision-making.

The trouble with that answer is that the work this time is more technical, more bespoke, and more dependent on the kind of context that doesn’t transfer well from one consultant’s slide deck to another. It’s FDE work. And there aren’t anywhere near enough FDEs on the planet to do it for every company that needs it. The OpenAI Deployment Company is starting with 150 engineers. Anthropic’s vehicle will scale similarly. McKinsey can throw people at projects, but the gap between a generalist consultant who knows the AI talking points and someone who can actually wire an agent into a customised ERP is real, and it’s a gap that doesn’t close in a quarter.

So who actually does it? The labs are betting on their in-house FDE armies, the consultancies on the relationships and bench they've built over thirty years, and the market is probably bigger than both put together. The question I'm sitting with isn't who wins. It's who gets the work done for the companies neither side is structured to serve.

I sit down with the customer to scope it. Within a week we’ve narrowed the wide outcome into something we can actually deliver in a meaningful timeframe. Then the pushback comes. “But you said you’d solve our whole invoice problem.” Not in those words always, but that’s the shape of it. The customer bought one thing. We’re now describing a smaller thing. Someone has to absorb the gap, and that someone is usually us.

This has happened often enough across our portfolio that it’s not a one-off. It’s the shape of a problem.

And the problem isn’t really at the scoping stage. The damage was done weeks earlier, before any FDE was in the room.

Every decision made in pre-sales compounds. A use case framed too widely in the sales call becomes a contract framed too widely. A contract framed too widely becomes a kick-off with mismatched expectations. A kick-off with mismatched expectations becomes a project that spends its first month renegotiating what it’s supposed to be. By the time you reach delivery, you’re not building. You’re recovering.

So we changed how we start.

Get an FDE in the room early

The first move was to stop letting sales scope alone.

This idea came from a recent conversation I had with Rahul Agarwal at Medplum, who runs his FDE team as what he calls sensors in the field. He described a rotating delegate system where one FDE each week is on the hook for early-stage sales calls, answering the “can it do X” questions across all prospects. The point isn’t to assign that FDE to any of those projects. It’s to make sure FDE thinking is in the room before the deal hardens.

We adapted this for our team of four. Every week, one of us is the rotating FDE. They join all pre-sales calls in the 30 to 70 per cent probability band. Below 30, it’s too speculative to spend FDE capacity on. Above 70, the project is real enough that we want a dedicated FDE rather than a rotating one. The 30 to 70 band is the window where the customer is serious but the scope is still soft, and that’s the window where an FDE can change the trajectory.

What does the rotating FDE actually do on these calls? They ask better questions than a salesperson would think to ask. Not because salespeople aren’t smart. We’re all chasing the same outcome, which is the biggest value we can credibly deliver. The difference is that an FDE can sharpen where that value actually sits, given what’s possible and what’s optimal to build first.

There are four things we want answered before a deal moves forward:

1. What does the process look like end to end today? Walk me through a single transaction, from trigger to completion. What systems are touched, what decisions are made, and by whom. This is the question that surfaces the gap between the label the deal was sold under and what’s actually going on.

2. Where does the data live, and who controls access? Which systems are involved. Cloud or on-premise. Are APIs available. Is there an external IT partner managing any of this. Integration risk and IT-partner dependency block more projects than anything else, and you want to know about both before you sign.

3. Who actually does this work every day? Can we speak to the operators, not just the champion or sponsor. How many people touch this process. Champions know what they want. Operators know how it works. You need both, and you need to confirm access to the second early.

4. What does success look like in three months? What specific outcome would justify the investment. How will the customer measure it internally. This forces them to articulate something concrete, and gives us a yardstick to scope against rather than an open-ended engagement.

The rotating FDE isn’t promising delivery. They’re often not even going to be the one delivering. The value of the rotation isn’t continuity. It’s that the customer hears these questions early, and the team gets to flag concerns before they get baked into a contract.

Dedicate an FDE before the deal closes

Once a deal crosses 80 per cent likelihood of closing, the rotation ends and one FDE takes ownership. Sometimes that’s the rotating FDE who’s been in the calls. Often it isn’t. What matters is that ownership transfers cleanly, and that it happens before the deal officially closes rather than after.

The reason for that timing is simple. The week between contract signature and project kick-off is wasted week. If a dedicated FDE is named once a deal looks close to certain, they can start absorbing context while the commercial paperwork moves in parallel. By the time the contract is signed, the FDE has been in the late-stage calls, has read whatever documentation exists, and is ready to run the kick-off.

Run the kick-off before doing anything else

The kick-off isn’t where work begins. It’s where we explain what work begins, and what we need from the customer before it does.

The kick-off has two jobs. First, set expectations for the engagement: what we’re building, what we’re not building, how we’re going to work together. Second, hand the customer their list. Credentials for the services we need to integrate with. Test environments we can break without consequence. Ground truth sample data, real cases the system should handle and real cases it currently gets wrong. A high-level overview of the process from the people who actually run it. Named partners in IT who can unblock us when we hit access issues, because we will hit access issues.

The customer then has one to two weeks to deliver that list. Nothing else happens in the meantime.

This sounds rigid and it is. The reason it’s rigid is that the cost of starting without the list is enormous and invisible. You begin building against assumed integrations, you discover the assumptions are wrong in week three, and now you’re rebuilding while explaining why the timeline is slipping. Or you start without ground truth data and ship something that works on the synthetic examples and falls over on the real ones.

If the customer can’t get us tool access in two weeks, that’s also information. It tells us something about how their organisation moves, and it predicts how the rest of the project will go.

Spend one to three days on site

Once the materials are in, we go on site.

The duration depends on the complexity of the process, which usually correlates with the contract size. One day for something narrow, three for something with multiple stakeholders and handoffs.

What we do on site is shadow. We sit with the operators who currently do the work. We watch them do it. We interview the champion, but we don’t only talk to the champion, because champions know what they want and operators know how it actually works. We ask questions that probably feel obvious to them and reveal things that aren’t obvious at all. Why do you check this twice. What happens when this field is blank. Who do you call when the system is down. Is there a spreadsheet on someone’s desktop that this depends on.

There’s no shortcut for this. Calls don’t surface it. Documentation doesn’t capture it. The tacit operational knowledge that determines whether a project succeeds is in people’s hands and habits, and you have to be next to them to see it.

A common worry is that this is paternalistic, or that customers won’t want us in their offices. In practice the opposite is true. Customers are usually relieved to have someone take their process seriously enough to sit with it. The ones who don’t want us on site are usually the ones whose projects we should be more cautious about anyway.

Define the scope

Only now do we write the statement of work.

By this point we’ve been in pre-sales calls, we’ve owned the project for two or three weeks, we’ve received everything we asked for, and we’ve watched the work happen. The scope we now write is grounded in that, not in the wide framing from the sales call. It defines what we will deliver to call the engagement complete, broken into specific capabilities with timelines and an estimated FDE budget. That’s the document the customer signs off on. Reaching the end of it is what ends the project.

Internally, alongside the full scope, we pick a first slice. Something inside the scope that we can deliver end-to-end in roughly a week, so the customer starts getting real value almost immediately. It might be ten per cent of the total scope, sometimes thirty, occasionally more. The exact size matters less than the shape: it has to be end-to-end, it has to run on real data, and it has to be something an operator can actually use rather than a demo we click through ourselves.

That first slice is deliberate. The point is to get something in front of operators that they can poke at, react to, complain about, and start building habits around. A live solution processing real data teaches us more in a week than months of planning. It surfaces the integration edges, the undocumented system behaviour, the IT-partner responsiveness, all of it, while there’s still time to do something about it. From there we keep building against the agreed scope, with each iteration landing in something the customer is already using.

Wide scoping at the start kills upsell. If phase one was framed too broadly and underdelivered, there is no phase two. A scope that’s well-defined and well-delivered is the only reliable path to the second engagement. Customers don’t buy more from teams that disappointed them on the first thing. They buy more from teams that shipped something useful in the first month and earned the right to do harder things.

What we’ve seen so far

We’ve run two projects through this full sequence. That’s not enough to call it proven, but it’s enough to notice that both have started cleaner than projects we ran the old way. Less mid-project reframing. Less of the conversation that begins with “but I thought you were going to do.” Faster path to a deliverable that an operator can actually use.

We’re going to keep running it and refining as we go. The four questions the rotating FDE walks into a call with will keep evolving. The criteria for what makes a good first slice are still being learned. The tradeoff between rigour and speed at the front of the project will keep adjusting.

But the underlying bet feels right. Everything that’s unclear early compounds. Every assumption left unexamined in pre-sales becomes an argument in week six. The leverage isn’t at delivery, where most teams focus their energy. It’s at the start, where most teams aren’t even paying attention.

Scope is a contract, not a conversation. The work we do before the build is the work that decides what the build will be. Clarity early is the cheapest part of the project. It’s also the part most likely to be skipped, because nothing seems to be happening when you’re waiting on credentials or sitting in a sales call you’re not going to deliver. But that’s exactly when the project is being decided. The build is just where the decision becomes visible.

You’ve now worked as an FDE at two quite different companies. How do the roles compare?

There are a lot of differences, and part of it boils down to the fact that Actively is an AI-native company that started as AI-native. Rippling is a SaaS company that’s existed for a while and is moving to be AI-forward. It is very much AI-forward now, but the archetypes are very different.

You see a lot of AI-native companies that are smaller, younger, newer, that emerged in the past two or three years and employ FDEs. And then there are these SaaS giants that have pivoted to be more AI-forward over the last couple of years. Rippling is an example. Ramp, Salesforce, Databricks and Snowflake all have FDEs now. These are companies that existed for years before AI adoption was the thing.

The role differs quite a bit between the two. At a smaller AI-native company the day-to-day work is heavily agentic, heavily focused on building the AI product itself. At a larger company it’s AI-focused too, but you’re also building custom code on top of a mature platform for a particular customer. The platform is more mature, so you can.

At a younger company you also do a lot more pre-sales POC work, because the company is still trying to find its footing. At Rippling there isn’t really time for that. There are already so many customers and a robust sales motion that handles winning the deal. Your job becomes filling in gaps in the product for a given customer, rather than putting time and effort into convincing someone to sign.

At Actively you had a 100% pilot-to-paid conversion rate. What does it actually take to get a pilot to convert?

The main purpose of a pilot is to prove out ROI. And with AI that can be tricky. You can talk about boosting productivity, or boosting revenue, or moving some other metric. But at the end of the day it needs to tie back to the P&L. You’re paying us X, we’re netting you Y, and Y needs to be much greater than X for you to be convinced to buy.

The customer is usually evaluating other tools in the space at the same time. So the path you take as an FDE is not just implementing the thing. Before you even implement it, you decide on the metrics with the customer. If we can prove out this percentage increase on this productivity or revenue metric, that is the success criterion for this POC.

It’s hard to measure AI workflows. You can’t just run the pilot for a month and at the end say, here are the reports. It has to be something you track from the beginning. Some metrics are genuinely impossible to track, but as much as you can, you need to be forthcoming with the numbers. It’s less of a technical problem than it is about managing customer expectations and building trust in the fact that you’re both looking at the same metrics.

On the POC itself, do you prefer to go narrow and end-to-end, or wide with a big magical moment?

Narrow and end-to-end, almost always. You prove out one part of the product that truly works, with measured metrics against it. You acknowledge there are other parts of the product that will have tangible or intangible benefits over time, but you have one clear thing to measure against.

The risk with going wide is that you don’t actually end up proving ROI, because that isn’t how the product will be used in practice. You can also build something so bespoke to one person’s workflow that it just doesn’t generalise. Starting narrow also sets up the next conversation. If you delivered something concrete in a week, it’s easier to make the case for what five weeks would look like.

How do you handle context gathering? No FDE I’ve spoken to has managed to collect everything up front.

I don’t think the answer is getting 100% of the information you want up front, and I don’t think it’s unique to being an FDE. This is a customer success problem that’s existed for as long as companies have been working with each other.

It does become easier in the age of AI. If the customer is already using AI tools, or has a bunch of documents scattered everywhere, you can ingest it, build a vector database, index it, and get somewhere. But the business end of it is never a technically hard problem. It’s that they don’t know what to send over, and we don’t know what they have unless we ask for it.

The approach I like is separating it into high-level and low-level. You have an initial high-level discussion to determine feasibility, scope the work, and agree on an architecture. Once you have that, you have enough confidence to move into implementation, where the nitty-gritty details surface.

A common one is approval processes. A lot of them are very unique to a business. It’s not even based on roles, it’s “Samantha is the approver here.” And what happens if Samantha leaves? Who knows. That kind of data isn’t something you can scope up front. You just have to know, going in, that someone is approving this, and build to that shape. You figure out who the someones are later. By asking the big questions you get 80% of the way there. The last 20% is what’s painful, and it just sits in the tail of the project.

When is a project actually done? How do you close the loop without endless scope creep?

This was something we had to figure out at Actively, because we would never stop. At Rippling we realised we needed a harder boundary, otherwise the model doesn’t scale.

The way you solve it is the way any SaaS product tends to solve it. Contracts and guidelines that outline the scope. This is what we are going to deliver. Once we deliver it, your problem should be solved. The initial scope becomes a document both parties sign and are beholden to. It works the other way too. If we don’t implement what we said we were going to, you can hold us accountable.

Whether the scope document is pre-commercial or post-commercial doesn’t really matter. I’ve talked to FDEs at other SaaS companies and it varies a lot. There is a difference in how much leverage you have in that conversation depending on the stage of the company. A larger, more established player can push back on scope in a way that a seed-stage company doing forward deployed work simply can’t, because they don’t yet have the leverage.

The FDE job description tends to read like a unicorn spec. Kanav spent almost three years at Amazon before moving into the role.

What was the hardest part of that transition, coming from a core software engineering background?

Two things stood out. The first was context switching. Whatever size of company you’re at, as a core software engineer you have layers of separation from the customer. PMs, sales, customer success, sometimes your own manager. That shielding lets you dive into your technical environment, and that’s what it was for me at Amazon.

As an FDE you might be on one customer call right now, another half an hour from now, and you have that half an hour in between to code something. You never get to truly lock in. That’s a hard skill to master, and I don’t think you fully can. Humans have a context window, like agents do. You try to minimise context switching where you can, but you also have to build the muscle of doing both parts of the job.

The second thing was interfacing with customers directly. You think there’s always a layer of separation, where you have to be professional because you’re representing the company. But true discovery happens when you’re fully comfortable with the customer and they’re fully comfortable with you. Being able to embed in their process, learn their business immediately, pick up the nuances of it, and ask the right questions to get them to open up. That’s a muscle I had to build over time.

On the depth question, Palantir is famous for sending FDEs to embed with one customer for months at a time. That’s obviously not feasible at most AI companies. How do you think about depth versus breadth?

Unfortunately, it isn’t really something you get to decide as a company or as an individual. It’s decided by account size, by ACV, by ARR. It becomes a question of economics. Whether you can afford to embed a whole FDE into one customer’s workflow.

Palantir is one of one. As you move to AI companies, or AI-forward companies, the FDE almost always has to manage multiple implementations in parallel. With the Palantir model, you have the advantage of learning one business really deeply. With the multi-customer model, you want depth but you also need breadth. Over time breadth becomes more important, as does the ability to pick up new things about new businesses quickly.

If you’re dealing with a large enterprise tech customer versus a big restaurant chain versus a retail store, their workflows differ drastically. You have to be able to pick it up and embed in all of them at once. You probably won’t reach the same depth as someone working on a single project. But that isn’t within the control of an individual. It’s dictated by the economics of the situation.

We’re software engineers by training and we tend to aim for close to perfection, but the role doesn’t always allow it.

It’s something you have to get used to while using AI products anyway. A lot of traditional software is deterministic. AI products mostly aren’t. You can make parts more strongly typed, you can build strict guardrails around certain components, but as a whole, software is moving in a non-deterministic, directionally correct direction. That has to be good enough. Even if most of your end-to-end solution is deterministic, one probabilistic link makes the whole solution probabilistic.

You’ve described the FDE role as a kind of founder bootcamp. Why?

I’ll call on what one of the co-founders at Actively used to say. There are really only two things that make money if you think about it abstractly. Building things and selling things. Engineering and sales. The FDE role sits right in the middle of that.

A founder goes through a process where they’re building a product and also doing customer discovery. Who wants this, what are their pain points, what would help them do things faster, or eliminate manual work. You figure that out in the customer discovery part, but you also have to immediately tie it back and build it. That’s what I feel like I do every day, whether it was at Actively or now at Rippling.

At both companies I’ve had the benefit of a sales team and a core product team supporting me. My job is to create the link between them. Because of that link I’ve learned a huge amount about the sales process that I never would have as a core software engineer, and a lot about building things I wouldn’t have picked up in sales. And it isn’t only sales. It’s marketing, customer success, RevOps. All these teams I converse with and learn from, whose workflows I end up observing. The same thing on the engineering side. It isn’t just building. It’s making product management decisions, small ones, but real ones, to build the software correctly.

You do a little bit of everything. And as such, it helps you build the skills to run your own company one day.

Anything you’d want other FDEs to keep in mind?

The role is still rapidly changing. If you discount Palantir and look only at the AI world, the oldest FDEs at AI companies are maybe a year in. Everyone is still figuring out processes. Part of the job is understanding that this is a role filling a gap that exists right now. AI makes it easier to build software and easier to talk to customers, so I think the role is here to stay. But what the FDE role looks like now versus a year from now could be very different. The core products we use and the industry we’re in are changing that fast.

Kanav Bhatnagar is a Senior Forward Deployed Engineer at Rippling, where he’s on the founding FDE team building out the function from the ground up. He was previously an FDE at Actively AI and a software engineer at Amazon.

The playbook for scaling a team used to be pretty simple: revenue goes up, headcount follows, hire enough people to cover the volume, then hire more to manage the people you just hired. Everyone understood the math, boards expected it, and forecasts were built around it with almost no questioning of the underlying assumptions.

That model is broken, and I don’t think it’s coming back.

Let me tell you about a project I saw running at every enterprise I worked with over the last decade. None of this will be new to you.

They called it different things: company ontology, knowledge graph, single source of truth, shared data model. Different vocabulary, same project: get the entire organization operating from one common language. Product called them “customers.” Finance called them “accounts.” Customer Success called them “clients.” Legal called them “counterparties.” Four words for the same human being, living in four different systems, with four slightly different definitions of what counted as active, churned, or at risk.

The result: most of the coordination overhead in a large company isn’t strategic, it’s definitional. You’re not having a meeting to make a decision; you’re having a meeting to establish what the numbers even mean before anyone can start making a decision, then scheduling a follow-up because someone pulled a different number from a different system, and by that point the actual work has been sitting untouched for two weeks. This is the information layer that runs through humans because there was no other place for it to live.

AI (properly implemented) has changed the cost of fixing this dramatically. You don’t have to perfectly unify every system before you start getting value; you can build a working model of how your organization describes itself, connect it to your preferred AI provider, and the CS manager who used to spend three hours hunting down renewal data and the QBR template to copy from, can query it and create the deck in four minutes. The constant “hey, what’s going on with X” that accounted for 40% of most people’s communication overhead largely disappears. That’s the setup. Here’s the framework that actually determines whether any of it matters.

The four tiers. Embarrassingly simple, almost universally ignored in the right order.

1. AI it.

Try this first, always, even when you’re confident it won’t work. The attempt is the point, because even when it fails it usually tells you something useful about the underlying process that you didn’t have explicit language for before.

What this looks like in practice for anyone in post-sales or implementation work: drafting account health summaries, generating first-pass renewal risk assessments, summarizing call transcripts into action items, building the skeleton of a QBR deck, triaging incoming tickets/customer requests by urgency and category, writing the first draft of a playbook that a human then edits. The output isn’t always usable. An 80% draft that takes two minutes still beats a blank page that takes two hours, and more often than not, the 20% gap is specific and fixable rather than fundamental. When AI fails at a task, the failure is almost always informative: it’s pointing at the part of the process that was never clearly defined in the first place.

The biggest mistake here is treating “it didn’t do it perfectly” as a verdict. It’s not a verdict; it’s a data point about the process.

2. Automate it the old way.

Rules, triggers, scripts, workflows. Pre-2023 thinking, still valid and still underused for anything deterministic. If the output of a process is predictable given a set of inputs, a human should not be the mechanism that connects them.

Most organizations have already paid for this capability and aren’t using it. If a support ticket comes in with a specific keyword from a customer in a specific segment, it should route automatically. If an account’s health score drops below a threshold, something should happen without anyone manually noticing and then manually deciding to act. If a contract hits a 90-day renewal window, the motion should start on its own. These are not complex problems; they’re rules that nobody built because defaulting to a human was easier than writing the rule once.

The 90% of SaaS tools you’ve already bought are effectively capable of doing this, or were designed to. Salesforce workflows, HubSpot sequences, Zendesk triggers, Gainsight playbooks. The access is there. The will to sit down and configure it usually isn’t. That’s the actual gap, and it’s a choice gap, not a technology gap.

And increasingly, tier one can handle the setup and configuration of tier two for you, which blurs the line between them.

3. Write a better SOP.

If a human genuinely has to do it, at least make it repeatable, trainable, and documented well enough that the next person doesn’t have to rebuild it from memory. The teams that are hardest to automate are almost always the ones that never wrote anything down; you can’t AI a process you haven’t described, and you can’t automate a workflow that exists entirely inside one person’s head.

These SOPs matter beyond the immediate documentation value: they’re the training data for whatever comes next. Every process you document today is a process you can hand to an agent later with something approaching confidence. The teams skipping this step aren’t just making their lives harder now; they’re making the transition to tier one harder when it becomes unavoidable.

4. Throw a person at it.

Hire someone, add headcount, default to humans. This is the right call for a narrow set of things. Judgment calls where someone needs to be personally accountable. Relationships where trust is the product. Situations where the context is too specific and too recent for any system to have it. An enterprise renewal going sideways because of an executive relationship problem is a tier-four problem. A QBR deck is not.

The problem isn’t tier four existing; it’s that it became the default for everything, including work that isn’t complex, high-stakes, or relationship-dependent. Tiers one and two were either never seriously attempted, or when they were, expectations were miscalibrated and solutions were designed by humans who assumed human involvement was necessary, which is a surprisingly hard assumption to challenge when you’re the human doing the designing.

For most of the last decade, tiers two through four were the real options, and the mature move was knowing which tier a problem belonged in. That’s not quite the situation anymore. Tier one is now a mandate, coming loudly from every CEO in every all-hands, which is not a strategy; it’s a mandate, and mandates without methods don’t produce what the people issuing them want. The organizations that actually get there are the ones where individuals built the habit before anyone told them to. Tier two is still valid and underused, especially now that the technical barriers to accomplishing them are effectively non-existent. Tiers three and four are becoming the exception, and the only work that should land there is work that has genuinely exhausted the first two.

I think this is where it’s heading: the healthiest org you can show an investor is one where 70% or more of your headcount is built around humans (employees) talking to other humans (customers/suppliers). The remaining 30% is the rest of the org, and even that number gets blurry, because as AI absorbs more of the operational and analytical work, roles like engineering, marketing, and product naturally spend more of their time interfacing with customers too. The metric I’d start watching: what percentage of your people woke up today and actually talked to a customer? That number should be going up.

The scaling playbook isn’t gone; it’s just running on different assumptions. Start stress-testing AI against your own work, not because your company told you to, but because every attempt builds a reflex that’s going to matter for the rest of your career. Even when it fails, especially when it fails, you learn something about the process you didn’t know before. That muscle comes from repetition, not mandates.

That’s pretty much the whole job now.

Rory O'Brien is an advisor and fractional CXO for seed to Series B startups, with 15+ years scaling post-sales and customer experience organizations. He previously served as VP of CX at HappyRobot and Tonkean, where he built and scaled FDE/Implementation, deployment strategy, and customer experience teams. You can find him on LinkedIn, Substack, and X.

To set the scene for readers who don’t know Medplum, what do your FDEs actually do day to day?

Medplum is an open source healthcare toolkit for developers. We make a set of Lego blocks for the most common healthcare applications, mostly EHRs, the systems doctors and nurses use to document clinical notes and order lab work and prescriptions. There’s a whole new breed of digital health companies building these at scale, fifty states, tens to hundreds of thousands of patients a month, but only for a narrow slice like specialty pediatrics. They need bespoke solutions. We took what a standard EHR does, exploded it into modules, made them open source, and let developers at these companies put the pieces together for their care model.

The hard part for our customers is making all those choices. Our FDEs have to be highly technical because they’re working with developers on the other side. You can’t just be a product person. A lot of our daily interactions are, “what is this error message, why didn’t my lab order go through to the lab.” But they also have to be good with people. Each of our FDEs supports between five and ten customers. We don’t send a team to a customer. One FDE supports many.

We didn’t found the company saying we’d have engineering, product, FDE. We don’t actually have a product team right now. The FDE function was born out of necessity, which I imagine is true for most companies hiring FDEs.

Most FDEs I speak to work directly with operators. Yours work with engineers who are building products for operators. How much harder does that make it to surface the tacit operational knowledge healthcare is famous for?

It’s a real challenge. The ideal is that engineers are our day to day but we have direct access to operators too. In healthcare there are two flavours. There’s clinical staff, the doctors and nurses doing care. And there’s an operational layer doing scheduling and billing, making sure patients move through the workflow. We want to get to both, or at least have a champion who can give us ground truth on the actual workflow.

Our engineering counterparts are strong developers but they’re often new to healthcare themselves. They don’t always know the right questions to ask. And when you do talk to operators, they describe how they currently do things, not how things should or could work. A lot of doctors at digital health companies aren’t doing it as their day job. They work in a hospital during the day and take telehealth visits on their off days, so when you ask them to design a system they bring all the baggage of their day job into the company.

So there’s a balance. We have to earn the right to talk directly to product or to clinical, but we also don’t want to get sucked into talking to ten physicians ourselves. Someone has to own the synthesis, and someone is always going to be unhappy with the result. We’d rather the customer’s internal stakeholders own that decision, with us guiding them based on best practice.

The reason that synthesis question is so loaded is that at Medplum, the FDE team is also doing the work a product organisation would normally do. I asked Rahul to walk me through how that actually functions.

Your CEO Reshma has talked publicly about Medplum running without traditional product managers, with the FDE team being how customer reality gets into the product. How does that actually work?

We probably won’t have PMs for at least another year. I’m not saying never, but FDEs are sensors in the field. They’re with customers every day, so they have a strong understanding of what customers need.

The challenge is combining those needs into generalised feature requests rather than building a hundred features that look almost identical, where this one is the way customer one wanted it and that one is the way customer two wanted it. That’s part of the argument for keeping core engineering separate. They have to build things that are general purpose by necessity. The organisational challenge is the connective tissue between FDE and core engineering.

Everyone has access to all code bases. FDEs are encouraged to contribute to the core. There’s no gatekeeping. It’s a division of labour.

The core engineering team has a weekly standup, and we send one rotating delegate from the FDE team to it. The FDE team does pre-work the day before to collate all the burning issues from customers and stack-rank them into one unified list across all features and all customers. The point is to avoid the anti-pattern I see at other places where every FDE is advocating for their own customer at the expense of others. If everyone goes directly to engineering and throws a ticket over the fence, the squeakiest wheel gets the grease. “Oh my God, this customer needs this tomorrow, this one is a high revenue deal, we need to do this thing that we all know is a bad feature.”

We make intentional tradeoffs among the FDEs. I know this customer is upset, but I will take the heat. We can talk about workarounds until the right thing is built. The unified list also gives the whole team visibility on what’s being requested. So if you hear a request that sounds like one from another customer, you have the familiarity to say, that feature is already in development, the thing in flight will suffice.

That’s how we do reconciliation without product managers. We might need PMs in a year as the team grows and these meetings stop scaling. But adding another layer is just another game of telephone between customer, FDE, and engineering. We’re trying to reduce telephone, not add to it.

One of the failure modes I hear about is core engineering and FDE turning into adversaries. How do you avoid that?

It’s a real anti-pattern. Core engineering starts to think FDE is always asking for everything tomorrow, because customers ask for things on customer timelines, not six-month timelines. The FDE team starts to think core is too slow, too much exploration.

The rotating delegate is partly an empathy-building exercise. Everyone gets exposure to engineering, inside their standard processes. You have to understand the trade-offs. If we did this the quick and dirty way, here’s what we lose. As a leader, you can say these are the same function with different responsibilities, but the teams have to actually trust each other. The FDEs need to understand that even if their customer needs something tomorrow, a hacky implementation has long-term costs. Core engineers need to understand that not everything can be perfectly designed, that there are real commercial factors and real customer pain. Even when customers aren’t doing things the way we’d like, they’ve made certain choices and we have to support them within a framework.

The other piece is the narrative inside the company. Even if it’s not true, the story can develop that FDEs are lower-quality engineers, body shop. Keeping the technical bar high is one defence against that. It’s easier said than done because you’re already asking for people skills and product judgement on top of engineering. But the bar matters.

You’ve got a public repo, a Discord, an issue tracker, paying customers and enterprise contracts running in parallel. Where does the FDE responsibility actually start in the customer lifecycle?

It’s a bell curve where the tails extend to infinity, but there’s a middle. We have a delegate to the sales process the same way we have one to engineering.

The sales process for an enterprise platform like ours has distinct phases. The first is, “hi, how are you, is this even a fit.” Salespeople handle that. Then there’s a technical capabilities Q&A. “Can it do this, how would it handle that?” I call it the “can Medplum do X?” phase. The important thing is that it’s stateless. It’s more about us than about the customer. So in that phase we have a rotating FDE on the hook for whatever calls come up that week, just to answer can-it-do-X questions across all prospects.

As we get deeper into the funnel, around a seventy per cent chance of close, we pre-assign a dedicated FDE. That’s before the deal actually closes, because close itself is fuzzy. There’s close-a-pilot and there’s close-for-real. By that seventy per cent mark things get stateful. You have to know a lot about the customer’s care model, their business model, their legacy system, their migration challenges. So we assign the dedicated FDE then, and by the time real building starts that person is already ramped up. Earlier than that, when they’re just kicking the tires, it’s too noisy to pre-assign.

Once the deal closes and the project starts, how do you make sure you have enough context to build the right thing?

That is the fundamental challenge. You need to get all the way into the belly of the beast of the customer, really understand what they want, what they need, even when they’re not asking for it. The key skill is telling them what they should be building (based on our experience), not just what they asked for.

The methodology we use is what we call our enterprise workshop. It works under the assumption that you’re not going to know everything. The goal isn’t to spend three months gathering all the context. You won’t, you never will. The goal is to prove that our product solves a problem in a very short time. We target one to two weeks.

When I tell customers we’re going to pick one thing and build it in two weeks, people lose their minds at first. “That’s too small. We’re a core system of record, we expected Medplum to solve all these problems.” But three months is forever. People dilly-dally until the last month anyway. They’re slow to respond, slow to get you information. By reducing the scope to one or two weeks, it forces customers to think smaller, and to actually pick one problem instead of saying everything is high priority but nothing is actionable. Decision-making on the customer side is the slowest part of all this. We can always match or exceed the customer’s energy.

The problem we pick has to be end to end, from user to back end, not three back-end features with no user input. And it has to be something better than their existing system, not a re-implementation. I want to focus on why they came to us in the first place. Their old system can’t do X, that’s why they’re considering us, so let’s work on X first.

Sometimes in two weeks we can’t get real usage, but we did force their engineers to talk to their clinicians and to their ops team. It sounds paternalistic, but I think of it as the connective tissue. Now they know how to build on Medplum, and they know who needs to be consulted for the rest. Over the following months they’re often already accelerated by that connective tissue alone.

If you were hiring your next FDE tomorrow, what’s the signal that matters most? And how much does healthcare background matter?

We assume no healthcare background. I had none before I started this company. My co-founders did, which was essential as a founding team, but we don’t require it.

When we hire we think about slope versus Y-intercept. We’re looking for high-slope people who have demonstrated they learn fast, that they’re motivated to own a whole thing and eat pain. They don’t have a lot of preconditions about what their work looks like.

Give me an example of someone who showed that.

A few stories. We have one person who was in an engineering department at their previous company and had been told not to talk to customers. Just focus on your job, head down. They learned a customer was suffering, disregarded orders, went and built the feature, and then built the internal buy-in for the broader migration. When the thing shipped and they wanted to follow up, the customer manager said that’s someone else’s job. But they wanted to break the mould and actually solve the problem.

Others came from more traditional sales engineering or solutions backgrounds and volunteered for the hardest customers. There are always little bugs at go-live, and they were the ones running into the fire. With others you just see them going beyond their job description. Even when they handed something off to a salesperson, they followed up to make sure the problem actually got solved, not just that they did their job.

A lot of leaders starting FDE teams now don’t have an FDE background themselves. What’s your advice to them?

I get the question a lot. Is FDE product, sales, engineering? There are different ways to make it work, but my bias is towards engineering. Treat it as an engineering function. Putting the team structurally inside engineering is one defence against the cultural anti-patterns. Keeping the technical bar high is another.

The rest is in the messaging. I deliberately use the terms division of labour and separation of responsibilities. These are the same function with different jobs to do, not different tiers of engineer. A leader can say that, but the teams have to actually live it, which is why the rotating delegate exists. It’s as much a trust-building ritual as it is a process.

Hiring is one thing. Keeping good FDEs is another. People don’t talk enough about retention. How do you keep someone who’s an excellent engineer, a good communicator, and has product instincts, when on paper they could do anything?

At least once or twice a month when I address the team, I remind them that FDE is basically founder school at Medplum. You’re going to be so pluripotent. You’re working on sales, you’re at the head of commercial conversations, you’re doing tech, you’re doing product. You’re already doing all the functions. If you put your founder hat on, even if you’re not an expert in all of them, you’ll have enough familiarity to go found your own company, hire those roles, and have judgement over them.

So it makes the good ones really hard to retain. If they’re good they’re going to go off and do their own thing at some point. I have to price that in and just keep hiring. We haven’t had churn on this dimension yet, but I’m not holding my breath. In some ways we’d want it to happen, to know we’re providing an environment that grows people.

I had this problem when hiring FDEs myself. Everyone I grew up with at Palantir has founded their own company. I can’t get my best FDEs to come work for me because they have their own companies.

The other thing that helps is that because we hire more for slope than Y-intercept, we can accept slightly more junior candidates than we would on the core engineering side. That creates a real opportunity for mentorship. We’ve defined an FDE lead role and an FDE mentor role. New FDEs need to hit the ground running. If I’m putting them in front of a customer in two weeks, they have to own those customers within the first one to two weeks. There’s a lot of content knowledge involved. Rather than me teaching them everything, senior FDEs mentor junior FDEs. So we’ve built a progression in, where you’re responsible not just for your own customers’ outcomes but for your mentee’s outcomes too.

Anything else you wanted to share?

One thing on AI and agentic coding. The question I always get is whether that means FDEs can be more or less technical because of the coding tools. I’m coming down conclusively on more technical. If an FDE is technical enough to actually read our codebase and understand the architecture, not just talk about it, they can sometimes ship a small bug fix in between meetings. We just got off the call, we already filed the fix, and because we’re open source we can point them to the PR. As a developer tool, there are so many small one-off things, and shortening that cycle is where the delight comes from.

Rahul Agarwal is co-founder and COO at Medplum. He’s hiring FDEs in the San Francisco Bay Area.

I’m trying something new on FDE Hub. Alongside my own writing and interviews, I want to start sharing work from other people writing about Forward Deployed Engineering and adjacent roles. There’s a small but growing group of us thinking and writing about this craft, and the more we can cross-pollinate, the better for everyone trying to figure out what this work actually is.

First up is Prasad Rao, who writes Big Tech Careers. Prasad spent years as a Principal Solutions Architect at AWS and has been covering the Solutions Architect and FDE roles from the angle I don’t really touch on FDE Hub: how to break in. His audience is largely engineers and architects looking to level up their careers, and his pieces on the AI FDE role have been some of the clearest writing out there on what these jobs actually require on paper.

I write a lot about what FDEs do once they’re in the role. Prasad writes about how to get there in the first place. The two perspectives complement each other well, and I think his piece below is one of the most useful things you can read if you’re either considering an FDE role or trying to understand what hiring teams at the big AI companies are actually looking for.

Over to Prasad.

— Milos

This is a follow‑up to my earlier article on transitioning from Developer/Architect to AI FDE roles. In that piece, I argued that the knowledge gap is smaller than you think if you already work as an Solutions Architect (SA) or Software Engineer (SWE).

In this article, I go one level deeper: I analyze what AI Forward Deployed Engineer–style roles actually look like at five of the most sought‑after companies—OpenAI, Anthropic, NVIDIA, Databricks, and Salesforce—and distill the skills you really need to break into them.

You’ll notice a pattern: the core skills are the same, but each company has its own weightage for each of these skills that they look for in candidates.

The Common DNA: What All AI FDE Roles Expect

Before we pick apart company‑specific nuances, it’s worth summarizing the shared core of these roles.

Across these five companies, an AI FDE is expected to:

• Embed with customers or strategic internal teams, not just sit in a central platform group.

• Own end‑to‑end delivery: discovery, design, implementation, deployment, and post‑go‑live iteration.

• Work directly with modern LLM tooling: RAG systems, agents, vector stores, observability, and cost controls.

• Translate messy business requirements into durable technical systems and then back into business value.

• Operate under ambiguity, time pressure, and partial information.

As you can see, these are combination of SA, SWE and AI skills including both technical and behavioral skills.

OpenAI: Deep AI Fluency + Full‑Stack Ownership

Positioning: OpenAI’s forward‑deployed roles skew toward high‑stakes, high‑impact deployments with customers who are building on top of frontier models. The expectation is that you act as both a product engineer and a field architect.

What they really test for:

• LLM depth, not just API usage

  • Solid understanding of tokenization, context windows, function calling, system prompts, rate limits, and failure modes.

  • Ability to choose between RAG, fine‑tuning, and prompt‑engineering tradeoffs and justify them with cost/latency/quality reasoning.

• Full‑stack + infra skills

  • Comfortable shipping production systems: backend (Python/TypeScript), basic frontend (React/Next), infra (Docker, K8s, cloud).

  • Can design data pipelines for logging, analytics, safety signals, and feedback loops.

• Customer‑facing ambiguity handling

  • You walk into “we want AI” conversations and shape them into concrete use cases, milestones, and guardrails.

  • You’re comfortable saying “no” to unrealistic expectations while offering a simpler path that still delivers value.

How to prepare for OpenAI‑style FDE interviews:

• Build and ship at least one real product on OpenAI APIs (not a toy chatbot): for example, a workflow assistant with RAG, role‑based access, analytics dashboard, and guardrails.

• Be ready with case studies that show: discovery → design tradeoffs → shipping under constraints → post‑launch iteration.

• Practice explaining LLM tradeoffs to a non‑technical VP in simple language.

Current FDE open roles at OpenAI

• https://openai.com/careers/search/?q=FDE

Anthropic: Safety‑First Applied AI + Long‑Term Customer Stewardship

Positioning: Anthropic’s forward‑deployed engineers lean heavily into applied AI with a safety and reliability lens. You’re expected to think about not just “does it work?” but “does it behave safely and predictably under pressure?”

What they really test for:

• Applied AI engineering with a safety mindset

  • Familiarity with Claude‑style models, safety policies, red‑teaming concepts, and failure‑mode thinking.

  • Ability to design flows that mitigate prompt injection, abuse, and misuse scenarios.

• Structured reasoning & evaluation

  • Designing evaluation harnesses, test datasets, and metrics for “quality” beyond simple accuracy: helpfulness, honesty, harmlessness.

  • Iterating on prompts and policies in a structured, data‑driven way.

• High‑trust, long‑term client relationships

  • You’re more steward than “hit‑and‑run” implementer; you help customers evolve their AI maturity over months, not just ship a single feature.

  • Strong written communication: architecture docs, safety considerations, decision logs.

How to prepare for Anthropic‑style FDE interviews:

• Build at least one “safety‑aware” AI feature: think moderation, red‑teaming tools, or evaluation dashboards that track failure modes, not just latency.

• Prepare stories where you caught risks early (data misuse, policy issues, security gaps) and navigated them with stakeholders.

• Practice walking through how you’d design an AI system for a regulated domain (finance, healthcare, gov) and what safety levers you’d include.

Current FDE open roles at Anthropic

• https://job-boards.greenhouse.io/anthropic?keyword=FDE

NVIDIA: Systems‑Level Performance + AI Infrastructure

Positioning: NVIDIA’s forward‑deployed/architect roles are closest to AI infrastructure and performance engineering. Instead of “which prompt?” the conversation is often “which GPU, which optimization, which deployment pattern?”

What they really test for:

• Strong systems & performance orientation

  • Comfortable reasoning about GPU utilization, batching, concurrency, throughput, and cost per token or per request.

  • Understanding of how model choices, quantization, and deployment frameworks impact latency and cost.

• Platform and ecosystem fluency

  • Familiarity with NVIDIA’s AI stack (CUDA basics, Triton, TensorRT, NIMs, etc.) is a strong plus.

  • Bonus points for comfort with multi‑cloud deployments and hybrid/on‑prem setups.

• Architect‑level customer guidance

  • You can sit with a customer’s infra team and co‑design reference architectures that fit their budget, latency needs, and compliance constraints.

  • You’re credible in conversations with both CTOs and senior infra engineers.

How to prepare for NVIDIA‑style FDE/architect interviews:

• Take an existing LLM application and run simple performance experiments: batching, caching, model size swaps; document how these affect latency/cost.

• Learn at least one NVIDIA‑branded component end‑to‑end (e.g., deploy a small model using Triton or a NIM‑style setup) and be able to explain the architecture.

• Prepare a “customer workshop” style narrative: how you’d guide a bank or telco from “we want AI” to a GPU‑backed architecture.

Current FDE open roles at NVIDIA

• https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite?q=Forward+Deployed+Engineer

New to Big Tech Careers? Join 26,000+ subscribers to elevate your tech career through behavioral skills!

Databricks: Data + GenAI + Enterprise Platforms

Positioning: Databricks’ AI Engineer / FDE roles sit at the intersection of data platforms and generative AI. Think “build AI on top of the lakehouse and ship it into customer workloads.”

What they really test for:

• Data engineering + GenAI hybrid

  • Strong skills in Spark, SQL, and data modeling, combined with hands‑on experience building RAG/LLM apps.

  • Ability to design retrieval over large enterprise datasets, not just a handful of PDFs.

• Platform thinking

  • You don’t just hack a one‑off script; you build reusable patterns that can be productized or repeated across customers.

  • You understand how feature stores, governance, and lineage matter for enterprise AI.

• Field engineering & enablement

  • You can work side‑by‑side with a customer’s data team, co‑building notebooks, pipelines, and MLflow/observability setups.

  • Strong skills in making complex architectures understandable through diagrams, demos, and “day‑2 operations” docs.

How to prepare for Databricks‑style FDE interviews:

• Build a full RAG system backed by a real data lake: ingest docs, create embeddings, store in a vector DB, expose as an API, and add monitoring.

• Practice telling the story of a data‑intensive project: ingestion → transformation → governance → AI feature → monitoring.

• Be ready to whiteboard how you’d integrate Databricks with a customer’s existing warehouse, BI tools, and downstream apps.

Current FDE open roles at Databricks

• https://www.databricks.com/company/careers/open-positions?department=Professional%20Services&location=all (search for FDE)

Salesforce: AI Agents, Business Workflows, and Enterprise “Last Mile”

Positioning: Salesforce’s AI FDE roles are deeply tied to AI agents and business workflows inside the Salesforce ecosystem. The emphasis is on customer outcomes, not just model sophistication.

What they really test for:

• Workflow‑centric AI design

  • You can map sales, service, or marketing workflows and decide where AI agents add value: drafting emails, suggesting next best actions, summarizing cases, etc.

  • You understand how to chain tools, data sources, and prompts into reliable “agentic” flows.

• Ecosystem fluency

  • Enough understanding of Salesforce platform primitives (objects, flows, Apex, integration patterns) to wire AI into real orgs.

  • Comfortable mixing declarative tools with code and external AI services.

• Elite customer‑facing skills

  • You spend a lot of time with business stakeholders: directors of sales, heads of service, program managers.

  • You can peel back the layers of “we want an AI bot” into root business problems and define measurable outcomes.

How to prepare for Salesforce‑style FDE interviews:

• Build an “agentic” AI prototype around a business workflow: e.g., an AI that triages support tickets and drafts responses while logging everything into a CRM.

• Practice explaining AI capabilities in pure business language: pipeline impact, CSAT, handle time, revenue lift.

• Prepare examples where you shaped requirements, pushed back on purely “flashy demo” ideas, and delivered something that actually moved metrics.

Current FDE open roles at Salesforce

• https://careers.salesforce.com/en/jobs/?search=forward+deployed+engineer&pagesize=20#results

Skill Map: How the Five Companies Differ

Here’s a simple way to visualize the emphasis areas. All five require all of these skills, but the “dial” is turned up differently.

Use this to target your preparation. You don’t need to be equally strong on everything to start; you need one or two companies where your natural strengths line up with their focus areas.

A 6–8 Week Targeted Plan for These Five Companies

If my earlier article was about “closing the general AI FDE gap,” this is the company‑specific version.

Weeks 1–2: Core LLM + One Deep Project

• Revisit LLM fundamentals and RAG.

• Build one serious end‑to‑end app and treat it as your “OpenAI/Anthropic case study”:

  • Backend API, basic frontend, RAG, observability, cost tracking, and a simple safety policy.

Weeks 3–4: Pick a “Platform Anchor”

Choose one based on your target:

• OpenAI: Build an end‑to‑end app on OpenAI APIs: for example, a customer‑support assistant with RAG over real docs, role‑based access, analytics dashboard, and basic safety/guardrail checks.

• Anthropic: Build a Claude‑based internal assistant (e.g., policy QA or contract reviewer) with an evaluation harness that tracks quality, safety failures, and red‑team prompts.

• NVIDIA: do a small performance‑oriented deployment, experiment with latency and throughput, document tradeoffs.

• Databricks: build a RAG system on top of a small lakehouse‑style dataset.

• Salesforce: build a workflow‑centric agent that automates part of a sales or support process (with a mock CRM if needed).

Weeks 5–6: Storytelling and Behavioral Prep

• Turn your projects into 3–4 crisp case studies: problem → constraints → decisions → results → lessons.

• Practice behavioral stories that highlight: discovery, production debugging, stakeholder management, expectation management.

• Tailor your resume bullets and LinkedIn to explicitly mention “AI Forward Deployed Engineer–style work” and name these companies as your target pattern.

If you already have SA/SWE experience, this plan is less about learning everything from scratch and more about relabeling and aiming the skills you already use daily.

The Bottom Line

AI FDE roles at OpenAI, Anthropic, NVIDIA, Databricks, and Salesforce are deep enough in AI and engineering to ship, and deep enough in customer reality to matter.

If you’re a seasoned SA or SWE, you’re already 60–70% of the way there. The remaining 30–40% is:

• Gaining AI fluency

• Picking 1–2 ecosystems to anchor on them (the focus of each of them is bit different)

• Learning to talk about your work through the lens of “forward‑deployed impact,” not just “feature delivery.”

  Thanks for reading FDE Hub! Subscribe for free to receive new posts and support my work.

When we onboarded our newest FDE at Lleverage, he was running his own client within two weeks. That’s not because we were reckless. It’s because FDE onboarding operates on a fundamentally different logic.

Ownership from day one

The core difference between onboarding an engineer and onboarding an FDE is that FDEs need to own things end-to-end from the very beginning. The unit of ownership isn’t a module or a ticket. It’s an outcome for a client.

The scope starts small, of course. A proof of concept. An extension to an existing solution. But even when the scope is small, the ownership is complete. You’re not fixing someone else’s bug. You’re figuring out what the client needs, how to build it, and how to deliver it.

When I started at Lleverage, my first two days looked like what we do when we begin any client engagement: gathering context. Meeting after meeting, absorbing everything I could about the sales process, the platform, the technology, existing customers, how the team operates. Two days of listening and asking questions.

On day three, a colleague from the sales team walked over. We need someone to run a PoC for a prospect. Can you pick it up? The demo was due in two days.

I said yes, obviously. You don’t join a role like this and hesitate when someone hands you a real problem to solve. But looking back, that moment was the best onboarding decision anyone made for me. It forced me to learn the platform not by reading about it, but by building something on it under a real deadline. I was paired with someone who could show me the basics, give me that initial push, and then I had to figure the rest out.

By the end of my first week, I was already picking up existing clients, maintaining their solutions, and starting to think about where those solutions could go next.

The layers underneath

What makes FDE onboarding uniquely dense is the number of dimensions you’re absorbing simultaneously. It’s not just “learn the codebase.” There are distinct layers, and they all matter.

There’s the platform itself: how you build on it, its capabilities, its constraints. There’s the project management side: how we track work, communicate progress, manage timelines across multiple clients. There are the clients themselves: their industries, their systems, their stakeholders, their particular expectations. And then there’s the internal layer: how the team works, how decisions get made, what the culture around quality and pace looks like.

A software engineer might absorb these layers over months, one at a time. An FDE has to take them all in more or less at once, because the moment you sit in a client meeting, all of these layers are active.

Calibration, not probation

When our newest FDE joined a couple of months ago, we followed the same instinct. He shadowed me on an existing client for about two meetings. Then he started picking up tasks. Within two weeks, we’d done the full knowledge transfer and he was in charge of that client relationship. By the end of his first month, he’d taken on a completely new client from scratch. He’s now onboarding with a third and fourth in his second month.

That pace might sound aggressive, but it reflects something important about how we think about onboarding. If you’ve done the hiring process right, you should be at least 95% confident that this person can do the job. The hiring process itself, its entire purpose, is to establish that baseline.

So the onboarding period isn’t a trial. It’s a calibration. You’re not figuring out whether someone can do the work. You’re figuring out how quickly you can increase scope, how soon they can handle bigger clients, more complex projects, more simultaneous engagements. The approach is to stretch people relatively quickly, to find out where their ceiling might be, without actually pushing them to a breaking point. That’s very different from the cautious approach of holding back responsibility because you’re worried about overloading someone.

Our newest hire came from a technical background, fresh from university but with a couple of years of building his own companies behind him. The entrepreneurial experience was a strong signal: someone who’s built products, talked to customers, handled the pressure of making things work with limited resources. That profile told us a lot. It was just a question of how quickly he’d adapt to this specific context. He adapted faster than we expected.

Staying close

How do you actually monitor all of this without micromanaging? For us, it starts with regular check-ins. Bi-weekly conversations between mentor and mentee, in addition to the normal managerial ones. Those check-ins are a mix of practical and personal: how are you feeling, what’s blocking you, but also let’s talk through this specific client situation.

Beyond the structured check-ins, physical proximity matters. I don’t mean this in a “remote work doesn’t work” way, plenty of FDE teams operate remotely and do it well. But in our case, sitting next to each other in the office made a real difference. I told my mentee early on that I don’t mind being interrupted. That I’m available for questions whenever they come up, within reason, but that it has to come from them.

That last part is deliberate. I’m not going to chase someone down and ask if they need help every hour. I make myself available, I show that I care, and then I let them come to me. There’s a practical reason for this: I have my own clients and my own work. But there’s also a diagnostic element. A big part of the FDE role is asking questions. When you’re with a client, you need to ask constantly, probe, clarify, push back on assumptions. You should never be embarrassed to say “I don’t understand, can you explain that again?” If someone is hesitant to ask their own mentor for help, that’s a signal. It might mean they’ll also hesitate to ask the client, and instead build something based on what they think they understood rather than what actually needs to happen.

In the early days, I sit in on client calls so the new FDE can shadow. One or two calls to observe the dynamic, understand how we communicate, see how conversations flow. Then they start taking over gradually: leading parts of the call, then running the whole thing while I observe, and eventually handling it independently.

The KPI through all of this isn’t code quality or technical elegance. It’s whether the client is happy and the solution is delivering value. That’s what’s measurable, and that’s what matters. If the solution works and the client sees results, the code behind it is secondary.

The gap we found

If I had to identify the one thing we got wrong, it’s that we didn’t spend enough time walking through existing solutions.

When I started, I got a broad overview of what was in production: the different clients, the different use cases, the general landscape. But the emphasis was, rightly, on the clients I’d be taking over. With our newest FDE, we did even less of this. We jumped straight into client work, gave him context on the solutions he’d be owning, and moved quickly.

It worked, but in retrospect, we left something on the table. There’s real value in sitting down with a new FDE and walking through a range of completed and in-progress solutions. How we typically collect data. How we handle integrations that aren’t native to the platform, where we’re relying on HTTP requests. How we move from development to production. How we manage credentials. When we use LLMs versus structured workflows versus full agentic setups.

These are patterns. And you only develop an instinct for them by seeing enough examples. Our mentee said it himself: seeing more of the existing work earlier would have accelerated him further. He was already moving fast. But that kind of pattern recognition, knowing that “oh, this new client’s problem looks a lot like what we already solved for another client,” saves real time and produces better solutions.

If I were redesigning the onboarding, I’d keep the same structure of short, focused sessions spread across the first week, anywhere from one to two hours each, covering different aspects of the platform, the solutions, and the workflow. But I’d add a dedicated track that walks through the architecture and patterns of existing solutions, not just the ones the new FDE is picking up. And I’d leave room between those sessions for them to explore on their own, to identify their own gaps and focus where they feel weakest.

When I started, for example, I was coming from six years of working directly with enterprise customers. I was confident in how I communicate with stakeholders, how I run meetings, how I manage expectations. But I was rusty with coding and building. So that’s where I put my own focus in those early days. Everyone’s profile is different, and the onboarding needs to accommodate that.

Good enough is good enough

One more thing that’s important to instil early, especially in a startup environment, is the idea that things need to be done well but not perfectly.

Every good engineer has high standards. That’s a feature. But in an FDE role, those standards need to be in service of the client’s outcome, not your own sense of craft. Sometimes you ship something that you’re not 100% happy with. The architecture isn’t as clean as you’d like. The edge case handling is functional but not elegant. If it’s delivering value to the client and it’s working reliably, then it’s good enough. Chasing perfection at the expense of pace is a luxury that FDEs, particularly in a startup, can’t afford.

This doesn’t mean you cut corners recklessly. It means you develop judgement about where the bar needs to be high and where good enough genuinely is good enough. That judgement, like most FDE skills, comes from exposure and repetition.

Still figuring it out

I’m not presenting this as a finished playbook. We’ve onboarded exactly one new FDE at Lleverage, and my own onboarding was only about nine months ago. The sample size is small. But the principles are becoming clearer with each iteration: ownership early, scope that grows based on calibration, proximity and availability, pattern recognition through exposure, and the confidence to stretch people when you’ve hired well.

I know a lot of FDEs read this newsletter, and I’m genuinely curious how your onboarding looked. Whether you were thrown into the deep end or eased in gradually. Whether your team had a structured process or figured it out as they went. And for those of you who lead or mentor FDEs, how you think about shaping someone into this role. I’d love to hear about it in the comments.

You studied CS and Applied Maths at Berkeley, went to Harvard Business School, spent five years at Palantir, and now you’re investing at Emergence. That’s a lot of different seats. How did FDE lead to venture?

When I was at Berkeley, the rite of passage for anyone studying CS was to go be a software engineer at Google or big tech. I had interned there and I didn’t really enjoy it. It was slow. The scope of your work tends to be very limited.

What excited me about Palantir was that I’d be responsible for spending time with customers, scoping out what they’re trying to do, and then just going and building it myself. A lot of the value came from hearing how customers were trying to do something with the product and where it failed, and then literally building something in the next two days and showing it to them. Sometimes completely from scratch. At that stage of my career, that felt like a really good learning opportunity for someone who wants to maybe one day start a business.

After five years, I went to HBS looking to start a company. I played around with a few ideas, and in that journey I met a bunch of VCs. I was a scout for a fund called Contrary, got a chance to intern at Notable Capital for about eight or nine months. During that period, I just enjoyed the day-to-day work enough that I ended up wanting to do it full-time.

There are trade-offs. When you’re deeply embedded in a specific problem as an engineer or PM, you only think about that one problem. You think about all the things that could go wrong and everything you need to fix to make it work for a customer. As an investor, you don’t get that depth. But the entire job is meeting really smart people and hearing about how they view the world and how they want to shape certain problems. The energy I got from that was enough to compensate for the lack of depth.

Kabir also spent time as a product manager at Verkada and in engineering roles at Amazon. I asked how those stints in more traditional product and engineering organisations changed his view of the FDE model.

Did those experiences show you that FDEs have gaps compared to traditional product managers, or that they have advantages?

It’s definitely an advantage. I started doing product work while I was still at Palantir, towards the end of my time there. A big reason I was able to do that was because I’d spent so much time actually building parts of the product and hearing across many different customers and verticals how they used it. That helps you inform your intuitions about both how to build and what to build.

Verkada was a slightly different experience. Product is not as tightly coupled with engineering there. You only think about what you want to build, not necessarily how to build it. For my personality and background, I had a lot more fun in the Palantir style of doing product, which was much more tightly coupled with FDE and core software engineering.

But there’s also a disadvantage. The biggest thing I felt as a PM was a natural inclination to overfit to a very specific customer’s feature requests. That inclination is probably fine at a business like Palantir, which has a couple of hundred customers that tend to be very large. You benefit from overfitting to what those customers want.

At a business like Verkada, which has many more, smaller customers, you have to be more disciplined about which features and workflows you actually support. I remember speaking to a customer that was not very large and I started scoping out exactly how we’d build this one thing they really wanted, something highly specific to them. My manager told me, why are you doing this? It doesn’t make any sense. We need to make a business case. We need to decide where this fits from a priority perspective. That was a good lesson.

Kabir’s FDE background now shapes how he evaluates founders. At Emergence, he’s drawn to companies that look messy early on, the ones doing hands-on, customer-specific work before they’ve figured out the product. I asked how he tells the difference between a smart path and a dead end.

Your bio at Emergence says you love founders who do what might initially look like unscalable things to solve customer problems. That’s basically the FDE job description. How do you distinguish between a founder doing unscalable things as a path to product versus one who’s just building a services company that won’t scale?

You can’t scale what you don’t know. Early on in a company, it’s pretty natural to be doing unscalable things.

If you’re primarily serving enterprise customers, doing unscalable things is actually really good because it buys you a level of trust with users that is very hard to get otherwise. If I’m a young person selling to a large Fortune 500 company, I’d be very lucky to get my foot in the door. If during the pilot I severely constrain the set of things I want to do relative to the set of things my users want me to do, it gives me less opportunity to build trust. And with enterprises, you want trust to expand within them over time.

Of course, it’s important to productise in some shape or form. You don’t have to productise the external thing, at least not early to mid-stage. But it is good to be productising the set of primitives you see come up again and again, at least internally.

As an example at Palantir, even when I was there, Foundry was relatively nascent. FDEs would build custom front-ends to support very specific workflows and applications. In maybe a year and a half to two years, a lot of what FDEs had built across deployments provided learnings into what a more generic application builder could look like. One that actually works well, because there were a ton of other application builders in the market that couldn’t do very specific things, like allowing users to configure complex business logic beyond simple SQL queries. That kind of stuff could not have come without the “unscalable” work.

Today, with AI coding tools, the road you can travel doing unscalable things can go a lot further. If you want to build custom applications, custom React front-ends, you can do them a lot quicker with tools like Claude Code. That can incentivise founders to keep the services journey going very long.

But it’s still important to try and productise, because every moment you spend building or supporting something customer-bespoke distracts you from building the thing that’s eventually going to be your product. At a minimum, internally, founders should be productising the set of primitives they see over time.

This naturally led us to a question about defensibility in a world where building is getting easier by the day.

If it’s easier than ever to build things, what counts as a moat?

Brand and trust. That as a moat has not changed. You tend to look for whether there’s a lot of customer love. Even if it’s easy to build things, not every product will have tons of customer love. Are users going to be super sad if this product was ripped out? If it became 5x more expensive?

You do see a real bifurcation. Today, there are a bunch of coding tools. But people are still spending thousands of dollars every month on Claude Code, on those really expensive tokens, even though there might be cheaper tools out there.

Where you have to be careful is investing in companies that are very thin layers over the model. You have to look for what level of depth they’ve actually gotten within an industry or a workflow.

Towards the end, Kabir brought up a topic I hadn’t planned to ask about. Historically, VCs have avoided services businesses because of thin margins and slow growth. He’s seeing that change.

You mentioned AI-enabled services businesses as a real opportunity. What’s shifted?

The thing most people point to about services businesses is that the gross margin profile is not there. Most services businesses tend to be 25 to 35% gross margin, whereas software has historically been 70 to 80%.

I would push most founders to think about that, because you can probably get to the 60s or even 70s. There are startups in the Valley that have been able to get to 70-plus percent gross margins offering purely a service.

The trade-off between product and services doesn’t actually have to be as explicit as we historically believed. For a lot of industries, like accounting or healthcare, the cost of mistakes is so high that customers want a human in the loop. There is still an opportunity to build a true venture-scale services business that is more enabled by AI. There are already examples, including some companies in our portfolio like Strala, that are taking this approach where they’re not selling product, they’re selling a service.

Founders should not shy away from that.

I had one last question. Many FDEs eventually start their own companies or move into product. Kabir has done both. I asked what he’d tell FDEs thinking about what comes next.

You’ve been an FDE, a PM, and now an investor. What advice would you give to people entering the FDE role, or FDEs thinking about their next step?

It’s probably the most exciting time to be an FDE because there’s so much more you can actually do for more customers with the tools being built today.

From a core advice perspective, the job of an FDE is evolving. A lot of companies outside of Palantir would structure this role historically as someone who does configurations and integrations. Every FDE should be thinking hard about how they can shape the product. They are the people providing the most direct signal and feedback. A key thing that sometimes gets missed about the FDE model is that the reason you have deployed teams is not just because the product doesn’t work. It’s about finding more use cases to tackle, more users to enable.

For people thinking about what’s next, FDE is becoming more of an independent function. You can be a true head of deployments at your company. If that’s not the direction, starting a company is a great option. Product is a natural progression too, but honestly those roles are converging. A lot of what you’re already doing is spending time with customers. You are already shaping product and doing product-style work.

I’d even say that going into core product engineering is a strong path. That used to be the most common move at Palantir. People who’d been there a long time would build stuff in the field, then build a more generic version of it that would be used across the fleet of customers. Pretty much all the best engineers at Palantir across the years were former FDEs.

Kabir Sial is an Investor at Emergence Capital.

The client was still in touch with the original builder, so they shared the contact and I got on a call with the guy. Nothing dramatic, but every piece of logic, every business rule, every edge case in that system lived in one person’s head. If he’d moved on or been unreachable, there was no project. The AI was perfectly capable. There was just no door to walk through.

The agent works. The system it needs to talk to does not. These systems were never designed to be talked to by an agent. They were designed for a person who already knows how everything works.

The distance between what an agent can reason about and what it can actually access and act on is the context gap. Right now, it’s the single biggest bottleneck in enterprise AI.

Demos are easy. Integrations are not.

Building an agent that can read a sales order and extract line items is a weekend project. Building one that can take that sales order, match it against the right customer in an ERP, check inventory across three warehouses, apply the correct pricing tier, and book it into the accounting system with proper GL codes? That’s months of work. And most of that time isn’t spent on the agent itself. It’s spent getting access to the systems around it.

Another client, a wholesaler, ran an old on-premise version of Business Central. Getting a connection required weeks of back-and-forth with their implementation partner over firewall restrictions, whitelisted IPs, and specific port configurations. Once we finally had access, we discovered the system had been customised with internal actions and triggers that nobody fully understood. We’d call a seemingly straightforward endpoint and something unexpected would fire in the background. Weeks were spent mapping undocumented behaviour that only revealed itself through trial and error.

This is the reality across almost every deployment. APIs are undocumented or don’t exist. Every customer’s setup is customised in ways that generic documentation doesn’t cover. And the people who originally configured the system have often moved on.

System archaeology

When documentation doesn’t exist, you discover the system yourself. I’ve started thinking of this as system archaeology. Software archaeology is an established concept, but what FDEs do in the field is a specific version of it.

In practice, it looks something like this. You hit an endpoint that returns all available objects. You fetch a thousand of them and immediately you’re looking at field names that only make sense if you’ve worked in that specific industry for a decade. This is where an LLM becomes genuinely useful. You feed it the response and it helps you interpret the data, connect the dots between cryptic field names and domain concepts, and start mapping the structure of what you’re looking at. You filter by type until you find the ones you actually need, often going back and forth with the model to make sense of what each type represents in the context of the client’s business.

Then you need to learn how to create that type. So you start with the absolute minimum number of fields and try to post an object. It fails. The LLM helps you build the next request and interpret the error in context. You add fields, try again. Eventually it succeeds, and you check what you’re missing compared to what a properly created object should look like. You iterate until the object looks right.

That gets you basic reads and writes, and through most of that process the LLM is a genuine partner. But the real complexity shows up when you need to figure out how to perform actions. Creating an object is one thing. Triggering the right downstream behaviour, posting it to a ledger, moving it through a status chain, firing the correct workflow, is another entirely. At that point the LLM can only really help you verify what happened, and verification itself is hard. You’re checking whether the system ended up in the right state, often across multiple tables and processes, with no specification to compare against. That’s where the undocumented behaviour lives. That’s where the system does things nobody told you about, because nobody remembered it did them.

Fetch. Interpret. Request. Validate. Repeat.

It’s painstaking work, but it’s the work that actually gets an agent into production, and no amount of model improvement will eliminate it. The problem isn’t the agent’s reasoning. The problem is that the context the agent needs is locked behind firewalls, buried in legacy databases, or sitting in the head of an operator who’s been doing the job for fifteen years.

Where this leaves us

Companies have access to the most capable AI models ever built, and most of them are still running on spreadsheets, disconnected tools, and manual processes. The gap between what the models can do and what the systems around them allow remains enormous, and nobody has done the work to close it.

I think the instinct for a lot of companies right now is to look at AI as a way to leapfrog the infrastructure problems they’ve been ignoring, to automate the messy process and let the agent figure it out. But AI is not a magic cure for undermaintained systems. If anything, it makes the mess more visible. The moment you try to connect an agent to a process, you discover exactly how undocumented, fragile, and human-dependent that process really is.

The organisations that get real value from AI will be the ones willing to do the unglamorous work first: mapping the processes, connecting the systems, documenting what was never documented, and building the doors before expecting agents to walk through them.

The question I keep coming back to is simple. How many companies are prepared to do that work? And what happens to the ones that aren’t?

You might have noticed I went quiet for almost ten days. I spent a few days in San Francisco, attending meetings and delivering a talk at the FDE Conference, organised by Nixo, Rippling and ElevenLabs. Between the travel and the talk prep, I decided to skip a week rather than rush something out.

This week, I want to share what I talked about. The talk was called “The Champion Trap,” and it’s based on a pattern I’ve seen across roughly 20 client engagements so far. The pattern is simple: the person most excited to work with you is often the one most likely to send you in the wrong direction.

That sounds ungrateful. It’s not meant to be. The champion is usually someone incredible. But there’s a gap between knowing what a team does and knowing why they do it the way they do it. And that gap will cost you months if you don’t catch it early.

Let me walk you through how I learned this.

The setup

Global customer. A major music label with offices across the UK, US, and the Netherlands. The project: accounts payable automation.

On paper, accounts payable doesn’t sound too complicated. But their suppliers are music artists, and artists are not always comfortable with invoicing. Formats ranged from proper PDFs to handwritten notes, Word documents, Excel files, things that barely qualified as invoices at all. Tens of thousands of suppliers. 150 possible approval paths across seven levels of hierarchy.

One invoice sticks with me. We flagged it for a missing purchase order number. The operator reached out to the creditor and asked them to add it. They sent back a revised invoice. We processed it, flagged it again. The purchase order was still missing. I double-checked. They had literally typed the words “purchase order” on the invoice instead of providing the actual number.

That’s the kind of territory we were operating in.

We had a champion on the client side, and she was excellent. This project was her top priority. She was available, responsive, senior enough to make decisions, and deeply motivated to get it done. Every instinct said: this is the person to build with. This is the person who’s going to get us to a solution fastest.

We spent two months building the solution with her.

Death by a thousand details

Then we gave it to the operators.

It wasn’t one big dramatic failure. It was dozens of small things. Operators were changing data directly in the ERP that we didn’t know about, which meant we needed two-way sync instead of the one-way push we’d built. The approval process ran on a spreadsheet that had been growing for over a decade, with paths and exceptions nobody had fully documented. We’d built around how accounts payable should work, not how it actually did.

There were hidden workarounds everywhere. Dozens of micro-decisions per hour that the champion had never seen, because she didn’t do this work every day. The operators did.

And because this was finance, there was no room for partial wins. Either the invoice books correctly, or it doesn’t. There’s no “almost right” in AP.

The champion wasn’t wrong about anything. She genuinely believed she knew how the process worked. But there’s a difference between overseeing a process and living inside it, eight hours a day, handling the exceptions and edge cases that never make it into a summary.

The cost

Two to three months of redesign. The AI worked fine. We’d just built with the wrong person’s understanding.

Two mistakes in one project. First, we built with the champion’s version of reality instead of the operator’s. Second, we tried to automate a broken process instead of simplifying it first.

We spent months building infrastructure around that ten-year-old approval spreadsheet, faithfully replicating every path and exception. When we finally pushed back and said this is going to take longer and be harder to maintain if we cover every path, they realised the process could be significantly simplified. The framing that unlocked it: faster delivery, easier maintenance. Everyone wants both.

The project is in a much better place now. But those extra months were the tuition fee for a lesson I won’t forget.

Right customer, right stage

Four people matter in every FDE project: the sponsor, the champion, the operator, and the FDE. Each one is essential, but at different stages.

The sponsor unlocks the deal in pre-sales and approves expansion at the end. During the build, they just need updates.

The champion gives you context and vision. They’re invaluable during pre-sales and for alignment checks throughout. But their role during the build itself should be periodic check-ins, not daily collaboration.

The operator is where the real knowledge lives. They should be your primary partner during scoping and the build phase. They hold the “why” behind every workaround, every exception, every process that looks irrational from the outside but makes perfect sense when you understand the constraints.

Champions know what the team does. Operators know why they do it the way they do it. If you only have the “what,” you’ll build something that looks right but doesn’t work in practice.

What it looks like done right

Different project, different client, different approach. Sales order processing.

This time, we pushed hard from the very first call to get connected with the operators. Before the deal closed, before scoping was even finished. We did a thorough discovery call where we actually mapped the process before signing anything. At kickoff, we confirmed everything with operators from day one. No assumptions from the sales phase carried over unchecked.

Then we built fast, iterated with operators synchronously and intensely, and delivered in six weeks from first contact.

The difference wasn’t that we built faster. It’s that we knew who to sit with from the start.

This part is worth being honest about: operators are not always eager to work with you. There’s real fear around AI. People wonder if you’re there to replace them, restructure their role, or hand their job to a machine. I’ve been fortunate that in almost every engagement I’ve worked on, the company’s intention has been to free operators from repetitive work and give them more meaningful things to do. But the operators don’t always know that when you first walk in. Earning their trust, warming them up enough to share how the work really gets done, that’s part of the job. Maybe the most important part.

The closing thought

This matters more now than ever. AI is getting better at the intelligence layer. It can process invoices, route approvals, handle data entry. But the “why,” the judgment, the decision-making, that still lives with the people doing the work every day. And the only way to get it is to be in the room with the people doing the work. With them.

Every project has someone eager to help you build. The hard part is finding who knows how the work gets done.

The value of an FDE isn’t building faster. Tools are making building easier every month. The value is knowing who to sit with. And it’s almost never the person raising their hand.

You founded a company at 21 and raised from Tim Draper before joining Palantir. How did building your own thing change how you approached FDE work, and did FDE teach you anything you wished you’d known as a founder?

One of the things I learned that was really helpful, and the reason I liked FDE work, is that working directly with customers is really important. It shapes how you build product. You get real feedback in real time and you can improve very quickly.

As a founder, you have to be very customer-obsessed. Your whole business will win or die based on whether your customers like working with you and your product. That’s the biggest learning I took away from building a startup: how do you care about your customers, how do you listen to their feedback, and how do you build from there? That’s directly why I went to Palantir.

When I first joined, I was 24, and I was leading engagements for one of the top auto manufacturers in the world. We would go to the factory in Toledo and see how they’re building cars to understand their processes. You quickly learn it is all powered by people. You’re talking to the guy putting the mirror on the car. You’re talking to the people in charge of ordering parts. These are all real people that run these positions.

How do we build their learnings into a system that they can use to become more efficient? That’s what FDE is about. Working with very smart people in their own domain and taking their learnings to build a product at scale.

You wrote about spending months on factory floors in Toledo. What’s the difference between an FDE who shadows well and one who doesn’t?

A lot of it comes down to being very curious and very patient.

Think of anything you’re really good at. You’ll explain it very quickly because it’s so obvious to you. When you work with people that are domain experts in their own field, like manufacturing, they have been doing it for 25 to 30 years. They’re going to explain it the way they do it every day. You have to go slow with them, watch it all, take it in.

It’s actually a lot like what’s happened with AI. You have to treat your AI like it doesn’t know anything, and then slowly give it context over time for it to be effective. When you’re ramping up as an FDE and working with a customer, they’re the domain experts providing you the context. You’re the person who knows the platform best. You’re trying to figure out how to use the context provided, the platform, and your skill set to help them build something scalable and useful.

I spent almost three months in Toledo. Every week I’d fly in from New York, drive an hour south from Detroit, and spend the whole week there in person with them. Who’s the person in charge of ordering parts? Who runs the shop floor? What systems run the shop floor? How do they identify defects? Mapping a system like that is intense, but it’s something you need to do.

The reason you go into the field, to the customer, is so you can build enough domain expertise to have an opinion about what to build. It’s really hard to have an opinion about what to build when you haven’t done the work or don’t understand the details of how it works.

I asked whether it’s more beneficial to already have domain expertise or to come in fresh and learn fast.

It can work either way. What’s nice about having no context is you have very fresh eyes on a problem. A lot of great innovation comes from something outside the field being brought in. It transforms it completely.

But it depends on what you’re trying to do. If you’re focused on moving fast and executing, having the domain expertise is super helpful. Even at Sierra, as we work with large financial institutions or healthcare providers, those have a lot of complexity. If you want to be effective on the team quickly, you really need to understand those businesses.

It also depends on the domain. You definitely can’t vibe code your way through a healthcare product.

You converted 100% of your pilots at Palantir, three out of three in six months. What did you learn about what makes a pilot convert versus die?

One of the things I like about Sierra is that all of our proof of concepts are in production. We’ll work with our customer to get into production during the POC. It’s not just vaporware or a demo. I think it’s worth pushing for being in production to show tangible value.

At Palantir, what we saw was you need to be building something that’s going to be operationally critical for the business. If it’s not something that’s going to be in production and actually drive meaningful results, the likelihood of it replacing the existing solution is low, because they already have some way of doing it today. It’s just not the most efficient or scalable.

So you’re asking: is the solution I’m going to build for you 10x better than what you’re currently doing? If it is, it’s worth it. And in those scenarios, you have to take what you’re learning from the team on the ground and build it into something that can really transform the organisation.

You were at Palantir for about a year as an FDE, then moved into enterprise lead roles. What made you step back from the hands-on work?

The roles are relatively similar. When you first join Palantir, you’re going to work on an account. You’ll join an existing team and own a single workstream with an engineer. That’s the best way to learn the platform, get into the weeds, and build out that first use case.

Over time, you start to lead engagements. An enterprise lead is really about thinking how to build an account, help customers build products, expand, and figure out what else you can solve. It transitioned naturally for me. I started working on manufacturing, which is why I spent so much time in Toledo, then graduated to running the whole account, which covered safety, manufacturing, and real-time sensor based alerts.

The thing that’s very unique about Palantir is there was no concept of levels. No IC3 or whatever the traditional tech company structure is. You’re always just Echoes and Deltas. Echoes being deployment strategists and Deltas being forward deployed engineers. In that model, you’re driven by new scope or new problems, not career climbing.

If I was an IC5, I wouldn’t really want to go work on a two-man pilot. That’s a totally different scope. But Palantir’s flat organisation meant you could flex between different things. I went from manufacturing to airlines to financial services to government. I think that’s why people stay at Palantir for a very long time. You can work on so many different types of problems with the largest organizations in the world.

Personally, I always suggest people should optimise for learning and growth. Instead of staying on a large manufacturing account, I decided to work on small airlines, then moved to work in government, before working almost exclusively on pilots for six months. Can we win this deal in six to twelve weeks? That’s very different from spending a year building what was promised after the POC.

At Sierra, you’ve reframed FDE as “Agent Development.” Is that a genuine evolution of the role, or more of a rebrand?

Agent development is a much faster iteration cycle. Everything’s moving so fast with AI that it’s changed so often.

FDEs are still growing. Salesforce is planning to hire a thousand. I don’t think the role is going away. It just depends on how you think about building.

In a lot of cases, FDEs were building relatively bespoke applications on top of a platform like Foundry. Each use case is slightly different and needs to be built with components, like a dashboard or an application with alerts. You’re building within the Foundry ecosystem.

With agent development at Sierra you have a platform called the Agent Operating System, and it’s used specifically for building AI agents. You’re not building dashboard-style applications. You’re building agents, and agents are the core point of interaction across the company.

Why it’s different is you’re iterating so much faster. A customer in retail wants a “where is my order” agent. You work with them to build it, but you’ve already done that a few times. The platform knows how to build it and can be used to build it in a scalable way. The product and the outcome are more closely tied.

I asked whether a platform is almost necessary for the forward deployed model to scale.

In most cases you need a platform to leverage. The best FDEs are very smart individuals with strong technical understanding, you need to give them a set of tools. A platform is a pre-set-up set of tools to build with.

The problem with FDEs in a fully bespoke world is you’re building zero to one every single time. That makes it really tricky to have something reusable across companies or to capture learnings beyond the individual’s experience. I can’t take something I built fully custom for one customer and immediately apply it to another. But if I have a platform where I built an order lookup, I can use that again. I can generalise it as a PM and take those components into the platform so it works with another customer.

I asked about the team structure at Sierra and how engagement lengths have changed.

The speed is much faster now. At Palantir in 2017, you probably had six months to a year to build something very complicated. Now most of the time you’re building something meaningful in three months or less and iterating quickly. And with AI leverage in the current market, everything is so much faster. The iteration speed is days and weeks. We’ll often ship new agents to customers within the first week of engaging with them.

The way we’ve structured the agent development team is three roles. Agent engineers are in charge of building high-quality agents, scaling, infrastructure, everything that goes into traditional engineering work. Agent strategists are similar to deployment strategists, they own the account, its success, and growth. Then there’s the agent PM role, which is unique.

Almost every PM I’ve worked with at Sierra has the skill set to be a founder. They’re technical, they know how to engage with customers, they can think about scope, they have good EQ to engage with VPs. They also think through the strategy of the account. That’s a very interesting skill set. It’s basically why Palantir people all went and started companies.

The PMs are really in charge of taking learnings from customers and building those into scalable products that all deployments can use. Strategists are more focused on the individual account.

Where’s the biggest bottleneck in the deployment lifecycle? From my own experience, it’s discovery. Most customers don’t know what they want, where the biggest value is, or even how their own processes work.

That’s very common across the board. A lot of our discovery and pre-sale work is run by sales and sales engineering. The agent development team gets pulled in later, though we’re starting to be more exposed to the discovery part.

You’re going to approach it one of two ways. Either you work on a very hard, meaty problem right from the start, which is what Palantir used to do, because you can show value quickly if it’s real. We tend to focus on those kinds of problems at Sierra too. What is your hardest problem? What are your highest volume issues?

But in more regulated or structured environments like healthcare or banking, you might start with something smaller in scope just to show you can get through the procurement process and all the hand-holding to go live. Then you expand from there.

You still have to prove value, though. There’s no scope small enough that’s going to be useful if it’s just AI tourism. “We just want to see what this is, but we don’t really have any interest in going into production.”

There’s been a shift in the past year and a half. Initially enterprises were jumping in to experiment with AI, but now finance and legal are involved much earlier. How has that changed how you approach engagements?

I think Databricks is doing a really good job of this. Their net dollar retention is increasing. They’re growing the account. Even at Palantir, a lot of the biggest accounts were accounts that compounded over time. You started something smaller at Airbus, but then the account just grows because there’s so much more you want to do.

The nice part about forward deployed work in general is you build a lot of trust with your customer. They see you as an extension of their team. You’re not billing by the hour. It’s not consulting. They’re buying the software, they’re working with you. When they see you as a real partner for their AI adoption, they give you access to harder and harder problems.

But initially, in a POC, you’re going to get hard problems, but maybe not the hardest problem. Those require a lot of trust building. It’d be silly for a bank to give you their hardest problem on day one. Those are things you have to build towards. That comes from showing up really well, building trust, becoming a partner.

You’ve been an FDE, an enterprise lead, a founder, and now a product manager at an AI company. If someone’s a strong FDE today and wondering what’s next, what would you tell them?

One of the best parts about FDE work or agent development, anything where you’re working directly with customers and building things quickly, is you’re just very good at a lot of things. I used to joke with my friends at Palantir that Palantir did a really good job of building really smart generalists. Everyone was good at pretty much everything, but they had really strong spikes in certain areas. Customer work, technical ability, strategic thinking.

It’s worth knowing, even within the FDE role, what you gravitate towards. Do you enjoy doing the discovery work with a customer and understanding what the scope should be? A lot of people go into sales engineering roles from there. If you like the actual building and infrastructure side, you can go into building infrastructure products. If you’re drawn to working with customers, a lot of Palantir people went on to run their own FDE shops or consulting companies, operating as an enterprise lead across multiple accounts.

I went into product because after Palantir, where you over-index on a customer, which is the right approach, I wanted to try something different. Can I build a product that compounds over multiple years? At Dune, we built a public data platform housing hundreds of blockchains worth of data, petabytes of it. Very different from the customer-focused FDE work.

I always tell younger people: you don’t really know what you don’t want until you do it. You always think you know what you want, then you do it, and you realise it’s not quite right. But right now is a great time. If you’re learning about AI tooling and building and exploring, you can do so much. You can basically pick your future based on what you want to do.

Niles Lawrence is an Agent Product Manager at Sierra.

You built Retain.ai over five years, then founded Stork Network, and then went to lead FDE at Baseten. Most people in FDE go the other direction, they start as FDEs and then start companies. What pulled you toward leading an FDE team after running your own companies twice?

I think there’s a very big overlap in skills between FDE and founders. The simplest way to put it is building things constrained by the commercial environment. FDEs learn that because they show up and there’s a clear outcome they’re building towards. They’re on sales calls, getting exposed to commercial considerations. A typical engineer doesn’t get exposed to that. Even a typical product manager doesn’t get exposed to that.

When the Baseten opportunity came along, the framework I used was impact. I saw a solid adoption graph going up and to the right. And I saw a place where I was uniquely positioned to impact thousands of customers because the shape of the team made sense to me based on my experience as a founder.

There’s also something very attractive about already having product-market fit. A lot of founders I know alternate. First they do something that’s pre-product-market fit, then they pick an idea where they have a very clear fit and it’s more about commercialising. I think this was an extreme version of that. You’re coming in, there’s already a product, there’s product-market fit. It’s about reiterating on that last step repeatedly and refining the product, while focusing on process, team, etc.

But you actually said no at first.

I did. I did not believe, having seen similar roles at previous companies before they were called FDE, that it could create truly durable technical artifacts. I always had this hunch that calling it something technical is just a euphemism to attract talent. And then in practice, it’s such a commercially driven thing that any sense of autonomy gets overshadowed by commercial needs.

I actually called a friend who used to run a similar team at a previous company. I asked him, do you think there’s a way to make this team truly technically empowered? He was skeptical, but out of that conversation came a list of prerequisites that I took to the Baseten founders for what I think would be required for success. Fortunately they were 100% on board.

You’ve now had six months of distance from Baseten and you’re advising multiple startups. What would you do differently if you were building an FDE function from scratch?

I don’t know that there were massive things I would do differently at Baseten if I were building that team again. There are small things.

The challenge for me personally was often forming enough belief in something so that I do it with absolute conviction. One example: in the first four to five months, hiring was brutal. We had a philosophical principle that any person who can join the FDE team should be able to join any other engineering team at the company. The technical bar should be the same. It should really be a matter of interest, that they want to work on this type of problem.

Until we hired the first two people that met that bar, there were many times I was wondering if we’d ever find them. If there was something we needed to change, if we needed to be less strict. If I were to go back, I would just tell myself it’s going to be okay. There’s a virtuous cycle that kicks in. It’s standard pipeline stuff where eventually enough things click.

But if I was starting an FDE team at a different type of company, the non-negotiable is you always want an FDE who is motivated by accelerating the customer to impact. You screen for that. Beyond that, you pick the attributes you want to augment with. Do you want them to be very technical? Do you want them to have past experience working with customers? Do you want them to have sold into an enterprise before? Do you want them to be really organised because they’ll be doing many of these at the same time?

That’s an important decision because hiring FDEs is hard. And you can’t optimise for everything at once.

When it comes to hiring, I’ve heard two schools of thought from FDE leaders. One group hires people who are seven out of ten across many things: product, engineering, customer communication, leadership. The other group hires people who are exceptional at one thing and then moulds them in other areas. Which was your approach?

It goes back to the conversation from the beginning: what kind of FDEs are you hiring for? If they’re enterprise FDEs and they need to be great at navigating an org or knowing when to take a client out to dinner, I think it’s okay to screen for that during the interview process.

For us, the main thing was that our customers were L6 engineers or equivalent. Very senior staff engineers. Our FDEs had to be able to go in front of top-tier engineers and prove they were at least as smart when it came to inference. That was the bar.

Sure, I also wanted them to be good communicators. I wanted them to keep an engagement going. I wanted them to have enough product intuition to ask, wait, what are we actually solving? But I felt I could teach those things to a sufficient degree. People could learn during onboarding or by osmosis, as long as they wanted to learn, as long as they were excited by what the role presented.

There were engineers from other teams helping out in FDE, and the number one reason they weren’t long-term FDEs is they were doing it somewhat reluctantly. Yes, they wanted the company to succeed, they were willing to get on a call. But they were not intrinsically motivated to get better at taking an ambiguous customer problem and solving it within messy constraints.

You ended up not requiring any ML or AI background for FDE hires. That’s counterintuitive for an AI inference company.

We debated that. Our version was we decided we did not care if you had any ML background or AI knowledge. A year and a half ago, that was a real discussion. Today it’s probably a red flag if someone has literally no AI knowledge. But back then, we found that engineers who operate comfortably across different stacks can pick up pertinent applied ML fundamentals on the job.

The harder part was interview design. We kept going back and forth on trying to come up with something more hands-on for FDE candidates. We’d say, well, maybe we go build an agent that does a thing. Every time we tried this, it was a disaster. The two things that are important in interviews are that you’re getting signal correlated with the outcome, and that you’re doing it consistently between candidates.

We would spend hours coming up with what we thought was the best test. And then we didn’t know what to do with the results. Did we present the problem poorly? Was it too open-ended? Did the candidate not know about some weird library that we knew about? Someone would spend half the time trying to install Python on Windows.

We tried to intellectually make up for it, but it was a mess. Keeping it simple would have saved us hundreds of hours and potentially kept candidates in the pipeline that we psyched ourselves out about.

Even with the right hires in place, Vlad found that the real challenge of running FDE isn't the work itself. It's the constant pull between the engineering side of the house and the commercial side.

In your article, you were clear that FDE should sit in engineering, not in GTM. But when deals are on the line and sales needs FDE resources, how did you actually navigate that tension day to day?

I did not want to take an FDE leadership role because I thought this tension was very hard to resolve and typically resolved only in one direction, which is in favour of the commercial side of the business.

So what do you do? I think you have to structure everything you can control in favour of engineering. At Baseten, we had FDE report into engineering. Does that solve everything? Of course not. Reporting structure is a made-up concept. But now your manager is the CTO. And the CTO thinks about long-term stuff.

The way it fails is when the CTO says, I have no idea what you want from me, leave me alone. That probably happens a lot. So reporting to engineering alone is not a solution.

For us, it was about adopting as many engineering artifacts as possible. The rituals associated with engineering. FDEs sit in the same meetings. The engineering weekly planning meeting, the FDEs are there. All these small things together add up. Optically, you feel like an engineer. You hear what people are building. They hear your problems.

Because commercially, the gravity is always going to be revenue. If you’re lucky and you’re successful, you have revenue to get. And it will find the FDE team. So you have to create a counterbalance.

My job was holding two repelling magnets together the whole time. Making sure that if one magnet moved here, you move the other magnet to make up for it. Sometimes you skew. End of quarter, January 20th, you rush to the finish line, go heads down and ship without asking too many questions.

But then as an FDE leader, you go to the CTO, you go to the CEO, and you say: what I want in return is two weeks where I can push back on commercial needs to give the team time to incorporate feedback. I think that’s the job of leadership in this world.

Was there a tactical trick that helped manage this?

Something I’m curious to try in more places. You can try to force the commercial side to be self-accountable. One of the first tricks you learn as a product manager is you don’t ask customers if a feature is important. Instead, you force them to prioritise it. Force them to say they want this more than this other thing. Because now they can’t say everything is equally important.

You can do the same thing with sales. You say, sort these deals by priority. Don’t tell me everything is important. Sales will say, if only we had hired more FDEs. But that’s not the question we’re asking.

A great salesperson is often highly aligned with the organisation’s long term outcome. If you force them to articulate what they want in terms of priority, they’ll probably give you the right priority. Not guaranteed, but it helps a lot.

As the team scaled, how did you decide what individual FDEs should specialise in?

One idea we had that turned out to be good was letting the team specialise by vertical. ASR, video, language. The reason it wasn’t obvious is you can’t guarantee customer workloads will be distributed along how you broke up your team. But the upside was massive. It lets the engineers specialise and gives them infinite runway to get better at something. They can figure out whatever techniques exist, whatever infrastructure plus model performance plus UX things they need to do.

If we’d specialised them by enterprise versus SMB instead, I feel like you end up specialising in how to say the right words so the CIO is excited. Not how to get the best product out there.

Vlad Shulman is the former Head of Forward Deployed Engineering at Baseten.

These first two weeks are mostly not about AI. They’re about understanding a business well enough to know where AI actually helps.

The first meeting is 80% listening

When we kick off a new engagement, the instinct is to demo what we’ve built, show off the technology, get people excited about what’s possible. We’ve learned to resist that.

The first meeting is almost entirely about listening. We’re not there to talk about AI. We’re there to understand how the business actually runs. What does the process look like end to end? What are the inputs? What are the outputs? Where do things break? What happens when they break?

For every hour we spend listening in this phase, we save days of rework later.

The most important dynamic to recognise early is the gap between how leadership describes a process and how the team actually executes it. This gap is always bigger than you expect. Leadership will describe the idealised version, the clean workflow they designed or approved. The operators on the ground have a different reality entirely.

In one project, we discovered that leadership had no idea about half the functionality baked into their own ERP system. The operators had figured out features and workarounds that nobody in management knew existed. They had personal spreadsheets tracking things the system was supposed to handle. They had mental rules for edge cases that had never been documented anywhere.

This is why you talk to the people who actually do the work, not just the people who approved the budget.

Mapping the real workflow

Once we’ve listened, we start mapping. And by mapping, I mean walking through every single step of the workflow we’re planning to automate. Every input, every output, every exception, every edge case we can find.

The key question we always ask is: “If this works perfectly, what changes for your team day to day?” The answer tells you what success actually looks like in their world, not in yours.

This is also where you discover where time is genuinely being wasted versus where people think it’s being wasted. These are often different things. A leader might point to invoice processing as the bottleneck because it feels slow, but the real time sink might be the manual data reconciliation that happens afterwards. If you automate the wrong step, you’ll deliver something technically impressive that doesn’t move the needle.

And this is where scope management starts mattering. The “can you also...” requests begin almost immediately. Our response is straightforward: we can do a lot, but you need to pick the things that matter most to you right now. Not because we’re being difficult, but because we need to get a first version live as quickly as possible.

This is often the hardest thing to explain to clients. We’re not trying to ship fast because we’re cutting corners. We’re trying to ship fast because a live solution generating real outputs at volume teaches us more in a week than months of planning ever could. If we keep discovering edge cases one at a time during workshops, we’ll be in the discovery phase forever. But if the system is processing real work, those edge cases surface naturally and at scale.

The IT partner problem

Almost every mid-market European company we work with has an external IT partner managing their ERP, their CRM, or their core systems. This is a reality of the market that a lot of AI content ignores entirely.

These IT partners control the integrations you depend on. If they’re responsive and engaged, the project moves. If they’re not, the project stalls. There’s almost no middle ground.

We learned this lesson the hard way. On one project, the sales process had assumed the client’s ERP was cloud-based with API access. When we got into delivery, we discovered it was on-premises with no API at all. And it wasn’t a standard system. It was a one-of-one, custom-built ERP maintained by a single person.

We got lucky. That person was responsive, keen to collaborate, and we had API access within days. But on other projects, we’ve been stuck waiting on external partners who had no incentive to prioritise our integration work. They had their own timelines, their own clients, and our requests sat in their queue.

The lesson: reach out to the IT partner immediately. Not in week two. Not after you’ve finished discovery. Day one if you can. Be specific about what you need: API access, data formats, test environments. Vague requests get vague timelines. And if the partner is a blocker, you need to know that as early as possible so you can find workarounds or reset expectations with the client.

We’ve also learned to do better scoping during the sales process itself. If the deal depends on a specific integration, verify it before signing. Don’t assume.

Getting to live

When we talk about getting a first version live, we don’t mean shipping a polished product. We mean getting the AI system running against real data, either alongside the existing process or replacing it with a human in the loop who can catch and correct mistakes.

The first outputs will be rough. We communicate that upfront, clearly and repeatedly. The goal isn’t perfection. The goal is feedback at volume.

We always set up evaluation criteria before the system starts running, not after. What does a good output look like? What does an acceptable error rate look like? How will we measure whether this is working?

Then we run real cases through the system. The edge cases you didn’t anticipate will surface immediately. This is a feature, not a bug. Every edge case caught now is one that won’t blindside you in production later.

Client feedback in this phase is gold, but you need to structure it. “Does it look good?” isn’t a useful question. “Is this output correct? If not, what specifically is wrong?” gets you somewhere. We set up feedback loops that are specific, low-friction, and regular.

Then we adjust. Tighten guardrails. Improve prompts. Add handling for the edge cases that surfaced. Run it again. This cycle happens daily, sometimes multiple times a day.

Why speed matters

There are two failure modes we’ve seen play out repeatedly.

The first is obvious: you skip the discovery phase, jump straight to building, and ship something fast that nobody uses. The solution doesn’t match the real workflow because you never mapped the real workflow. The operators reject it because they weren’t consulted. The champion who bought the project loses credibility internally.

The second is less obvious but just as dangerous: you spend too long in discovery and planning, and the project loses momentum. The client starts wondering what they’re paying for. The internal champion has to keep justifying a project that hasn’t shown results. The scope keeps expanding because there’s no live system to anchor decisions around. By the time you finally deliver something, expectations have inflated beyond what any first version could meet.

The two-week target forces a discipline. You can’t boil the ocean in two weeks. You have to make choices about what matters most. You have to get comfortable with imperfection. And you have to bring the client along with you on that, which means building trust through transparency rather than polished demos.

What this phase really is

The first two weeks of an AI implementation are not a technical challenge. They’re an organisational one. You’re learning how a business works, building relationships with the people who will use your system, navigating dependencies you don’t control, and establishing the feedback loops that will determine whether the project succeeds or quietly dies.

The companies that get the best results are the ones who engage fully in this phase. They explain their processes honestly, challenge our assumptions, share the messy spreadsheets and undocumented workarounds. They treat us as a partner, not a vendor.

Every shortcut you take in these two weeks costs you weeks later. Every conversation you skip comes back as a feature gap. Every dependency you don’t surface becomes a blocker at the worst possible time.

The AI part, frankly, is the easy bit.

Palantir coined the FDE title over a decade ago. Today you see it on job posts from AI startups, infrastructure companies, traditional SaaS. When you say FDE now, what does it actually mean to you?

I think the broadest umbrella is that it’s a technical or quasi-technical role that accelerates customers to value. You can imagine other roles that have always existed potentially falling into this category. Solutions architecture, professional services, to some degree.

What made Palantir’s version distinct was two things. One, they were literally embedded with the customer. They would go on site, be in the Slack channel, really learn the ins and outs of the organisation. And two, they were actually building things. Processes, products, connecting tools rather than just configuring them.

But today, FDE spans a huge spectrum. A lot of AI companies looking for product-market fit think of FDE as a way to go build something based loosely on what the company has. Just go build something. This is a way of getting more at-bats.

Then you have post-PMF companies that don’t have the most technically complex product but want folks that can help configure it for a customer. In that case, FDE is almost more of a marketing term for recruiting. It doesn’t hurt to have smart people doing this work. But the question is, are they going to be happy doing it in a year?

And then you still have plenty of folks who are going on site, building things, expanding the product perimeter. That’s the Palantir sense.

At Baseten, it was a different flavour again. We had a product, and the buyers were highly technical teams. Staff engineers, L6 equivalents. These are people who traditionally don’t need help building something technical. The reason they were working with us is because they wanted outsized outcomes, two standard deviations better performance on state-of-the-art inference. They’re smart enough that if they invested the resources, they could probably get there. But they’re growing quickly, raising money every six months. What can they stop worrying about? Maybe inference. And inference just happens to be a surprisingly difficult thing to do.

You’re describing at least three or four different roles that all get called FDE. Does that matter?

Honestly, 80% of the conversations I have about FDE, most of the disagreement is because of what the speaker has in mind when they say FDE.

Here’s what happens. You call your role FDE. Externally, people who are applying start self-selecting based on that term. Internally, you start using the term and thinking in that term. You go to your friends and ask what they’re doing for FDE, and they give you their answers. And now it’s affecting what you’re doing. But at this point, it’s already detethered from the actual intent you had. You had some intent and now you’re sailing wherever the wind is blowing.

Is that good or bad? It’s good if you’re directionally aligned. But if your FDE team is doing configurations and you read advice about how much time the team should spend on work that becomes part of the core product, that probably confuses you. It doesn’t jive with how the product works. You just need someone doing last-mile delivery. That might be solutions architecture.

Conversely, people would ask me for advice on navigating large enterprises. I’m not very knowledgeable about that. At Baseten, our people didn’t literally go embedded on site. The traditional enterprise sales challenges that FDE sometimes helps solve, that wasn’t our world. Getting advice on that from me would not be helpful.

I think maybe there’s some sort of one-pager we should put together. How to tell what kind of FDE role this is. Because the signals get mixed up for candidates, for employers, for everyone.

In your article, you wrote that 70% of what FDE builds should go back into the product. For the early-stage startups you’re advising now, is that realistic?

For some reason, that line is the one that many people have messaged me about. Whenever that happens, I wonder if I said something wrong. I’ve thought about it a lot since.

There are two things that are important to understand. When I defined FDE earlier, I did not define it in terms of contributing to the product. I don’t think it’s inherent to the definition that FDEs contribute to the product, even in the Palantir sense. FDE can be using and implementing the product without providing feedback back. But to me, this is where the alpha starts to come out. This is the whole point of FDE in some sense.

The problem is there’s nothing about the incentives of the role that obviously incentivise that. The incentives are typically commercially aligned. So that 70% is more than anything a heuristic to be self-accountable. As a leader, as an individual contributor, you ask yourself: what type of FDE work are you doing?

One place it becomes existentially important is the pre-product-market-fit startup. For a lot of those companies, FDE is this load-bearing function that can be a way to uncover product-market fit. It lets you parallelise discovery. But really, what you’re parallelising is consulting. You think you’re parallelising discovery.

If you’re this kind of company and FDE is load-bearing to do product discovery, I think you only survive if you’re very serious about feeding work back into the product. Ideally, you have a founder involved in a lot of these calls. Because it’s very hard for an FDE to change the direction of your company based on the discovery they made. They can be good advocates for individual features, but for them to say “hey let’s pivot the company based on this feedback customers are giving me...” that’s asking for a lot.

If you’re not thinking of incorporating that feedback back into the product, then you are just consulting. Eventually you’re going to either become a consulting company and maybe make a lot of money, or you’re going to run out of money. But you’re not going to become a product company.

Maybe the number is 60%, maybe it’s 80%. I don’t think it’s 30%. It has to be more than 50 and less than 100. And it has to be less than 100 because if everything your FDE team does becomes product, you’re probably either not taking big enough bets or spending too much time generalizing things before you know if they matter.

Can you give an example of what that looks like in practice? What counts toward that 70%?

At Baseten, one of the biggest things we shipped out of FDE was the ASR product. The transcription, speech-to-text pipeline as a first-class product. It’s a drop-down on the website. That shipped out of FDE and I’m very proud of it.

But these types of products are not 70%. They’re maybe 20-25%. The other 50% are products that shipped out of our product engineer team that FDE materially informed. And tools that the FDE team built for themselves that make each incremental engagement more effective. Things that create leverage.

Shipping a “GA” product is the pinnacle of that motion. But there are reasons why FDE shouldn’t be building all your products, especially as the company grows, because other people develop that speciality.

You can also do zero of that. I don’t think it’s illegal to call that role FDE. But then you’re not getting that feature of FDE. It’s just an implementation team with engineering skills. And it’s very hard to scale that sub-linearly with revenue.

Vlad Shulman is the former Head of Forward Deployed Engineering at Baseten. In Part 2, we talk about his path from founding two companies to leading an FDE team, the daily tension between engineering and sales, and why he nearly turned the role down.