AI Engineer World's Fair 2026
The Dirty Secret of Forward Deployed Engineering
Read the talk
The Dirty Secret of Forward Deployed Engineering
Forward deployed engineering grew from keeping customer installations alive to delivering customer outcomes. Coding agents are now bringing that responsibility into product engineering itself.
From a talk by Natalie Meurer
What are you hiring a forward deployed engineer to do?
Are you a forward deployed engineer, or are you hiring one? Natalie Meurer opens with those two questions. They identify two sides of the same problem: engineers and employers are using a job title whose responsibilities can differ dramatically between teams.
Meurer approaches that problem as Sierra’s head of agent engineering, after roughly two years at the company. Her path began with tech policy at Georgetown’s School of Foreign Service, followed by learning to code and joining Palantir. From 2016 to 2021, she worked on privacy, infrastructure, and forward deployment, primarily with law enforcement and defense customers. After business studies at Stanford, she joined Sierra in 2024—on a team then called the deployment team.
The name bothered her because it did not describe what the team was building. In July 2024, about six months after joining, she published Meet the AI agent engineer. Her initial distinction was useful: agent engineering was a subdiscipline of AI engineering with the same customer accountability as forward deployed engineering, but with its own technical domain. As agent engineering gained currency, harness engineering began emerging as a possible specialization within it. The vocabulary kept expanding.
That proliferation leads to the talk’s provocation: forward deployed engineering “doesn’t exist.” The work certainly exists; the trouble is that the label describes so many kinds of work that it no longer specifies a coherent discipline. Its popularity in AI makes that ambiguity more consequential. To understand what a forward deployed engineer actually does, follow the responsibilities that accumulated under the title—from platform operations to customer outcomes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
First, keep the customer’s installation running
The Palantir job postings that attracted Meurer in 2016 led with location. Where a contemporary engineering advertisement might emphasize languages and technical skills, these emphasized the forward deployed part: sitting with customers, on the ground. Much of Palantir’s ecosystem consisted of on-premises deployments, so physical proximity was part of delivering the software.
The comic stereotype is a new graduate parachuting out of a helicopter while fixing a runtime error. The early job was more recognizably DevOps: platform stability occupied much of the work. Meurer’s own onboarding assignment was to deploy Palantir’s software on an EC2 instance. Before an engineer could make the product useful, the installation had to work.
Her illustrative customer email captures the operational reality: someone has unplugged the instance again, and the engineer needs to come in at two in the morning. Customer accountability initially meant restoring availability. The product’s immediate bottleneck was not another feature; it was a running system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A stable platform still needs data
Looking back to around 2012 in Meurer’s chronology, greater platform stability exposed the next problem. Palantir sold data integration software, but software without integrated data was like a movie theater playing nothing. In the analogy, the theater was not standing in 2008; by 2012, it stood, but there were no movies to watch.
The customer’s response to a functioning platform was that the data still lived in 20 different places. Forward deployed engineers had to connect those sources. Much of that integration work used variants of Java; Meurer also recalls Palantir’s client being written with Java Swing. The job now included DevOps plus data integration, rather than replacing operations with a new specialty.
Integration also required understanding what the records meant in the customer’s environment. Meurer describes Palantir’s ontology here as a taxonomy for the data. A small Java example illustrates the distinction between copying fields and modeling their meaning: two source records become the same kind of customer object only after their identifiers and names are interpreted.
java
import java.util.Map;
public class CustomerIntegration {
record Customer(String id, String name) {}
static Customer fromCrm(Map<String, String> row) {
return new Customer(row.get("customer_id"), row.get("name"));
}
static Customer fromBilling(Map<String, String> row) {
return new Customer(row.get("account_id"), row.get("legal_name"));
}
public static void main(String[] args) {
var crm = Map.of("customer_id", "C-17", "name", "Acme");
var billing = Map.of("account_id", "C-17", "legal_name", "Acme");
Customer first = fromCrm(crm);
Customer second = fromBilling(billing);
System.out.println(first.equals(second));
}
}
In this illustrative mapping, both systems use the same customer identifier. Whether an account really corresponds to a customer is a question about the business, not Java syntax. That is why proximity to the customer mattered for data modeling as well as deployment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn integrated data into something people can use
By 2016, custom solutions added another responsibility. Engineers built applications for known customer problems, often as Slate dashboards. Meurer describes Slate as a drag-and-drop builder, comparable to Retool, that mapped components on a page to data sources. Once the data was available, the next question was how to make it useful. The engineers who understood that data were well positioned to answer.
In her account, the Slate era gave way to Foundry and a broader focus on moving from data to decision-making. That progression exposed a limitation of dashboards: displaying information does not necessarily complete the customer’s workflow. Meurer’s lesson is that dashboards without writeback to the data source lose usefulness over time. A useful operational application must support acting on the data, not just looking at it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Scale the work by teaching customers
Around 2020, as Palantir approached its IPO, sending engineers to Finland, Canberra, or every other customer location was not a sufficient scaling strategy. Customers needed to do more of the work themselves. Enablement became another part of the role, alongside platform stability, integration, and custom solutions.
Meurer cites Airbus’s Skywise work as enabling thousands of Airbus engineers to perform forward deployed engineering work on Foundry. That is her account of the enablement effort, rather than a measured training result. She then points to AI FDE, introduced after her departure, as using large language models for similar work. AIP boot camps represent the teaching side of the same progression: forward deployed engineers or deployment strategists help customers learn the software. She invokes Alex Karp running a boot camp as an example.
These were overlapping responsibilities, not clean replacement eras. The total set of jobs grew, producing the kind of generalist training that Meurer credits with helping Palantir alumni become founders. For hiring, that suggests a more informative question than whether someone has held the title: which vintage of FDE are they?
| Vintage in Meurer’s account | Responsibility emphasized |
|---|---|
| 2008 | Platform stability |
| 2012 | Data integration |
| 2016 | Custom solutions |
| 2020 | Customer enablement |
Her wine analogy gives the earliest vintage “hints of panic.” The years and boundaries are open to debate; their practical value is distinguishing the work a candidate has actually done. A title alone does not tell you whether someone’s strongest experience is operating installations, modeling data, building applications, or teaching customers.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The common thread is accountability to the customer
By 2026, the label appears across the AI industry. Meurer points to GCP hiring customer engineers or FDEs, OpenAI’s corporate deployment push—represented by the OpenAI Deployment Company announcement—and Aaron Levie’s posts about the importance of this work. But widespread demand does not make the job a single discipline.
Her satirical composite job posting asks for eight years as a staff engineer, six years in direct sales, four years as a solutions architect, and, ideally, prior teaching experience. It captures how hiring can turn accumulated responsibilities into an implausible candidate specification. After roughly two to two-and-a-half years hiring deployed roles herself, Meurer recognizes the pressure to ask one person to cover all of them.
Customer accountability is the continuity beneath the changing job description. An engineer restoring availability, integrating data, building a custom solution, or enabling a customer is responsible for making the software work for someone. That shared responsibility explains the role better than any particular language, framework, or deployment location.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cheaper code brings product and customer work together
What happens to this division of labor when an engineer can prompt a background coding agent and quickly get useful code back? Forward deployed engineers already translate customer signals into product needs: more stability, better integration, or a missing workflow. Coding agents extend their ability to act on those signals. They can move beyond conversations and prototypes to building end-to-end solutions.
Meurer reports a complementary change at Sierra: product engineering is becoming more client-facing. The two roles approach the same relationship from opposite directions. Forward deployed engineers bring customer understanding into the product; product engineers increasingly bring product expertise directly to customers. Good engineers in either role need to think about both together.
The convergence adds responsibilities rather than making operational work disappear. Product engineers—and infrastructure engineers—still need to understand how software gets deployed. At the same time, cheaper code changes the commercial question: what should customers pay for? Meurer turns to work from Emergence Capital and Sierra’s head of go-to-market operations, Elliot Greenwald, whose Outcomemaxxing develops the pricing argument.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Outcome pricing needs both autonomy and attribution
Sierra’s stated pricing principle is that customers should pay a software platform for the value it delivers. Applying that principle depends on whether the product can be credited with the outcome. When attribution is weak, charging for a result is difficult; seat pricing has long provided a way to sell access without claiming responsibility for the final result.
The framework introduces a second dimension: agency or autonomy to achieve the outcome. Attribution asks whether the result can be connected to the product; autonomy asks how much of the work the product can accomplish. Agents can move software upward and rightward on those dimensions, toward doing the work and being accountable for its result.
| Pricing basis | What the customer pays for | Example in the talk |
|---|---|---|
| Seats | Access to software | Traditional software subscriptions |
| Usage | Consumption of a service | Foundation model providers |
| Outcomes | A delivered result | A sale or resolved customer inquiry |
Payments to OpenAI or Anthropic illustrate usage pricing: consumption is measurable even when the downstream outcome is hard to attribute to the model service. In customer experience, completing a sale or resolving an inquiry can provide a more direct outcome. Meurer predicts that most pricing in this market will move toward outcomes; that forecast depends on the product’s ability to achieve and substantiate those results.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Who is responsible for delivering the outcome?
Combine engineers who can contribute directly to the product with a business that charges for results, and the unresolved question becomes concrete: who guarantees the outcome? Meurer identifies that responsibility with forward deployed engineering. The role connects the product’s capabilities to the customer’s actual result.
That changes her original taxonomy. In 2024, agent engineering looked like a distinct, outcome-focused specialization—a flavor of forward deployed engineering. Now she sees product engineering, agent engineering, AI engineering, solutions engineering, and customer engineering converging on the same responsibility. Her qualified claim is that everything is forward deployed engineering, or at least trending that way.
The work still includes enablement, DevOps, solution building, data integration, building agents, and deploying them into production. Each activity contributes to delivering something for a customer, and Meurer argues that pricing should reflect the associated outcomes. The title may lack a coherent technical boundary, but the obligation it expresses remains useful.
That is the force of her closing paradox: “forward-deployed engineering is dead” and “long live forward-deployed engineering.” A narrowly bounded discipline is giving way to a broader expectation that engineers own customer results. Sierra, she adds, is hiring across those forward deployed engineering roles.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Natalie Meurer's original account of agent engineering, including customer integrations, agent supervision, and reusable skills.
Elliot Greenwald explains Sierra's experience with outcome pricing and the importance of autonomy and attribution.
Emergence's framework for choosing seat, usage, hybrid, or outcome pricing according to autonomy and measurable attribution.
Current documentation for the conversational agent that operates Foundry, with capabilities and access requirements.
The May 2026 announcement of an enterprise deployment company using engineers embedded with customers.
Read the complete timestamped transcript
- 0:00
[upbeat music] Thanks, guys, for coming. I know right after lunch, this is like prime time, like sleepiness.
- 0:18
I'm curious just to get a sense for the audience, who here is a forward-deployed engineer? Okay. Who here is hiring forward-deployed engineers? Okay. Helpful. Anyone else in between? You can raise your hand just like if, if I didn't cover it.
- 0:29
Okay. I see you. Double, double hand raise. Um, well, I'm Natalie Meurer. I am the, um, head of agent engineering at Sierra. I've been at the company about two years.
- 0:38
I'll tell you a little bit about that. But honestly, I'm here to talk about forward-deployed engineering. So we're actually gonna spend a little bit less time talking about Sierra and a lot more time talking about the history of forward-deployed engineering and, and the dirty secret, I like to call it, of the domain, and you all can tell
- 0:54
me how controversial it is. So, um, just a little bit about me, which will give you a sense for sort of how I'm coming at this domain, at the whole domain of forward-deployed engineering.
- 1:03
I actually started off as a policy nerd. So I was at Georgetown. Um, I studied, uh, in the School of Foreign Service there, and so I was obsessed with basically tech policy.
- 1:12
I, um, learned to code and then swindled my way or earned my way, uh, depending upon your perspective, into a job at Palantir, where I spent 2016 to 2021.
- 1:22
And, um, there, I worked on the privacy team, and I was, uh, an infrastructure engineer and also a forward-deployed engineer with law enforcement and defense primarily. So I, I've seen forward-deployed engineering up close, and I'm gonna talk a lot about the history of not just my time at Palantir, but actually the time that predated me to talk
- 1:37
about basically the origins of the entire discipline. And then I actually wanted to get a business degree of all things, so I went to Stanford, and now I'm at Sierra from '24 to, to '26.
- 1:49
And one of the things that I think is, is quite interesting and-- When I started at Sierra, actually, a little-known fact is that I joined the deployment team. And at the time, I hated the name.
- 2:00
I, I thought th-this is not what we're doing, A, and B, it, it sort of is a, a nonsensical name, so to speak. And so I actually wrote an ar- an article in, uh, July of 2024, so about six months after I started, um, about two years ago now, on this concept of the agent engineer.
- 2:16
And the idea was that agent engineering was actually a subdiscipline of AI engineering, which we're of course here to talk about. And the vision was that agent engineering had the same level of customer accountability as forward-deployed engineering but was actually a, a domain unto itself.
- 2:31
And I think since then, you know, in the past two years, we've actually seen a lot of folks talking about agent engineering as a discipline, and now we're actually seeing harness engineering as sort of a new discipline, sort of as almost a subset of agent engineering.
- 2:42
And so if you're confused, that's sort of what this talk is about. [chuckles] And so the dirty secret of forward-deployed engineering, I won't make you wait until the end, is it doesn't exist.
- 2:53
It is a term that is, is meant to describe so many things that it sort of means nothing at this point. But nonetheless, it's sort of the hottest job in AI.
- 3:02
And so what I hope to convince you of over the next, let's say, fifteen minutes is A, that this is true, and B, that this doesn't matter. [chuckles] And so, um, I, I'm gonna dive in, and we're gonna start with tracing the history of forward-deployed engineering from Palantir.
- 3:19
So we're gonna start in 2008, and we're gonna basically come back to the present. And then I'll share with you at least my perspective on what forward-deployed engineering is today, why you should want to or not want to be a forward-deployed engineer, and why we're actually all forward-deployed engineers in the end.
- 3:33
Um, so first off, I-I'd actually like to start in 2016, and then we'll go a little back in time. And I actually pulled basically Palantir job postings in 2016.
- 3:42
This is when I started, and what drew me into Palantir was effectively this concept of a forward-deployed software engineer, and this was an emphasis on the forward-deployed part. I mean, they're leading-- These days you lead with, you know, you speak a certain language, you have these skill sets.
- 3:58
They were leading with location. And there's a reason for that that we'll get to, but, but forward-deployed literally meant sitting with customers, being on the ground. And in part, as we'll talk about, this was because so much of Palantir's, um, ecosystem was on-prem deployments.
- 4:14
And so when we think of forward-deployed engineering, though, we kind of think of this. [chuckles] And so, um, this is sort of the prototypical forward-deployed engineer right out of college, um, parachuting out of a helicopter, um, and of course, you know, fixing some sort of runtime issue, um, in the air.
- 4:30
But in practice, forward-deployed engineering actually started as something more akin to DevOps. And so platform stability really constituted the bulk of the job early on. And so when you think about, um, what forward-deployed engineering actually was, don't worry about understanding this code on the right, but it just gives you a sense for what, what folks were actually
- 4:50
doing. In fact, my onboarding project at Palantir was actually deploy the software on an EC2 instance. [chuckles] And so that was literally the job, and it, it was a, a large part of the job, and so much so that, um, basically the job felt like this, which is basically an email from the customer telling you that someone mistakenly
- 5:10
unplugged, um, the instance again. "Hey, could you look into it? By the way, it's two AM, and you need to go in." Um, and so in practice, a lot of the early forward-deployed engineering was, was really focused on DevOps.
- 5:25
And come 2012, the, the Palantir platform got a lot more stable, and Palantir built data integration software. So quick show of hands, everyone here probably knows, but who here knows what data integration software is?
- 5:38
Great. Anyone think data integration software is really useful without data?
- 5:42
Yeah. Okay. O-okay, one per- All r- all right. I, I'm curious to hear your take after. Um, so, um, so I like to think of data integration software without integrated data as a movie theater that's playing nothing.
- 5:54
It's like, why show up, you know? And so this is basically what Palantir was selling without forward-deployed engineers. A, the movie theater wasn't standing in 2008. By 2012, you actually don't have data in it, right?
- 6:06
You don't have movies playing.
- 6:08
And so you sort of have this basic, um, you know, comic explaining this, this process, which is, "Hey, great, we have this data integration software. Isn't it useful?" Right, but my data's in 20 places, and now you actually have a forward-deployed engineer that needs to go in and integrate that data.
- 6:24
And most of this was written in, you know, variants of Java back in the day, um, as was actually Palantir's client, fun fact, and Java Swing, if anyone here has had the privilege to, to use that.
- 6:34
Um, so, so basically, forward-deployed engineers now had this dual role, right? DevOps plus data integration. And so they wanted to, to deeply understand the customer's environment to, to model that data appropriately, and what Palantir, uh, did then and now still does call an ontology, which is sort of a famous Palantir, um, term of art.
- 6:56
But you can think of it as a taxonomy for that data.
- 6:59
And then 2016 rolled around, and you have custom solutions. So folks are building effectively solutions to known problems. Um, and usually that took the form of a Slate dashboard.
- 7:11
Has anyone here heard of Slate? This was sort of an internal... Okay. All right. Um, so Slate was basically, um, a drag-and-drop builder. It actually still exists as part of Palantir's platform.
- 7:21
It allowed you to map, similar to V tool actually, um, map components on the page to data sources. So now you have the data, and then the question became, okay, how do we make it useful?
- 7:31
And the, the person or the individual or the group that was most well-situated to make that data useful was the, the individuals that most understood that data, which were the forward-deployed engineers.
- 7:41
And so, um, the, this basically era of, of Slate actually gave way to an era of Foundry, which is Palantir's main platform today. And the era of Foundry was effectively all about, um, making data useful.
- 7:55
So Palantir had this phrase of, uh, going from data to decision-making, which was, was sort of the core problem. And one of the things they found, a spoiler alert for anyone building a dashboarding platform, is that a dashboard that doesn't write back to the data source isn't that useful, that these things would decay over time and actually
- 8:11
not be as useful as they could be.
- 8:13
Fast-forward to 2020, you know, Palantir is on the verge of IPO, and they also need a solution that doesn't involve shipping people out to Finland or Canberra or choose the kind of location on the earlier slide of your preference, and, um, they actually wanted to empower customers to do more of this work themselves.
- 8:33
And so this is where Palantir really started to become a platform, and the job of forward-deployed engineering still involved the first three, but it also involved enablement of those customers.
- 8:41
So if you look at the work that Palantir's done with Airbus, for example, in Skywise, that was focused on enabling thousands of Airbus engineers on the Foundry platform to do work of the forward-deployed engineer.
- 8:52
And these days, they actually have a platform, uh, since I left, called AI FDE that's focused on leveraging, uh, large language models to do similar work. So this is the timeline, and you'll see that it's not one thing.
- 9:04
And so this is a, a picture of, uh, Alex Karp, and I think we might have lost the photo, um, over, over here, but of Alex Karp basically running an AIP boot camp.
- 9:15
So this is basically where the forward-deployed engineers or the deployment strategists would go in and actually teach customers to use the software. So what's interesting about this is these weren't discrete eras, right?
- 9:28
The total FDE jobs to be done actually increased over time. Maybe they peaked at one point, but they actually grew over time. And so now we have a world, come 2020, 2024, where, um, the role of FDE sort of doesn't mean anything quite yet, or it means everything, right?
- 9:46
It's actually the best training ground for generalists, and in fact, this is why I would say that Palantir has seen such suc- success of Palantir alums founding companies is because it's actually training you on all of these different facets of the role.
- 9:59
And so I have an idea that I like to think of, um, that you all can ask your next candidate if you're interviewing for, uh, a forward-deployed engineering role, um, which is what vintage of FDE are you?
- 10:10
Are you the 2008 vintage of, um, platform stability with hints of panic? Um, 2012, 2016, um, 2020, or even, you know, today? What is, what is the forward-deployed engineer of today?
- 10:24
And so the-- I like to call this the FDE vintage, and, um, you might debate the years and debate the details, but, um, just like fine wine, I think there's a, a particular vintage of an FDE.
- 10:35
So welcome to 2026. Here we are, and FDE is absolutely everywhere. So I'm, I'm sure you all have heard, Google recently announced, um, with GCP an effort to, um, hire customer engineers or FDEs.
- 10:49
OpenAI created a new unit, um, with a massive investment to aid the corporate AI push. You have folks like Aaron Levie, um, basically posting on X as, as well as many others about just how important this work is today.
- 11:02
But if you think as-- about what we just saw, the work isn't one thing, right? So forward-deployed engineering is actually many things all at once. And in fact, today, if you look at basically what it takes to be a forward-deployed engineer, if you were to combine all the job postings into one, you'd probably see something like this. [chuckles]
- 11:19
You know, I'm-- I don't know how many of you have been a staff eng for eight years, um, with six years of direct sales experience and four years as a solution architect.
- 11:27
Um, also, I, I don't know if you've taught in schools prior, 'cause that would help as well. Um, and this is actually what it feels like hiring for these deployed roles as I've done for the past, you know, two years, two and a half years or so.
- 11:39
Um, but this is actually what's being asked of forward-deployed engineers today. And so you think about the, the dirty secret that it doesn't exist, and actually it, it either doesn't exist or maybe it actually exists too much.
- 11:52
Hard to say. Um, and part of this, I think, and part of sort of, um, I think the importance of the role is that across all of those different aspects of the role, the one continuity point is that you actually have every single forward-deployed engineer accountable to the customer, whether that be for DevOps, for enablement, whether that
- 12:14
be for custom solutioning, data integration. These are all forms of solutions or customer accountability.
- 12:21
And when that happens, though, I, I ask the question, you know, what happens to engineering broadly, even outside of forward-deployed engineering, when code becomes cheap to produce, when it becomes really quick to fire off a prompt to a background agent and get something pretty great on the other end?
- 12:38
And one way to think about this is forward-deployed engineers being accountable to customers and trying to translate that signal into the product, either to make it more stable or to drive more data integration.
- 12:50
And so what this allows you to do as a forward-deployed engineer today is actually be way more impactful in product development. So forward-deployed engineers can now not just talk to customers, not just prototype, but actually build end-to-end solutions with coding agents.
- 13:06
But I think something more interesting is happening that we're seeing at Sierra, which is actually the lines are blurring. So product engineering is also becoming more client-facing. And so if you're a good product engineer, if you're a good forward-deployed engineer, you should be thinking about the product and the customer both together.
- 13:24
And so one of the reasons that folks are talking about forward-deployed engineering as so essential to where we are at this point in time is that it's actually converging.
- 13:33
Forward-deployed engineering is in some ways actually getting larger than we ever thought it was before, so it's actually stacking more skills on top. And if you're a product engineer, even an infra engineer, you should also be thinking about DevOps, right?
- 13:44
How do you actually deploy the software? And then separately, a different shift is changing when code becomes cheap, and this is actually from, um, both Emergence Capital and then, uh, a blog post from someone on, on our team, our head of go-to-market ops, Elliot Greenwald.
- 14:00
And the way that we sell software is changing. And at Sierra, we have always been focused on this outcome-based pricing model. We think that you should pay a software platform for the value that that software delivers.
- 14:14
And this is not always possible. So if you think about, uh, scenarios where basically you can only slightly attribute the outcome to the product, think of seat-based pricing. This is basically the way that software has been priced for, uh, an incredibly long time.
- 14:29
And then you think about the agency and the autonomy to, to achieve the outcome. And agents basically move us up and to the right here. So usage-based, a good example of that might actually be what we pay to OpenAI or Anthropic or some of the foundation model providers
- 14:42
because it's, it's based on usage and it's hard to actually attribute the outcome. When you think about customer experience in AI, that's outcome-based. It's are you actually making a sale?
- 14:52
Are you solving a customer's inquiry? And we think basically that most of pricing in this market will move to outcome-based.
- 15:00
So if you have both of these things, you have forward-deployed engineers that can now contribute to the product, you have more outcome-based pricing, how do you actually guarantee the outcome?
- 15:09
And that really is forward-deployed engineering. And so if I jump here, uh, back to sort of where I started, this is how I envisioned agent engineering in, in twenty twenty-four.
- 15:20
And I, I don't know if I was wrong, or you guys can tell me if I was wrong, but it wasn't the whole story, right? That agent engineering actually was a subset heavily focused on outcomes.
- 15:30
It is a flavor of forward-deployed engineering. But these days, I'm actually of a different mind, which is that, um, really in some ways everything is forward-deployed engineering, or at least everything is trending that way.
- 15:43
Product engineering, agent engineering, AI engineering, solutions engineering, and customer engineering. When you think about enablement, you think about DevOps, you think about solution building, data integration, building an agent, deploying it into production.
- 15:56
These are things that are on behalf of customers at the end of the day, and we should be pricing outcomes associated with them. And forward-deployed engineering as a concept, even if it is one, sort of lacks a coherent definition, is something that actually allows us to enable those outcomes.
- 16:11
So I'll leave you with, um, maybe one last note, which is that forward-deployed engineering is dead [chuckles] and long live forward-deployed engineering. So thanks so much. And by the way, we're hiring across forward-deployed engineering roles, uh, at Sierra.
- 16:24
So I told you it wouldn't be about Sierra, but if you wanna talk about FDE, I'm here. Thanks, guys. [audience applauding] [upbeat music]