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.

On Friday evening, I pulled it out. I didn’t have a grand plan. I just wanted to see how far I could get building an AI agent from scratch, starting from nothing, on hardware most people would throw away. The honest motivation was curiosity and the itch to build something with my hands. Well, my hands and Claude Code.

By Sunday night, I had a personal assistant that understands voice messages, controls the phone’s hardware, remembers conversations across sessions, and can modify its own code when I ask it to. I called it Chorgi. I want to walk through how I got there, because the process itself was the most interesting part.

From drawer to Linux machine

The first step had nothing to do with AI. Before any of the interesting stuff could happen, I needed to turn a consumer Android phone into something I could actually program on.

Factory reset for a clean slate. Developer options enabled by tapping the build number seven times in the settings (a ritual that never stops feeling like a cheat code). “Stay awake while charging” turned on. Battery optimisation disabled for Termux.

Termux is what makes the whole thing possible. It’s a terminal emulator that gives you a proper Linux environment on Android, no root required. One important detail: you have to install it from F-Droid, not the Play Store. The Play Store version hasn’t been updated in years and is essentially broken. I also grabbed Termux:API (which exposes phone hardware to the command line), Termux:Boot (for auto-starting services), and Termux:Widget.

With Termux running, I installed the basics: Python, Node.js, Git, SSH, tmux, and a handful of networking tools. Then I set up SSH so I could connect from my laptop. This was the single biggest quality-of-life improvement of the entire project. Instead of typing on a tiny phone screen, I could work from my laptop’s full terminal, treating the phone as a headless server sitting on my desk.

I also set up auto-start so that SSH launches automatically whenever the phone reboots. A tiny boot script that acquires a wake lock (preventing Android from sleeping Termux) and starts the SSH daemon. After this, the phone became a proper always-on server. Plug it in, and it’s ready.

SSH access is locked down with key-based authentication only, no passwords. Only my laptop can connect, and only from the local network. The phone is accessible, but only to me.

At this point, I had a Linux machine with access to four cameras, forty-three sensors, GPS, a microphone, a flashlight, a vibration motor, and screen brightness control, all accessible from the command line. The hardware was never the problem. The software just needed unlocking.

A bot that listens

I needed an interface. Something I could talk to from anywhere, not just when I’m on the same WiFi network as the phone. SMS was an option, but Telegram was the obvious choice: free, simple bot API, works from any device, and creating a bot through BotFather takes about two minutes. The bot only accepts messages from my Telegram account, so nobody else can interact with it.

The first version was a bash script running in a tmux session. It polled the Telegram API for new messages, pattern-matched against slash commands, executed the corresponding Termux:API call, and sent the result back. Simple as it gets.

/torch on turned on the flashlight. /battery returned the charge level and temperature. /photo triggered the camera, captured an image, and sent it back through Telegram. /location grabbed GPS coordinates. /wifi showed network information. /room read the barometric pressure from the phone’s LPS22H sensor and estimated room temperature from the battery thermistor (roughly 2°C offset from ambient, not precise, but surprisingly useful).

It worked. And it was completely useless for anything beyond the specific commands I’d hard-coded. If I asked it “what’s the weather like?” it would just sit there. No understanding, no flexibility, no intelligence. A remote control with a chat interface.

Adding a brain

The next step was obvious: route messages through Claude. Instead of only responding to pre-defined slash commands, every message would go through an LLM that could reason about what I was asking and decide which phone commands to execute.

I used the Claude Code CLI for this, and the reason was practical: Claude Code supports OAuth authentication, which means I could run everything under my existing Pro subscription. No API key needed, no separate billing, no credits to manage. For a weekend project, this was ideal.

Getting Claude Code running on the phone required a small workaround. Claude Code expects a /tmp directory, which on Android lives on a read-only partition (no root, remember). The fix was proot, a lightweight tool that lets you fake filesystem paths. A simple alias in my shell config made it transparent: alias claude='proot -b $PREFIX/tmp:/tmp claude'. One detail that cost me twenty minutes of debugging: this alias has to use single quotes. Double quotes cause the shell to expand $PREFIX at definition time instead of execution time, which breaks the path.

With Claude wired in, the bot suddenly understood natural language. I could say “turn on the flashlight” or “take a photo of the room” or “what sensors does this phone have?” and it would figure out the right commands to run. The jump from slash commands to natural conversation felt enormous.

But two problems appeared immediately.

First, every response took about fifteen seconds. The architecture was heavy: each message spawned a subprocess chain of proot, Node.js (the Claude CLI), and a Python MCP server communicating over stdio. That’s a lot of startup overhead before any actual API call happens.

Second, and more importantly, the bot had no memory. Every message was a completely fresh start. I could have a detailed conversation about setting up a reminder, and two messages later it had no idea who I was or what we’d been discussing. Each invocation of claude -p (pipe mode) is stateless by design.

The speed problem was annoying. The memory problem made the bot fundamentally limited.

Building memory because I needed it

I didn’t sit down and think “now I’ll implement a memory system.” I was chatting with the bot, it forgot something I’d told it thirty seconds earlier, and I realised I needed to fix this if the thing was going to be useful at all. The bot needed to understand its environment, remember context across conversations, and be able to complete tasks from beginning to end.

The approach I landed on was deliberately simple. Just markdown files on disk, assembled into a system prompt before every message.

The memory system has a few layers. A core identity file that’s always loaded, defining who the bot is and how it should behave. A user facts file where the bot stores things I tell it to remember (via a /remember command that just appends to the file). A self-knowledge file that gets loaded when someone asks the bot about its own architecture. And a collection of topic files, each with keyword triggers in their headers, that get loaded on demand when the conversation touches their domain.

The topic files are where it gets interesting. The phone has over eighty Termux:API commands across cameras, sensors, audio, communications, location, hardware control, UI interactions, storage, and networking. Loading all of that into every prompt would blow through the token budget immediately. Instead, I created nine topic files covering different capability domains. When I mention cameras, only the camera knowledge loads. When I ask about sensors, only the sensor file loads. Simple substring matching against the incoming message.

There’s a budget system capping the assembled prompt at six thousand characters. Core identity and user facts are mandatory and always included. Optional sections get added in order until the budget runs out, then they’re dropped. It means the bot always has its essential context and loads specialised knowledge just in time.

The whole memory manager is about a hundred and fifty lines of stdlib Python. Just files. Markdown on disk, editable by hand or programmatically by the bot. The data format is the interface.

Teaching it skills and tools

