Forward Deployed Engineering
Sorted into 8 categories: what the role is, where it ends and consulting begins, how it gets measured, and what these teams screen for when they hire. Answered by the leads at Ramp, Nominal, Dataland, OpenAI. Pick a category, open a question, or click a timestamp to watch the answer.
Where each question sits in the 52 minute recording51:44
Each tick is one question, coloured by category. Click a tick to jump to it.
What the role actually is, in each company words, and what forward deployed really means in practice.
There is no agreed definition. Each company describes the job by what the team is responsible for, not by what it does day to day.
At Ramp the team has one job: win big enterprise customers. How they do it is left deliberately open. They are allowed to build inside the main product and do whatever winning the deal takes.
FDE at Ramp has a mandate to win enterprise, the upmarket segment. And the way we do that, we are allowed to get very creative.
Nominal sells to people building satellites, nuclear reactors and other hardware. The role has been central since day one. The important part is finding where the product runs out of road and feeding that back into what gets built next.
Learn where the bleeding edge of product is, what do our users need to fully unlock their workflows, and how does that feed into our longer-term product roadmap.
Dataland builds AI that takes over work people do today, across healthcare, energy, consumer electronics, logistics and waste. Every customer gets a different agent, so the role is not a layer on top of a product. It is the whole company.
It's literally the lifeblood of the company.
OpenAI wants two things: more people using AI, and better models. Those become the team's two jobs. One group finds problems that repeat across many companies, builds with a customer, then ships a product or folds the work into Codex. The other takes the hardest industries and works with researchers to improve the model itself.
We're the tip of the spear for OpenAI with the enterprise, and we try and make things repeatable, and we try and push the bounds of what the models can do.
The name suggests being physically deployed. At Ramp it does not work that way.
Ramp's engineers rarely go on site, roughly once a quarter, and mostly work over video calls. Forward deployed means direct contact with the customer, not sitting in their building.
We don't actually visit them all that often. So, like once a quarter or so, you will mostly do it over Zoom.
Both Calvin and Jason call the alternative a game of telephone. This is the clearest statement of why the role exists at all.
An engineer who knows both what the customer needs and how the codebase works can see answers nobody in the relay would ever suggest. That is how you win the customer without wrecking your plans.
One very smart person, a great engineer with all of the context necessary can produce brilliant solutions that a game of telephone will inevitably miss.
He had to learn ordinary sales skills himself, because Palantir did not teach them in his day. His point is that the value comes from engineers building the relationship directly, instead of information passing through a sales layer.
Part of the magic of forward deployed engineering is just making sure that there's not a game of telephone.
Where the job stops. What belongs to the customer, what belongs to the product, and which titles do what.
Nominal's first large contract. The customer tested drones and wanted more of their team looking at flight data.
The customer wanted forty people looking at the data after each flight instead of two. The blocker was that data had to be cleaned up by scripts sitting on individual engineers' laptops before anyone could use it.
His goal was get 40 people in his organization looking at data every single flight. On average before us it was two.
The customer simply asked Nominal to handle it, without knowing what that meant technically. An engineer named Ross built it, but deliberately made it general: a container that holds the data-cleanup logic rather than something tied to one customer's format. It unblocked that customer and became a core feature sold to everyone else.
This was on our road map, I knew we would build this at some point. We just pulled it left because the opportunity presented itself.
Jason describes the version worth aiming for, which is a useful checklist when judging a company you might join.
Four signs it is going well: they value the product itself, you teach them how to use it, they treat you as a thinking partner, and they give you blunt feedback. The best ones will host your team so you can build alongside them.
There's a really magical sweet spot. They value the product, you teach them about the product and they view you as a thought partner.
Asked by an audience member finishing at MIT and about to start as an FDE, trying to tell similar-sounding job titles apart.
The clearest breakdown of the night, at least as OpenAI draws it. Solutions engineering happens before the sale, for the broad market. Solutions architecture happens after the sale, for that same broad market. FDE is a separate business unit running only about ten engagements at a time, brought in very early when a problem looks like the right shape, then owning everything before and after the sale as one team.
FDE is actually a different business unit that is separate from those, and we only really work like 10 engagements at a time.
Because they check whether the work has milestones and could turn into repeat revenue, the team turns down more than it takes on. Plenty of problems are interesting without ever reaching the scale that justifies this team.
We have to say no more times than we have to say yes, because there's a lot of people with interesting problems, but not every problem is going to get to scale.
What better models changed about the work, and what was already true before AI.
It sounds backwards. Better models should mean fewer engineers needed in the field, not more.
There is far more work to go after now. Old software picked one task, built one tool, sold it to everybody, and only so many tasks are shaped like that. Companies spend far more on people than on software, and the work people do varies enormously from place to place. AI can finally reach that messier work, but only if an engineer understands the job well enough to nearly do it themselves.
You need engineers who actually really understand the use case.
Why coding tools got good first: every software engineer already does the work the tool is automating, so the whole industry understands that job deeply. No industry has that for energy or logistics, which is exactly why someone has to go and learn it in person.
Every software engineer is naturally a forward deployed engineer in the coding space, because we all code every day, and that's why the coding agents are so good.
The work moved up a level. A year ago most of the time went on wiring things together and building tests for five separate agents, which limited how hard a problem you could take on, because the customer still needs to see something soon. Since about January the models handle long tasks well, so far less time goes on plumbing and far more on the actual problem.
You build a lot less plumbing and you spend a lot more time solving actual use cases.
His example: fourteen months with a chip company. The first ten were spent speeding up their software work, including an agent that debugs failures on its own. Only now are they building agents that help design the physical chip, because the basics underneath are finally reliable.
We can kind of trust that Codex is going to do the bottom 50% of tasks pretty well, and so we can focus on the higher level tasks.
Jason disagrees with the framing. He interned at Palantir in 2012, long before any of this.
He says AI is not the cause. Palantir was simply the one company willing to spend heavily on a field team, and he thinks most attempts at that bet fail. What has actually been happening for years is that software keeps getting cheaper to build, so the range of problems worth attacking grew steadily, then jumped with AI.
Maybe in 99 out of 100 multiverse paths it would have failed, but it just happened to work.
What stays constant across every era is judgement about which work belongs to the customer and which belongs to your team, which depends on your business model. You know it is working when you notice yourself building the same thing at several customers, because that shared piece gets pulled into the main product.
You always have to have this kind of a taste around, what is the customer's job versus what is something that our forward-deployed team would do.
The customer's world decides what you build. Ramp sells to finance teams who mostly do not write code, which is why Ramp shipped an agent that works inside Excel. Go where the customer already works, not where you wish they worked.
They're in Excel.
When this works well, sales, product and research stop being separate activities.
The model is outcome first, then scale, and there are two ways to scale: build a product, or improve the model itself. His example is slide making. The model was bad at it, and a Japanese sales organisation of about two thousand people wanted a slide assistant.
Outcome first, so always success and then scale, and you've got two ways to scale. One is product, the other is through the model.
They worked out how to describe the task so the model could do it, starting with fixed boxes, which looked terrible, then generating HTML instead. Around fifty approaches later they picked one, produced many examples, handed those to the research team, and three months later a new model version made good slides.
FDEs embed with the customer, figure out how to represent the task to the model, generate lots of examples of that, and then the research team can understand how to make the model do that thing.
A phone company wanted AI to handle voice customer service. At pitch time the model failed a trivial test.
They ran ten attempts at simply getting the model to read his phone number back, and it would not do it. Alarming, given the real job involves following company policies on live calls.
We did a test of 10 to just get it to read back my phone number and it just would not work.
Six months of work with the research team later it shipped. He says roughly 70,000 calls a day are now handled, with no serious failures. They also built tools so the customer can write their own tests and keep improving it without the team, which he calls the goal.
Something like 70,000 calls a day getting deflected, and no major jailbreaks so far.
Asked as a joke. The answer is a useful reality check on how good the output really is.
His team includes former consultants who joked about mourning their old colleagues. Then he punctures the hype: the slides are not actually good yet, so nobody is out of a job soon, even if the direction is clear.
The slides are actually not very good. So it'll take some time before McKinsey's out of a job.
How custom work turns into a consulting business, from both sides, and how these teams avoid it.
The question the panel keeps returning to. Where is the line between custom work for one customer and something that belongs in the product?
He says he has scars from this. Palantir went through a stretch the team called the dark ages, when the field team effectively rebelled, said the original product was useless for the work they were doing, and started building new things instead.
Palantir went through a few years of what we call the dark ages where the FD team essentially revolted.
To avoid repeating that, Nominal's first field engineers were people who had built products themselves and had been on the receiving end of the relay, so he could talk honestly with them about whether they were drifting into consulting. He notes this work can genuinely speed up a sale, which is sometimes a straight win, but says spend that goodwill carefully as the team grows.
I could have really high trust conversations with them that they weren't basically going off and doing consulting.
Howard raises the question Palantir argued about internally for years, and gives the answer it landed on.
For years Palantir genuinely did not know whether the model was a flaw to engineer away or a real advantage. By the time he worked there, the answer inside the company had settled firmly on advantage.
Palantir wasn't sure for many years, but even in my time there, the realization was FDE is a huge feature. It's not a bug.
Colin's diagnosis of the failure mode, plus the structural protection he credits at OpenAI.
The money is addictive. Once services revenue is flowing, the incentive is to sell bigger and bigger custom projects, and nothing pushes back. What protects OpenAI is that the commercial side is not where power sits, product and research are, so the team gets pushed toward work customers can eventually run themselves.
The services revenue is like a drug that they just can’t get off of, and they keep selling bigger and bigger custom things.
Asked for the founders in the room. Revenue is climbing, but nothing reusable is building up underneath it.
He flips the usual worry around. The danger is not only that your company gets hooked on the money. It is that the customer gets hooked on the specific people, so removing them gets you fired.
The customer is addicted to the forward deployed engineers more so than you as the company are addicted to the services revenue, and then when you try to pull the forward deployed engineers away they just fire you.
Asked by a working FDE in the audience, who names the tension plainly: you hire people who want to say yes and own the outcome, then need to pull them out without losing the account.
Ramp spreads people thin on purpose. Any one customer only ever gets about a third of a person, so dropping to a quarter or a sixth is barely noticed. They have never put two engineers on one customer.
We stretch our FDEs very thin at Ramp. So any given customer, they only ever had like a third of an FDE.
He admits this departs from the traditional model, but says it creates the right incentive. Because every customer is asking for something, the engineer has to weigh all of it at once and decide what actually matters to the business.
The FDE has to look at that holistically and think to themselves, what will actually move the business.
He treats the fear as a diagnosis. If reducing headcount would get you fired, then you never did the work of making the value come from the system rather than from people.
If the customer's going to fire you because you reduce the headcount, that means you haven't done the value engineering.
Dataland also runs many accounts per person, so customers never come to expect a standing crew. Part of the job is saying out loud that the customer is buying an outcome, not a number of hours from a number of people.
Part of the FDE's job is to communicate that that's not what they're buying. They're buying the outcome.
The blunt structural tool is a time limit. He has seen companies assign engineers to one customer for twelve or twenty-four months or longer, and others that cap it at six weeks as policy.
I've seen companies that have FDEs assigned to customers for 12, 24 months, or even longer. And then I've seen others where it's like 6 weeks as a rule.
How the team is judged. Revenue per head, what value lasts, and which engagements pay off.
Howard moves the question away from job titles and culture, and onto the numbers.
It is not about having a platform. It is whether you deliver value that keeps arriving, off a cost you pay once. That is what makes investors treat a business as software, and he says there are many ways to satisfy it without selling one product to everybody.
The question is, is there recurring value that you're delivering to your customer on some sort of fixed cost.
Because code is getting cheaper to write, he is deliberately not attached to finding one thing to sell everyone. The test he applies instead: what does each customer teach us that makes the next custom agent cheaper to build? Once an agent runs a real workflow at scale the recurring value is large, so every use case has its own version of this equation.
How can we have this flywheel of learning that reduces that initial fixed cost?
The premise: if the work succeeds, you should eventually be able to step back, because what you built lets the customer carry on alone.
His first answer is deliberately blunt arithmetic: enterprise revenue divided by salaries. Then the real version, which is that the team is always either shaping what gets built next or building it.
It's really simple at Ramp. We have the revenue from the enterprise customers and the costs of the salaries. Do that division and you get the ROI.
They prefer shipping a planned feature over something custom, because custom work has to be maintained forever. Ramp's engineers work inside the main codebase, partner closely with each product team, and keep changes small on purpose.
We love it when we can build a road map feature for the customer instead of having to build something custom cuz the custom stuff tends to require more maintenance.
OpenAI runs the opposite shape. They bet on problems worth hundreds of millions, so fewer customers and much more depth. Their biggest engagement has about fifteen engineers at one chip company, trying to change how an entire industry works.
We generally go deeper with a fewer amount of customers.
So the money from the field work itself is a minor concern for them. The real measure is the recurring revenue unlocked later, when many smaller, faster-moving customers adopt what was proven with one large one.
The services line is a small focus, but the bigger focus is what is the long-term value.
Not the answer most people expect. The biggest projects are not the most valuable ones.
The most profitable work over time is the small, product-shaped kind with two to four engineers, not the huge engagement. Big custom projects generate revenue now and very little that carries forward.
Probably the most long-term profitable engagements are more the product-based ones, which might have only two to four FDEs.
Howard uses the same measure as Ramp, revenue divided by headcount, but adds a test for whether the value sticks.
Dataland was two people going to three, aiming for around ten, so revenue per person is the number he watches. Build whatever the customer asks for and the asks never end, and the value shows up once then disappears. Sometimes you build the throwaway thing anyway to earn trust, but the long-term test is value that keeps arriving from a fixed amount of work.
If you just build whatever they ask for, there's infinite things they'll ask for, and it might deliver a momentary piece of value, but then that value evaporates.
Dataland reached real scale with two people. Where does the leverage come from?
Much of their time goes into building agents that help them build agents faster. His deeper point is that an agent is never a finished object. It lives inside a business whose systems, policies and product lines keep changing, and the agent has to keep up.
No agent you build is a static thing in time. It's a dynamic actor within the enterprise context of your customer.
So the real engineering problem is automating the improvement loop itself, so the agent keeps pace without a person nudging it. That is what lets a tiny team earn many millions per person.
You actually must figure out some sort of mechanism to actually autonomize the outer loop.
The fight between one customer needs and the main roadmap, and who wins.
Calvin says Ramp's reason is less lofty than the others. The team exists to stop something bad from happening.
He names a trap many software companies fall into. You build a product people love, growth comes easily, then you see how much money big enterprises spend. You chase those deals, and your plans get wrecked by features that help exactly one customer. An FDE team is the usual fix: the main teams keep building the plan while this team absorbs the enterprise work. He admits it is an unglamorous reason, and that it is honestly how Ramp's team started.
I say it's a sword and a shield. We're trying to win the enterprise deals and we're trying to protect the core teams.
Ramp is known as a product-driven company, so what was the conversation that changed it?
They were heading straight into the trap and spotted it in time. The big projects enterprise customers asked for were not things Ramp would have built otherwise, which made it a real problem to solve rather than a scheduling annoyance.
These large projects that the enterprise customers are asking for, this is not what we were planning on building.
The fix was removing the relay. Before, the customer told the account manager, who told the product manager, who told the engineer, who said no, and it went back around. Now the engineer talks to the customer directly.
That’s what we were doing before we had FD, and it was causing roadmap delays.
Colin says the plan has been rewritten twice in about a year, and one rewrite deleted most of a planned product line.
At the start there was no platform, just the API, the customer, and an engineer in between, so success meant getting anything working at all. He cites the widely quoted finding that only about 5% of companies see real returns from AI spending.
When we started, we didn't have a platform at OpenAI. It was just the API and then the customer and then you were in between.
Six months before the panel the plan was around fifty small products, maybe with other people building on top. Then Codex got better, and the test for every idea became whether it could just be a Codex extension. That killed roughly 80% of the planned products.
Now the question we ask of every product is, can this just be a Codex extension? And that probably ate like 80% of the products that we were making.
Two survived because enterprises need very consistent output: writing regulatory documents, and a workflow automation tool. Everything else folded into Codex. The standing questions are now whether it could be Codex, whether it truly needs to be separate, and whether the model could simply get good enough on its own.
Can this be Codex? If not, does it really have to be a separate product? Could the model just get smarter and be good at this task?
An audience member notes Ramp is clearly platform-first, and asks whether earlier-stage companies instead discover the product through field engagements.
He ties it to those expansion and narrowing phases and says the answer is changing for Nominal right now. They are finally big enough to build a real platform, and the field team is the honest test of it: do they find it useful, do they build on it. He credits Palantir for doing exactly this until customers could build on it directly.
In many ways they will be the first users of something that you claim to be a platform.
At Ramp the platform comes first, because they already know what it should do. The field engineers work out how to achieve that inside each customer's constraints rather than inventing something new. But there is a cycle: when many customers hit the same blocker, it belongs in the platform, and that is when one of these engineers gets to work like a core engineer. Same if something already planned needs to arrive sooner.
That's where an FDE does get to act like a core engineer.
What they screen for, what backgrounds get in, and how the interview differs.
The most directly useful question if you are trying to get hired. All four answer, and the answers do not fully agree.
Two skill sets that rarely appear in one person. You need to be genuinely strong technically, keeping up with how fast models change, and also good at ordinary software engineering, because connecting to enterprise systems is hard, unglamorous work.
You have to be really good at traditional software engineering as well because you're building really complex integrations.
The other half is the customer side: winning trust, then understanding and navigating the politics of their organisation. He says openly that people who can do all of it are very hard to find.
You have to figure out the politics of their organization and map it out and traverse it.
Only one of his five Palantir years was in the field, but he says he still draws on it constantly, including later as an early engineer at startups. What it taught: be resourceful, be a generalist, stay curious across subjects, and be humble when the situation calls for it.
You have to be really scrappy and kind of be super generalist in the way you solve problems.
Ramp likes former founders and early engineers, specifically people who care about revenue, which he says many engineers do not. His framing: this is the team that wants to say yes, because it cares about winning the customer, while many engineers would rather say no and keep building their own thing.
The FD team is the team that wants to say yes because they care about us winning that customer.
Having grown the team from two people to more than ninety, he names one trait above all: caring about the result more than the thing you made. The usual failure is falling in love with your own work, so when nobody uses it you defend it. The best people throw their own work away and build something different because that is what is needed.
So much of the time people love the form of what they've created more than the function.
Howard makes the strongest version of this claim, having gone from Palantir to co-founding Dataland.
He calls it the best training ground there is for a future founder, and lists why: you have to build from zero to one, stay on the cutting edge of AI, be good with people, win the trust of enterprise customers, and work out the politics of their organisation and navigate it.
I think it’s really sort of the best training ground to be a future founder.
One concrete, checkable difference at Ramp.
There is one extra stage compared with a normal engineering loop: can you actually communicate? Ordinary engineering jobs do not usually put you in front of a customer, so it is not normally tested.
There's an additional screen on the FD interviews that we do where it's, can you actually communicate?
Useful if you are wondering whether your own path counts.
OpenAI’s team is a deliberately mixed bag: people from the big consulting firms, a lot of ex-Palantir people, and a lot of former founders. No single background dominates. What they share is caring only about whether the customer actually uses the thing.
The common thing is that they’re all just like super outcome focused.
Closing question. Each panelist read out a direct work email on stage. Those are in the recording rather than reproduced here, to keep them away from scrapers.
All four confirmed they were hiring, and each gave a direct work email rather than pointing at a careers page, which itself says something about how these teams recruit. Listen to the closing minute for the addresses, or go to each company's careers page.
So there you have it. You can reach out if you're interested.
How these teams are actually organised, and how the structure keeps changing.
Jason's structural advice, with the story that convinced him.
Rotate people, because two organisations grown separately drift apart. One of his happiest moments was watching an early-career engineer fly out, try to use their own product on site, come back convinced it was bad, and get very motivated to fix it. It goes the other way too, when a field engineer cares enough about something to go and build it properly.
If you try to grow those organizations separately, you end up wanting them to be more conjoined so that you can more smoothly rotate.
A caution worth hearing before you take a job based on how the team works today.
Companies go through phases of expanding and then narrowing what they build, and each phase wants something different from this team. So who they should hire genuinely changes over time, and the people who do well are the ones willing to roll with that.
You go through these product expansion and contraction phases, and at different times you might want different things from a forward deployed engineering team.
Asked by a working FDE. Palantir split the role in two: Echo, closer to the customer and the subject matter, and Delta, closer to the code.
Nominal has mission ops, mission development, and a growing sales team. Mission ops are deeply technical but not always coders: often former mechanical or electrical engineers, some who designed engines, though increasingly they write code anyway. The reasoning is that understanding an engineer's workflow is far easier if you have lived it. He calls this a loose descendant of Palantir's Echo role, noting Echoes often lacked the subject background and were instead capable generalists, frequently from consulting.
It's really helpful if you have that background being part of that organization before, and that's why we have the mission ops role.
He was an Echo intern and then a Delta, and thinks AI collapses the split. The division existed because writing code was expensive enough to need dedicated coders while others owned the relationship. If code gets dramatically cheaper, one person can hold the whole picture, which he calls radical ownership.
If you can dramatically reduce the cost of the production of code, then perhaps you can have this radical ownership where one person can actually hold all of that context in their head.
Why he thinks that is better: the same person knows what is genuinely hard and what is easy, so decisions about what is worth building are not made by someone who cannot judge the cost. He is candid that it depends on finding people with that range.
They're not just a pure non-technical person making those value decisions.
He came from traditional consulting and disliked how many narrow roles it had, so OpenAI began with engineers only. They quickly found large accounts needed Echo-style people to carry the account work, so that role came back.
When we started the team there was only FDEs, and we realized very quickly that we really needed the echoes to take up a lot of the work around the account.
Now they are adding genuine industry experts, such as chip verification engineers and working scientists, because harder problems mean writing good tasks and tests inside a specialism. There are deliberately few, on the bet that the generalists learn from them.
When we go up the stack in chip design, we really need to know how to design a chip.
Nominal is around 150 people and still working this out. The advice attached to it is the most portable thing said all night.
They have not settled it. Their mission ops role did not exist at Palantir, so there is no template to copy, and the boundary with sales is still being drawn. His advice to anyone considering these jobs: interrogate the company the way this panel was interrogated, because every company answers differently.
Anyone who's considering a job in forward deployed engineering, ask a lot of questions like this of any company that you're considering working with.
If you are preparing for an interview
Reading them is not preparation. These are the questions FDE hiring managers care about, because they are the ones they argue about internally. Four things that turn this page into an edge:
This is my work: embedded delivery, FDE resume reviews against measured job posting data, and training for Solutions Architects moving into forward-deployed roles. If you are interviewing and want a second pair of eyes, book a slot and bring the job description.