With memory sorted, the bot understood context and could maintain conversations, but it still couldn’t do much beyond controlling the phone’s hardware. I added tool capabilities: web search, note-taking, file management. Each implemented as a Python module that Claude can call during a conversation.

This is also where I tackled the speed problem. The original architecture, shelling out to the Claude CLI for every message, was adding minutes of overhead. I replaced it with a direct HTTP bridge to the Anthropic API using urllib (stdlib Python, still keeping dependencies minimal). The bridge makes a POST request, and if Claude wants to call a tool, it executes the tool in-process and feeds the result back, looping up to ten rounds until the response is complete. This part does require an API key and credits, unlike the CLI approach, but the speed difference made it worth it for the conversational tier.

The bridge also manages conversation history, keeping the last twenty messages per chat, persisted to a JSON file. So the bot now has both long-term memory (the markdown topic files) and short-term memory (the conversation buffer).

The result: response times dropped from three to five minutes down to about fifteen seconds. Pure API latency, no overhead. And the change required modifying exactly two lines in the router to swap the old bridge for the new one. Everything else, the bot, the memory system, all the tools, stayed the same.

The three-tier architecture

What emerged over the weekend wasn’t planned. Each tier appeared because the previous approach hit a limitation.

Tier one handles known slash commands. When I type /battery or /torch on, there’s no reason to involve an LLM. The command is pattern-matched in Python, the corresponding Termux:API call is executed, and the result comes back instantly. Sub-second response times for things that don’t need intelligence.

Tier two handles everything else. Any message that isn’t a known command goes to the Anthropic API with the full memory-assembled system prompt and access to all tools. This is the conversational layer, where the bot reasons about what I need, decides which tools to call, and maintains context across the conversation. About fifteen seconds per response.

Tier three is explicit and deliberate. Triggered by /code or /implement, it spawns a full Claude Code CLI instance with write access to the entire project. This is the self-modification layer, the one where the bot can change its own code. It’s separated from tier two on purpose, because you want a clear boundary between “the bot is talking to me” and “the bot is rewriting itself.” Since this tier uses the CLI with OAuth, it runs on the Pro subscription, no API credits spent.

The escalation path is always clear: fast local handling, then conversational AI, then full code agent. And the user is always in control of when the bot is allowed to modify itself.

Plan mode is gold

One thing I want to call out specifically about Claude Code: Plan mode. Before jumping into implementation, you can ask Claude to plan what it’s going to do, review the approach, and only then give it the go-ahead to write code.

When I’m working on Chorgi from my laptop over SSH, this is how I build every major feature. I describe what I want, Claude thinks through what needs to be modified, what new files need to be created, how existing systems will be affected. I review the plan and either approve it or redirect before a single line of code is written. It’s the reason I could move so fast over the weekend. The thinking and the architecture decisions were mine, but the planning and execution were collaborative.

The moment it modified itself

This was the highlight of the weekend.

I wanted the bot to handle voice messages. I use Telegram on my main phone to chat with Chorgi, and Telegram supports voice notes natively, so the idea was to send a voice message from my phone and have the bot on the Samsung transcribe and respond to it.

Instead of writing the feature myself, I opened Telegram and sent: “Add voice message support with transcription.”

Then I waited. Three minutes of silence while the bot worked. Then a message appeared: “Restarting with your new feature.”

The bot killed its own process. The watchdog script detected the shutdown, waited five seconds, and restarted it. A message came through: “Back online.”

I sent a voice note. The bot asked me to provide an OpenAI API token for the Whisper transcription service. So I went and created an OpenAI paid plan, generated a token, SSH’d into the phone, and added it to the environment config. I probably could have just pasted it into the Telegram chat, but sending API keys through a messaging app felt wrong somehow. Once the token was set, I sent another voice note. It transcribed it and responded as if I’d typed the message. The feature worked.

I want to be specific about what happened here because it still feels slightly unreal. I described a feature I wanted, in plain English, through a Telegram message, to a bot running on a phone on my desk. The bot planned the implementation, wrote the code across multiple files, wired everything together, restarted itself, and confirmed it was ready. I didn’t open an editor. I didn’t write a line of code. The only manual step was adding the API token, and even that felt like it could have been handled through the chat.

For transcription, the bot uses OpenAI’s Whisper API. Quick, accurate, and straightforward to integrate.

Safety, because self-modification is terrifying

A bot that can rewrite its own code is exciting right up until it breaks itself. Which it will. Which it did.

The safety mechanisms work in layers. First, the bot only accepts messages from my Telegram account. Nobody else can interact with it, let alone trigger code modifications. SSH access is key-based only, limited to my laptop on the local network.

Every code modification starts with a git checkpoint, creating a rollback point before any changes. If something goes wrong, a /rollback command reverts the entire codebase to the checkpoint and restarts the bot.

The watchdog is the last line of defence. It’s a bash script that monitors the bot process and restarts it if it dies. But it also counts crashes: if the bot crashes three times within sixty seconds, that’s a crash loop, which almost certainly means the last code change broke something fundamental. When that happens, the watchdog automatically runs git checkout . to revert all changes, then restarts. The bot heals itself without any human intervention.

There’s also a lock file that prevents concurrent implementations (you don’t want two Claude Code instances editing the codebase simultaneously) and a five-minute timeout that kills any implementation session that runs too long.

The bot has broken itself exactly once so far. The watchdog caught the crash loop, rolled back the code, and had it running again within seconds. I was watching from Telegram and didn’t have to do anything.

What I built over a weekend

Let me step back and describe what actually exists now.

Chorgi is a Telegram bot running on a seven-year-old Samsung phone that sits plugged in on my desk. I can message it from anywhere in the world. It understands natural language and voice messages. It controls the phone’s hardware: cameras, flashlight, sensors, GPS, screen brightness. It can search the web, take and retrieve notes, manage files. It remembers things I tell it across sessions and loads specialised knowledge on demand. It has full awareness of its own architecture and can explain how it works when asked. And it can modify and extend its own codebase when I ask for new features, with safety mechanisms to catch and recover from mistakes.

The entire thing runs on stdlib Python with minimal external dependencies. Memory is markdown files on disk. Session history is a JSON file. The codebase is small enough that a single Claude Code instance can understand all of it. Everything is plain text, everything is inspectable, everything is editable by hand if needed.

The phone stays plugged in and online. There’s a battery degradation trade-off with keeping lithium batteries at 100%, but this is a seven-year-old repurposed device that was headed for a landfill. I’ll take it.

The speed of building

What surprised me most about this project was the pace. I started on Friday evening and had a working, self-modifying AI agent by Sunday. Something I actually use daily.

The reason it moved so fast is that I only needed to figure out what to build and why. The what came from running into limitations: the bot forgot things, so I needed memory. The bot was slow, so I needed a better API bridge. The bot couldn’t learn new tricks, so I needed a self-modification system. Each problem pointed clearly to the next thing to build.

The how was handled by Claude Code. I’d describe the architecture I wanted, the constraints I cared about (minimal dependencies, files on disk, specific budget limits), and it would implement the solution. Not perfectly every time, but well enough that I could iterate quickly. The bottleneck was never the coding. It was deciding what the right approach should be.

This is the thing that made the project addictive. Every improvement I made revealed the next thing I wanted to build. And now, the tool for building the tool is the tool itself. I can keep extending Chorgi by chatting with it on Telegram. The feedback loop is incredibly tight.

Where this goes

Right now, Chorgi calls an API for intelligence. Every conversational message requires an internet connection and a round trip to Anthropic’s servers. That works, and it costs money per message.

But local LLMs are getting smaller and faster. Models that can run on phone hardware already exist, and they’re improving rapidly. Imagine Chorgi with a local model instead of API calls. No internet dependency, no per-message cost, no latency from network round trips. Always on, fully private, running entirely on the device in your pocket.

Now imagine this isn’t a Termux hack on an old phone but a native layer in the operating system. Deep access to apps, contacts, calendar, notifications. A personal assistant that actually knows your context, remembers your preferences, controls your devices, and gets better over time because it can literally improve itself.

That’s not Siri. That’s not Google Assistant. Those are voice interfaces bolted onto search engines. What I’m describing is an agent that lives on your phone and works for you, with the same kind of autonomy and capability that Chorgi already has in its rough, duct-taped form.

I built a prototype of this in a weekend, on hardware from 2019, using tools that didn’t exist a year ago. The gap between what’s possible now and what ships as a default phone feature is mostly just packaging and polish.

I started on Friday because I was curious. I’m still building because I genuinely can’t stop. Every time I sit down to work on something else, I think of another feature to add, and the fastest way to add it is to just ask the bot. I’m already planning what to build next week.

You were an ML FDE at Kumo back in 2023, before FDE became a popular title. What did you see during that time that made you think the way these teams operate is broken?

When I got the role, I wasn’t even sure what it was. The chief scientist at Kumo, who is the leading specialist on graph neural networks, told me I’d like it because it still involved the research-oriented components I needed, but it would be more customer-facing. So I gave it a try.

My job was to create graph neural networks that ingest sales data from our customers and then make predictions on things like churn and lifetime value. Very technical solution, very non-technical audience. I got to work with customers like DoorDash, Louis Vuitton, and Snowflake, actually going on site, understanding their sales team’s needs, then building models for them.

I totally got why the role is so useful. Without that FDE team, the product has no value for the customer. But the function was so nascent that we were figuring out everything on the fly.

One example that stuck with me: one of my colleagues was building a GCP connector, which I didn’t know about. My customer asked about building the same thing, and I started building it from scratch. Only after did we realise we’d both built the same thing. Through those hiccups, we realised there were so many ways we could be organising our customer accounts and the work items created for them better.

I honestly put it in the back of my mind for a long time. Then in June 2025, FDE hiring just absolutely took off. I started talking to companies and it surfaced that FDE teams are scaling fast, and there’s a good chance they’re going to run into the exact same issues I did back at Kumo. That has absolutely been the case.

You now talk to a lot of different FDE teams through Nixo. What do you still see as a common way that teams fail, despite having strong engineers?

Engineering is a big part of FDE, of course. If you have good engineers, you can implement fast, and that’s a big part of what the role is about: delivering the customer win quickly.

But the strongest FDE teams are able to minimise the amount of new work they have to do for each customer. That’s more of a technical project management skill, and it’s a very new one.

FDE involves insights from both pilot and pre-sales. There’s relationship building, understanding the customer’s unique needs. What separates it from a traditional engineering role is that relationship building and the context you’re carrying over. A lot of people compare it to sales engineering, but you actually have to deliver.

Most teams still treat FDE like just another engineering division where you just happen to know the customer a little better. It’s actually a lot more complex than that. Unless you take a very organised operational approach to managing your customer accounts, each customer becomes its own project instead of something that converges into your main product.

That’s the issue I still see a lot of FDE teams running into. They aren’t really running a SaaS business anymore. They’re running a services operation. The best FDE teams maintain that SaaS-like scale even though they’re handling individual accounts.

When Priya applied to Y Combinator with the idea for an FDE ops platform, I was curious how much explaining she had to do. And whether, from where she sits now, FDE is actually mainstream or whether we’re all just in a bubble.

When you pitched “ops platform for FDEs” at YC, how much did you have to explain what an FDE even is?

I’ve actually had an easier time talking about FDE to investors than to companies. Most investors tell me the number one issue that comes up in their board meetings is how to get the FDE process right. Their portfolio companies are encountering it constantly.

That was absolutely the case with YC as well. The partners were very aware of the FDE motion because a lot of the best YC companies have really thrown themselves into it. My general partner had seen HappyRobot go through these struggles and absolutely understood the market potential.

With companies, it’s a toss-up. Sometimes people aren’t aware they’re experiencing an issue. I encounter FDE teams where I look and think that’s a bit of a hot mess situation, but they’re not aware. They say things like “this is just startup life, things are messy, you have to be scrappy.”

Surprisingly, this isn’t really related to company stage. I’ve seen really mature seed-stage FDE teams that get the issue and are actively working to make their motion more scalable. And I’ve also seen Series C and D companies with massive FDE teams who are trying to solve the services problem by increasing headcount instead of improving operational efficiency.

Where do you see a bigger gap right now: figuring out how FDE teams should operate, or hiring the right people for them?

They’re equally challenging, and it’s a realisation I had not too long ago.

In the first few months of running Nixo, I would see two buckets of questions. The first is: how do I make my FDE team better? That starts with questions as simple as how should I organise my team, which gets into pod structures, making sure you have both specialists and generalists. Then it goes down to how do I templatise the code I’m creating, which is where infra tooling comes in.

The second bucket: do you know any good people I could hire? Because FDEs are like mini founders. They own customer relationships and they’re building the entire sales cycle and implementation. These are people you really need to trust.

That’s when I realised the two go hand in hand. People are trying to scale their FDE teams because FDE is absolutely business-critical for AI companies. They see that if they want to take on more customers, they need the bandwidth. So they hire. But headcount doesn’t solve all problems. In engineering, if a project is going to take a year, throwing five versus ten engineers on it doesn’t necessarily change that. Maybe nine months instead of a year, but it’s not meaningfully different.

Nixo actually started a Hiring Hub programme because we kept getting people on both sides, employers looking for the best FDEs and FDEs asking where they should work, so we started matching them. One of our customers is in the healthcare space doing implementations that require EHR integrations and selling to CMOs and CTOs. Being able to look at our network and say, here’s a former founder in health tech who has sold to CMOs, let me make that intro, that’s become a real part of what we do.

But even outside of that, I always remind companies: not everything can be solved by adding headcount. When you’re looking to increase what your FDE team can take on, the most important thing is to hire people who 10x the leverage of your team. That means people who are high energy, enthusiastic about customers, have built zero to one before, and can manage their own technical projects. They can scope out what needs to happen now versus later. That’s actually the hardest part of being an FDE.

You mentioned high energy and enthusiasm. Here’s a question: what’s your take on experience level? The median FDE has about a decade of work experience. Is that what teams should be looking for?

My hot take is that new grads actually make really good FDEs.

Despite the lack of working experience. Because what I’ve come to realise about FDE is it’s a scaled-down version of making a startup. A lot of founders believe you learn by doing. You can have some experience, but you learn the most by doing. The same goes for FDE.

If you have high-energy, hard-working, enthusiastic people who care about customers, put them in that situation. Maybe they’ll need a little bit of hand-holding, but they’ll get it. Some of the best FDE teams I admire have experimented with bringing new grads onto their team and have seen a lot of success.

I read the article where you analysed the median years of experience for FDEs. My takeaway was that it’s more effect than cause. People believe you need experienced folks on the ground, so they hire experienced folks. But I’ve noticed in the best FDE teams, the bar is really having high energy, enthusiasm, and technical skills. Experience can be nice to have depending on your industry, but you can get those qualities from new people too.

Sometimes the best founders are folks who are in college or right out of college. They have no experience, but they’re approaching problems from an entirely fresh perspective. They’re more optimistic than people who have been in the industry, so they’ll find a way to cut around corners and get the win fast.

For some industries, that’s not always the case. If you’re doing really technical implementations, like deploying ML solutions in production, it helps to have people who’ve done that outside of a research environment. But even then, someone with one or two years of experience can do fairly well. I’ve seen people who were solutions architects for years get outperformed by newer people who just have that hunger.

You mentioned being honest with yourself about whether FDE is a real long-term need or just a moment. What’s the conclusion you arrived at?

I was grappling with the bubble question a lot during Y Combinator. I graduated in 2025. Coming out of college, I had an offer to join a foundation lab as an ML researcher. I had to ask myself: do I really want to throw that away for this?

The conclusion I arrived at was this. Ten to fifteen years ago, when you looked at SaaS, a lot of problems could be solved by generalised, off-the-shelf solutions. That’s why the SaaS model was really thriving. You could have software that works 80% out of the box, and then maybe 10 or 20% you have a solutions architect come in, tie the bow, and make it land for the customer.

But we look at the AI era, and AI works really well in hyper-specialised situations. We don’t have a good generalist AI yet. And, to be frank, AI is still pretty bad. It doesn’t really work reliably. That’s why everyone is trying to duct-tape together these sort-of-working solutions: agents, workflows, trying to make it work.

We’re seeing the exact opposite of SaaS now. An out-of-the-box solution can only deliver 10 or 20% of the value, and you need a human being to really understand the customer’s situation and make it work.

I asked myself: is this a consequence of a new industry where everyone can easily get funding and hype, or is this a more structural problem? My background is in AI and ML research. My understanding of LLMs is that as long as we stay on the current transformer-based paradigm, we don’t have intelligence. We need a lot of hand-holding with LLMs. Until we hit a research breakthrough, this is going to be the mode of operation.

That’s why FDE has become so important to AI. AI needs a lot of hand-holding right now. If you’re not getting FDE right, your AI business could collapse.

I think the real bubble is people thinking they can get away with generalist AI solutions when the technology is not there yet. The companies that will emerge from this bubble are the ones that have understood the limitations of AI and put workarounds in place.

When I hit that realisation, I went all in on Nixo. This is going to be a critical business need.

Priya Khandelwal is Founder & CEO of Nixo (YC S25).

That same month, Deloitte was caught submitting an AI-generated report to the Canadian government containing fabricated citations. Real researchers paired with papers they never wrote. A month earlier, they’d done the same thing in Australia, forced to refund $290,000 for a welfare compliance report that included made-up quotes from a federal judge.

An Australian senator put it simply: “Perhaps procurers would be better off signing up for a ChatGPT subscription.”

The pyramid problem

McKinsey’s headcount is down to 36,000, roughly 25% below its peak. They’re laying off up to 10% of non-client-facing staff over the next two years. BCG, Bain, the Big Four, all restructuring. Job postings at top consulting firms are down 50% year over year.

The structural issue isn’t that AI is making consultants more efficient. It’s that AI is automating exactly what junior consultants do: research, synthesis, slide creation, benchmarking. The pyramid model that made consulting profitable, partners at the top leveraging large teams of associates at the bottom, is collapsing from the base up.

Harvard Business Review proposes replacing the pyramid with an “obelisk.” Fewer layers, smaller teams, more leverage at each level. New roles like “AI facilitators” and “engagement architects” rather than armies of analysts.

But this misses the deeper problem.

Advice versus outcomes

The consulting business model was always based on selling time. Tom Rodenhauser from Kennedy Intelligence puts it plainly: “You charge for time, and when time goes away, you have to change the commercial model.”

But time isn’t the only thing that’s going away. The entire value proposition is shifting.

What enterprises actually want now is problems solved. Not analysis. Not a 200-slide deck explaining what they could potentially do.

The HFS study found that headcount-based contracts are collapsing. 49% of consulting contracts today are tied to staff numbers. Within two years, only 16% expect to use this model.

What’s replacing it? Outcome-based pricing. McKinsey says a quarter of their engagements are now outcome-based. But outcome-based pricing only works if you can deliver outcomes. And delivering outcomes requires building things, not advising on them.

This is where the traditional consulting model breaks. There is no outcome. There’s advice.

The verification problem

The Deloitte scandals are instructive. Not because Deloitte is uniquely bad, but because they reveal what happens when you try to use AI to cut costs without understanding the domain deeply enough to verify the output.

Their AI tools saved time. They also fabricated citations that a first-year university student would have caught. The consultants reviewing the work didn’t catch it because they were doing exactly what the pyramid model trained them to do: moving information between formats, not deeply understanding it.

This is the trap. AI makes synthesis faster. But synthesis without verification is worse than useless. And verification requires domain expertise that can’t be compressed into a 10-week engagement.

The new model is already here

While consulting firms struggle to adapt, a different model is emerging. Last week, Goldman Sachs revealed they’ve spent six months embedding Anthropic engineers directly into their operations to build autonomous AI agents for trade accounting and client onboarding.

Notice what’s happening here. Goldman embedded engineers from an AI company into their teams to build systems that do the work. The output isn’t a strategy deck or a report on the future of automation in financial services. It’s running software.

Marco Argenti, Goldman’s CIO, described the agents as “digital co-workers for professions within the firm that are scaled, complex, and process intensive.” Internal tests showed 30% faster client onboarding and over 20% developer productivity gains. The agents manage operations for $2.5 trillion in assets.

There’s another detail worth noting. Goldman also reported that over 10,000 employees, roughly a quarter of the firm, now use an internal AI assistant built on large language models. The tool started in one division and expanded to others based on internal demand, not a top-down mandate. I see the same pattern in European enterprises like Allianz. The companies with the broadest AI adoption are usually the ones where a team gets real value from a pilot, tells their colleagues, and momentum builds organically, all while being sponsored and guided by strong executive commitment. At a certain scale, internal word-of-mouth becomes your best adoption engine. The challenge shifts from “how do we convince people to try this” to “how do we support the teams that are already using it.”

This is what outcome-based work looks like in practice. Not a deck about what could be automated. Running systems that actually automate it.

The same week, ElevenLabs announced a partnership with BCG to deploy voice agents across industries. BCG isn’t being hired to advise on conversational AI strategy. They’re partnering with a technology company to actually deploy production systems for clients.

The consulting firms see the shift. They’re adapting. McKinsey has Lilli. BCG has Deckster. They’re building internal AI tools, launching partnerships, restructuring around implementation. But they’re doing it from within a business model that was optimised for something else entirely.

Where the opportunity is

Here’s my hypothesis. Many problems that took years and millions to solve with traditional consulting and systems integration can now be solved for 20% of the cost in a tenth of the time. ERP replacements. Process automation. Data integration. The categories of work that consultants scoped at 18 months are becoming 8-week projects.

This creates a gap. Not a small one. The AI consulting market is projected to grow from $11 billion this year to $91 billion by 2035. That growth has to go somewhere.

Some of it will go to the Big Four adding AI practices. They already are. They’re not standing still.

But they’re also not structurally built to capture this shift. Their economics depend on billing hours. Their pyramid depends on leverage. Their credibility depends on the “no one gets fired for hiring McKinsey” dynamic.

That dynamic isn’t going away, by the way. Enterprises that need a stamp of approval from a trusted name, whether for board presentations, regulatory cover, or simply career protection, will keep hiring the big names. Some buyers will always prioritise safety over speed.

But they’ll be the last ones to shift. And the buyers who actually want problems solved, the ones who care more about outcomes than process, are already looking elsewhere.

The shift away from advice isn’t really about consulting firms. It’s about the end of a model where describing problems was valuable enough to build a $300 billion industry around it.

What comes next is a model where solving problems is the only thing that counts.

At Orby you built an agentic process discovery product to uncover process information at enterprises. What did you learn about how enterprises actually work versus how they think they work?

It’s an age-old problem. There have been previous approaches like process mining and task mining that predate the LLM age. But with reasoning and multimodal capabilities, these models become a really big unlock.

Enterprises have so many processes through all the different layers of organisation structure. How things get done is a function of the people involved, the business model, the systems they’ve organised. And these processes always evolve over time.

At Orby, we worked with a large private company thinking of going public. For them, that meant making sure they weren’t just following their existing process, but moving towards something compliant with public markets. How they recognise revenue, how they handle discounts, rollover amounts.

A lot of this is information they have to painstakingly document. But in many cases, the only reason processes get documented is because you have a big moment like this.

What happens all the moments in between? When you add more members to a team? When the process changes for smaller reasons? That stuff never gets documented. People learn it from coworkers. By seeing and observing. Or they come up with their own ways of doing things.

You start to build up almost this debt. In the same way you have technical debt, it’s like process debt. People have figured out band-aids to solve problems that exist in their heads but don’t lend themselves to real transformation.

The key insight was: how executives and even process owners think work is happening versus how it’s actually happening often has a very big gulf between it.

Once you get to the people doing the job day to day, they show you all the edge cases. All the ways they do things that even their managers or VPs had no idea was happening.

FDEs spend a lot of time trying to understand business processes and extract business rules. What can be automated and what still needs a human?

A lot of business logic, actually the majority from a process standpoint, isn’t well documented or structured.

An example: people know that if an invoice is between $10,000 and $25,000, they probably need the finance director to review it. But if it’s above $25,000, who should review it? Is it still the director? Is it a VP? Maybe it needs an additional round of review from the controller if the GL code is of a particular category.

There are all these little details that come up.

One theory is we can look at decision traces. We can look at what decisions people made. But the reality on the ground is when people make decisions and carry out a task, they’re not documenting why they made that decision. They’re going off some knowledge in their head, or they were trained to do it but aren’t referring to that anymore.

None of these passive observation techniques answer the why question.

That’s where FDEs are critical. The role is not just to say “here’s what happened.” It’s to say “why did you do this?” Because the whole point of building an agent that can reason and take action is that it knows what to do not just in that exact scenario, but in similar ones.

One FDE leader put it well: how I know someone is really good at this role is they ask the right questions at the right times.

That’s the part FDEs will continue needing to take the lead on.

Is there also something about humans wanting to work with humans? Customers wanting to discuss things with someone rather than typing into an AI?

One thing a lot of people don’t realise is enterprises are not trying to buy software. They’re not trying to buy a seat of a certain product. They’re trying to buy outcomes. They need a problem solved in a way that delivers ROI.

Too many people approach it from the standpoint of: we give them the software and let them figure it out.

We heard recently from one of the foundation model lab companies. When they worked with their first enterprise customers, they gave them the API for a customer support use case. The customer said “great, now what next?” Both parties were looking at each other, waiting for the other to do something.

The lab was like, well, here’s the API, give it to your developers and build with it. But the customer’s expectation wasn’t an API. The expectation was: you help us solve the inefficiencies in our customer support.

That’s the mismatch even big, well-funded companies see.

With FDEs, there are two levels of what you’re selling. The first is outcomes. The FDE’s job is to make sure the outcome shows up in the form of results.

But where we can improve leverage for FDEs is when they start to own transformation rather than just outcomes. Outcomes happen at an individual workflow layer. The more we can give FDEs leverage to launch faster, they’re looking at transforming teams, organisations, entire functions.

That’s what transformation officers, COOs, CIOs are looking for. They want a thought partner who can help transform everything they run, not just deliver outcomes on particular workflows.

Who should own discovery, product or FDE?

This speaks to an existential question that many companies don’t always get to: do we see ourselves as an AI-powered services company, or do we see ourselves as a SaaS company?

For companies that present themselves as AI-powered SaaS with those investor expectations and margin pressure, the FDE’s work initially closes the gap between the product and the end customer. But ultimately the FDE’s job should be the final 20%, and the value has to come from the core product.

The way this works is if you set up a very good feedback cycle between the FDE and the core product team. It has to go in both directions.

You want to make sure the forward deployed team is always implementing the latest version of your product. We hear even at very large companies, FDEs will say they ship so quickly that sometimes they’ll show something to a customer and realise they’re implementing an obsolete version of the SDK because something shipped last week and they didn’t know.

But then on the flip side, FDEs see the truth and reality on the ground. You will always get higher signal from actual deployment than from the discovery questions a PM would normally do. Those are always hypothetical: if we built this, would you use it? Would you pay for it?

The highest signal is the customer telling the FDE: I need this feature right now because I have this workflow, I have this ROI in mind, and I need you to solve this problem for me.

If the FDE is seeing the same thing four or five times, that’s probably a failure on the core product team. They’re not building into the platform the things they’re hearing repeatedly. That’s a failure of product management.

I’ve heard people say FDEs aren’t qualified to influence product decisions. Do you think there’s a point where they overstep, or is the problem that they don’t push enough?

It’s an org structure thing. And partly culture.

The really successful companies are the ones where FDEs feel empowered to say: we are ultimately the authority on what the customer is saying and what the customer problems are. Because we are embedded. We deal with their problems day to day. We know their workflows. We know their systems.

That’s the highest signal you can get. FDEs have to feel empowered, but product teams also have to make sure they listen to those signals.

The best product managers at B2B companies also work with design partners constantly. In many regards, that’s a shallow FDE motion, just for a very small number of customers. It’s no different at scale when you build out the FDE motion.

Any team that’s not able to leverage that feedback cycle is giving up on a goldmine of data coming straight from customers.

A lot of startups are hiring one FDE and trying to use the role to find product-market fit. But companies like Palantir say FDEs are for scaling, not for finding PMF. What do you think?

With AI, even the definition of product-market fit is evolving slightly. You can build products so quickly, build solutions so quickly.

Product-market fit assumes a paradigm where you have a certain budget to build product, both in terms of time and resources. That’s why we think in terms of minimum viable product. How little do we need to build?

That paradigm has shifted. It’s never been easier and faster to build.

That’s what enables this new motion where FDEs can build a bunch of things before you have product-market fit and figure it out along the way. Earlier, a team of 20 people could only build one product with three design partners. Now a team of 20 could, in theory, build five very different solutions within a vertical.

You still want to strike that balance. But it’s a lot more possible to build faster, as long as you have some understanding of how this comes back into the product.

There are things you simply can’t productise easily. If you spend a lot of work building an integration with a specific enterprise company’s middleware that Accenture built 15 years ago, that’s one-off no matter what.

But that’s different from saying: as an insurance company, we’ve only done claims processing, but now we also want to be part of underwriting. We’ll do that with a new customer first, knowing parts of it can be reused across all customers.

Tanay recently left Orby to start a company focused on institutional knowledge for enterprise AI. I asked him what problem he kept seeing that made him want to build it.

What’s the core problem?

When working with large enterprises, they’re looking for outcomes and then one level above that: transformation of the organisation. Outcomes across multiple workflows and teams.

There’s no way to solve problems for them without being deeply embedded and being deep experts in everything that customer does and how they do their business.

How a company operates is a strategic asset. Even operational things like how they recognise revenue or structure their order forms or sales processes. This is strategic for them. The models will never be pre-trained on this.

That’s why embedded functions like FDEs will continue to exist, just like they always have for enterprise software. The total cost of ownership for enterprise systems has always been 60-70% consulting, services, management, and 30% the software license cost.

But now with all these scale-ups and startups that have FDEs, they’re raising money at SaaS multiples. The numbers they target are about one to one and a half million dollars revenue per FDE.

There are multiple ways to structure this. You work with one really big enterprise client with multiple workflows worth that much. Or every individual FDE works with 10 to 15 workflows, each worth around 100k.

In both cases, you still need to solve that fundamental institutional knowledge discovery problem. How I integrate with company A’s middleware isn’t always translatable to company B.

The motion simply doesn’t scale to support the economics without heavily automating certain aspects.

We can increase the time to value for the end customer, the time to revenue for the people who have FDEs. Through discovery, it also strategically opens up what the end goal is: now the FDE can spend more time thinking at a transformation level rather than going back into a Gong recording and looking at minute 23:40.

You mentioned 1 to 1.5 million per FDE. That’s a specific number.

Forward deployed functions are a revenue function. Even if it’s forward deployed engineering. It’s a revenue function because that’s the gap from your bookings to revenue, or your contracted revenue to actual revenue.

Making sure the margins work is essential. If you’re bottlenecked on an FDE team, that’s a direct bottleneck on your revenue.

That’s how every company with a forward deployed function should be thinking about their deployment teams.

For you as a forward deployed company, your 50th deployment has to be substantially faster, like four times faster than your 10th deployment. That’s what makes the economics work.

Tanay Padhi is a product leader and founder. Previously he led product at Orby AI, building agentic process discovery tools for enterprises.

Europe has the talent. We have world-class universities, exceptional engineers, and founders with genuine ambition. What we don’t have is the infrastructure, the culture, or the urgency to turn that talent into globally competitive companies.

And the gap is widening.

The Numbers

European startup valuations are 29-52% lower than their US counterparts across all funding stages. The gap is most pronounced at the earliest stages, where Seed and Series A rounds in Europe trade at roughly half the valuation of equivalent US companies.

This isn’t about quality. It’s about market structure.

The US is a single, homogeneous market of 330 million consumers sharing one language, one currency, and one regulatory framework. A startup in Austin can sell to customers in Boston, Seattle, and Miami without changing a single line of legal text. In Europe, scaling from Amsterdam to Paris to Berlin means navigating three different legal systems, three different tax regimes, and three different sets of employment laws.

The median post-valuation at IPO for European companies listing on domestic exchanges is $46 million. For European companies that list in the US instead, it’s $631 million. That’s a fourteen-fold difference that shapes every investment decision along the way.

The Culture Gap

The structural problems are symptoms of something deeper.

When I lived in Austin, I could choose between dozens of tech events on any given evening. Meetups, pitch nights, founder dinners, hackathons. The entrepreneurship culture was so embedded that conversations at coffee shops regularly turned into introductions to potential investors or co-founders. In Amsterdam, I’m lucky if there’s one relevant tech event per month.

This matters more than it might seem. Ecosystems aren’t just about money. They’re about density of ambition, about the normalisation of risk-taking, about the assumption that building something is a reasonable thing to do with your life.

In the US, saying “I’m starting a company” is met with curiosity and offers to help. In much of Europe, it’s still met with raised eyebrows and questions about your pension plan. Personal bankruptcy in the US is a data point on a founder’s journey. In Europe, it can be a social stigma that follows you for decades.

There’s a story that went viral recently about a founder in San Francisco who brought his laptop to a restaurant to work on his side project between courses. He hit a bug he couldn’t fix. The waitress noticed, looked at his screen, and offered to debug it for him. She was an engineer working a second job.

That story would never happen in Europe. We don’t lack engineers, but the density of ambition simply isn’t there. The probability of your waitress moonlighting as a developer building something on the side approaches zero.

The Quality of Life Trade-off

I should be fair here. Europe offers something the US doesn’t.

I remember my first time in San Jose, having drinks with a friend and his wife. After a few cocktails, he suggested we try the next bar. I got up and started walking. He looked at me like I was insane. We got in the car and drove for five minutes.

In most American cities outside New York, you move with intention. You get in a car, you have a destination, you execute. In Amsterdam, I’m tempted to stop at least twice on my seven-minute bike ride home from work. A terrace here, a canal-side bar there. Cities are designed for pleasure in a way that American suburbs simply aren’t.

This quality of life is real and it matters. European healthcare, parental leave, walkable cities, work-life balance. These aren’t small things. They’re genuine competitive advantages for attracting people who want to build sustainable lives.

But here’s the tension: the US startup ecosystem is built on a cultural acceptance that personal life temporarily takes a backseat when you’re building something. That trade-off is baked into the expectations. In Europe, we’re not willing to make that trade-off to the same degree. That’s a legitimate choice, but we need to be honest about its consequences.

The Policy Gap

Mario Draghi’s 2024 report on European competitiveness was supposed to be a wake-up call. It laid out 383 specific recommendations for closing the innovation gap with the US and China.

More than a year later, only 11% have been fully implemented. Another 20% are partially done. Nearly a quarter haven’t been touched at all.

This is the European disease. We’re excellent at diagnosis, world-class at producing reports, and utterly mediocre at execution.

The good news is that some things are finally moving. In January, Ursula von der Leyen announced EU-INC at Davos, promising a 48-hour digital incorporation framework that would let founders register a company once and operate across all 27 member states. It’s being called the “28th regime” because it would function as a virtual 28th country sitting above the fragmented national systems.

This is exactly what Europe needs. A startup in Amsterdam shouldn’t have to re-incorporate when it expands to Germany. The friction of 27 different legal systems is a self-imposed handicap that no serious competitor would tolerate.

But EU-INC is scheduled for 2027. The legislative proposal is expected later this year. Then comes negotiation between member states. Then implementation.

By 2027, the US will have pulled further ahead. China will have continued its aggressive industrial policy. And European founders will have spent another two years navigating unnecessary complexity while their competitors scaled.

The announcement is welcome. The timeline is not.

What Actually Needs to Change

If Europe is serious about competing, we need action in four areas.

First, the unified market needs to happen now, not in 2027. EU-INC is the right idea, but the implementation timeline reflects the usual European pace: thorough, consultative, and too slow to matter. Every month of delay is another month where founders choose to incorporate in Delaware instead.

Second, tax incentives for early-stage investment need to match what the US and UK offer. The UK’s SEIS scheme gives investors 50% income tax relief on investments up to £200,000 in qualifying startups, plus capital gains exemption if shares are held for three years. The US recently expanded its QSBS exemption, allowing investors to exclude up to $15 million in capital gains from federal taxes on qualifying small business stock. These aren’t minor tweaks. They’re structural advantages that make angel investing dramatically more attractive. Most European countries offer nothing comparable.

Third, education needs to embrace entrepreneurship as a legitimate career path. This is cultural as much as institutional, but universities and secondary schools could do far more to normalise the idea that building something is a reasonable thing to do with your life.

Fourth, we need to accept that European founders will sometimes need to access US capital markets. Rather than trying to prevent this, we should make it easier for European companies to maintain their European identity while tapping into deeper pools of growth capital. The goal shouldn’t be to keep companies from going to the US. It should be to ensure they stay connected to Europe when they do.

The Window Is Closing

I’m optimistic about Europe. The talent is here. The quality of life is a genuine draw. The recent policy momentum, from the Draghi report to EU-INC, suggests that leaders finally understand the stakes.

But optimism isn’t a strategy. The gap between Europe and the US isn’t static. It’s growing. Every year we spend on consultations and impact assessments is another year where the structural advantages compound on the other side of the Atlantic.

The waitress in San Francisco debugging code at a restaurant isn’t just a cute anecdote. It’s a signal of ecosystem density that Europe hasn’t achieved and won’t achieve through incremental reform.

We need to move faster. We need to act, not just announce. And we need to be honest with ourselves that the comfortable European approach to building ecosystems isn’t working.

The talent is here. The ambition is here. The infrastructure and incentives are not.

That’s fixable. But only if we stop admiring the problem and start solving it.

You spent seven years at Palantir across different roles. What did you learn as an FDE that you couldn’t have learned as a software engineer?

The FDE role accelerates learning a lot. Coming from academia, where you work on these super long projects that are very obscure and specialised, it was a bit of a rebound exercise for me.

The FDE role was fun and exciting because I got to do something different almost daily. I also got to deliver value very quickly. Unlike academia, it’s highly gratifying.

What FDE managed to do for me was horizontal learning. I didn’t specialise in one thing. I was always identifying what’s the highest value thing I could be doing, and then learning through that.

There was this entrepreneurial exposure: what are my client’s problems, how do I solve them? But then also: I suddenly need to think about stability, so I’m an SRE today. Or now I need to design a UX. Or I’m a product manager working with internal teams on the product story, but I’m also doing backend debugging. You just did a ton of different things.

You joined Palantir early in Foundry’s development. What was that like?

Foundry did not work. I joined two months before the first release and it was just not great. Very bad.

But that’s actually what made the FDE role so valuable. Working with users to understand their problems and how they do their work, and then using that as a means to actually improve Foundry — that was the job. The product wasn’t there yet, so we had to figure it out alongside the customers.

You now help companies implement the FDE model. When a company comes to you wanting to “build like Palantir,” what do they usually get wrong?

The first thing I always dig into is: why do you need FDEs?

The FDE thing is not really a new idea. It’s the standard advice that has existed in the startup world. Y Combinator, anyone: as founders in early stage pre-product-market-fit, go work with your users, understand what they need, and solve their problem in a way that doesn’t scale. Then once you have product-market fit, worry about scaling.

Palantir did the same thing, except the ambition was very, very high.

Did Palantir have product-market fit when they started the FDE motion?

They didn’t. Foundry didn’t work. That’s the definition of: we have a market we’re targeting, we have some idea of what the product should be, but the product isn’t there yet.

As the product matured, a lot of FDEs moved internally and became Core Software Engineers. They started thinking about how to scale. That was a natural evolution as the platform became mature and stable. The hiring scaled as well. It just happened later in Palantir’s trajectory because of the market they were going after and the very high ambition of wanting to be the operating system of the largest enterprises in the world.

So the thing I always dig into is: do you really need FDEs? Why do you think you need them?

Getting to the bottom of that question is important because it’s not an easy function to implement. Hiring for the role is very hard. The standard trap a lot of companies fall into is they basically just build a services wing. You can do that and it’s fine. But if you want to be a product company and that’s why you’re building an FDE org, you want to avoid falling into the trap of just providing services.

Then how you structure the teams and their interfaces becomes difficult to manage because incentives are not aligned in the short to medium term, even though they’re aligned in the long term.

There’s pull from product, pull from services to sell more, to upsell...

There’s that, but there’s also the pull from FDEs. The FDEs are pulling product in one direction, and the product team is pulling it in another direction. That friction is good because it results in a better product. But it’s not great for morale, and it’s very hard to manage.

Do you think FDEs are qualified to define how the product should look based on their customer interactions?

They are the ones forming opinions based on what’s working and what’s not working.

But is there a danger the product goes in too many directions?

Exactly. A good example is the Palantir ontology. It could have easily fallen into the trap of defining what the ontology should be for different verticals. If you’re a bank, this is the ontology you should use. These are the object types and relationships.

There was this realisation that we don’t want out-of-the-box things. We want a configurable ontology, a higher level abstraction. That came from product.

The FDE’s focus is: I need an airline object, I need a flight object. If the FDE was writing code, they would have probably just hard-coded all of those things and not thought about making it configurable.

Making it configurable takes longer. You have to go through proper design. And the FDE is impatient because they want to solve the business problem. It’s very short term.

So the short-term goals are very misaligned. But in the long term, having that signal from the field is what shapes your product the correct way.

With over a thousand companies now hiring for FDEs, I asked what startups should actually take from the Palantir playbook.

There are now over a thousand companies hiring for FDEs, many with just one or two. What’s transferable from the Palantir model?

First, ask yourself the question very honestly: why do you think you need FDEs?

There are largely two buckets of FDEs. There’s the product-facing FDE who helps shape the product. And there’s the business-facing FDE who does the land-and-expand motion of what more can we be solving.

Another way to think about it: if you think of the phrase “product-market fit,” one type of FDE is going after the product, one type is going after the market.

If you have either of those needs as a startup, then the motion makes sense.

Think about the timelines too. It’s not like you answer the question once and it’s done. You have to keep asking: do we still need FDEs? There’ll come a point where you won’t need it.

For the individuals functioning as FDEs, treat it like a future founder job. Someone who wants to build something. Someone who will do whatever it takes to figure it out and drive outcomes. If you keep doing that, you’ll be a good FDE.

It’s no surprise that a lot of ex-Palantir people are founders today. It was the training ground.

What do you look for when hiring for FDE roles?

It’s a misconception that one person did all those things at Palantir. There were different types of FDEs who did different things.

I’m a huge fan of the Palantir hiring approach: you hire spiky profiles. You hire people who have a huge spike in something. You don’t hire people who are six out of ten in everything. It’s rather ten out of ten in something. And others can be lower. Then you think about how to assemble teams with complementary spikes.

So it depends on who you have and what your business strategy is. That will guide what type of people you need. The FDE role is not well-defined, which I think is by design.

I’ll give you a slightly more satisfying answer. Go up one level in abstraction. You look for people who are very value-oriented, who think about what’s the most valuable thing I could be working on, and have the autonomy and agency to go do it. People who have high grit, who can tolerate a lot of pain because they’re working on something valuable. And people who are critical, who question things and think from first principles. Just because the CEO says something doesn’t make it true.

A lot of startups are hiring one FDE and expecting them to service five, ten, fifteen customers. Does that work?

I don’t see how. Honestly, this is true today at Palantir where one FDE services multiple clients. But that works because the product has come that far.

So it’s a lot of configuring, not a lot of building?

There’s a bit of building, but it’s just a lot quicker to build. When I joined, it would be a team of three to five people working on one use case with one client. That transition happened purely because the product works really well now.

So Palantir started with one FDE per customer, then as the product matured, one FDE could service more. But now startups without a developed product are trying to have one person service multiple customers from day one.

Yeah. I’m working with two founders right now, still in stealth. The way we’re approaching the FDE function: they haven’t really hired for FDEs yet, but we’re going to try having an internal software engineer do this. He’ll be attached to one customer. The most important customer, not in the sense of revenue, but where we get the most product signal.

That’s his job: make that customer successful. They have around ten or twelve customers, but he’s going to work on just one.

It goes back to the first-principle question: why do you think you need FDEs? The answer should be either to expand the market you’re attacking or to shape the product. I can’t imagine one FDE servicing ten clients being able to provide signal on either of those.

We talked about the future of the role.

There are a bunch of YC companies building platforms specifically for FDEs. Do you think there’s a need for those?

I don’t know if such a thing exists. The role is so general and ill-defined by design that you want something super general purpose. For specific companies and their specific flavour of FDE, there will be tools tailored for them.

Looking three to five years out, do you think this role will still exist? Or will it be broken into multiple smaller roles?

It will still exist. Any company that values innovation, any company whose success depends on their ability to innovate, will need these people.

In theory, that should be every company. You could run a professional services company and not innovate at any point and be extremely successful. But for startups, yes, you’re going to have to innovate.

It doesn’t matter if you call it FDE, entrepreneur in residence, whatever you want. But what the title does is give you the freedom and autonomy to go do the valuable thing.

Anjor Kanekar advises early-stage companies on FDE hiring and operating models. You can find him at anjor.xyz.