Define First to Deploy Fast
The numbers are mind-boggling to me. Job postings for Forward Deployed Engineer roles increased more than 800% between January and September 2025, according to the Financial Times. Salesforce committed to building a team of 1,000 FDEs. The framing from a16z lands because it’s true: “Enterprises buying AI are like your grandma getting an iPhone: they want to use it, but they need you to set it up.”
Aaron Levie, CEO of Box, named the structural reason why: “When a vendor sells any kind of agents into an organization, you’re no longer just selling a software tool that gets implemented and you’re done. You’re fundamentally selling some form of the actual workflow being done by your technology. This is far closer to a customer buying from a professional services firm than implementing traditional technology.” The corollary is the question this post is asking: if you’re selling a workflow, who owns whether that workflow actually delivers?
So, companies send engineers to set it up. The FDE solves a significant blocker for highly complex software. But unless all your FDEs are unicorns, they need someone to define the business outcomes, maintain alignment and executive communication, and deliver actual outcomes to maintain momentum. Most companies are hiring the engineer without hiring that person. That’s the gap this post is about.1
The Failure Mode That Predates FDEs
This pattern isn’t new. Before FDEs, it played out with Professional Services and Sales Engineer teams. A deal needed to close. Sales discovery was cut short. The conversation in the room was essentially: “That deal will get us over the bookings target. Go faster.” The PS or SE team got handed a contract where the definition of value was implicit, assumed, or never discussed. Having that conversation would have slowed down a deal that needed to land.
Across my career, the large accounts that failed to successfully adopt came down to three things, almost every time. First, we overpromised. Second, we sold to a customer who wasn’t a good fit. Lincoln Murphy at Sixteen Ventures has written well on this: bad-fit customers are expensive in ways that don’t show up on the invoice. Or, third, we didn’t properly identify the business outcome and the roadmap to get there before we started building.
Job titles changed. The patterns have not. The failure pattern persists not because the people are different but because the incentives aren’t. Deals still close faster when success criteria stay vague. Deployment still starts before the outcome is defined. The same pressure that pushed PS teams past the point of readiness now pushes FDE teams past the same point.
There is a structural fix that most companies ignore: align the salesperson’s compensation to the customer’s actual consumption and outcomes, not just the closed deal. When a sales rep documents the success criteria clearly during the sales cycle, the deployment moves faster, the FDE builds against a defined target, and the customer sees value sooner. When that same rep’s variable pay is tied to whether the customer actually hits those outcomes, their incentive to move fast and skip steps disappears. The handoff from sales to FDE becomes a baton pass instead of a messy toss over the wall. This is one of the highest-leverage things a company can do to make the FDE motion work. How many of us are talking about it?
There is an uncomfortable truth underneath the 800% job posting surge. Barry McCardel, an ex-Palantir engineer who helped build the FDE culture from the inside, has written that many companies calling their field teams FDEs are doing “sparkling Sales Engineering.” David Sakamoto, former SVP of Customer Success at GitLab, has made the same observation: many FDE hires are Professional Services with a new title. The title is not the motion. Copying the role without the hiring bar, the ICP discipline, and the financial accountability that makes the model work doesn’t change the outcome. It adds headcount to a motion that still isn’t defined.
The failure mode is the same and the stakes are higher. Enterprise AI deployments are expensive (and have tons of expectations on them). FDEs are expensive. When the account turns, the cause will be murky because the outcome was never defined clearly enough to measure whether it was achieved. That’s not a new problem, but an old problem running at new cost.
The Role Design Challenge
The FDE is built to build. Their incentive is deployment velocity, technical elegance, and field-to-product feedback. These are genuinely valuable. However, they can, just like other roles before them, become decoupled from having a rigorous definition of the customer’s business outcome before the first commit. On top of that, they must be excellent communicators, align with executives, operators, and software engineers.
The FDE will ask what the customer needs. They’ll get an answer shaped by the systems, workflows, workarounds, and constraints the customer is already operating inside — not by what great actually looks like. That answer risks producing a marginal improvement, not a zero-to-one gain. The customer describes the world as it is. The question of whether that excellent thing maps to what the customer’s leadership actually cares about: that’s a different conversation, and it rarely happens without someone whose job it is to make sure it does. Yes, there are exceptional people who do both. They are exactly that: exceptions.2
Carlos Granda, who has led customer success at Google Cloud, Salesforce, and SAP, put the broader challenge well: the FDE debate is asking the wrong question. The real question isn’t “FDE or CSM?” It’s “what does your customer actually need to succeed?” He’s right. And the answer to that question has to be spelled out first.
Granda also names the critical distinction: “Are you treating FDEs as an engineering motion, building durable, supportable solutions that scale across customers, or as a services motion, solving one-off problems that disappear the moment your engineer leaves? If every deployment is bespoke, you don’t have an FDE strategy. You have an expensive consulting practice.”
The corollary: if you don’t know what a successful deployment looks like in business terms before the FDE starts, you have a talented, expensive engineer building with their arm tied behind their back. The account will look fine until it doesn’t. And when it turns, the cause will be murky because the outcome was never defined clearly enough for anyone to measure whether it was achieved. We can overwhelmingly successfully deploy but miss the opportunity for high consumption.
The Strategist Comes First
Palantir figured this out years ago. They call them Deployment Strategists: specialists who sit alongside the FDE from the start, bridging technology and operational priorities so the technical work addresses the right problems and gains adoption across stakeholders. Salesforce has built the same function into their FDE model under the title Forward Deployed Engineer, Deployment Strategist. Flank, a legal-tech company, calls the role a Forward Deployed Strategist outright. The names differ. The function is the same: couple the FDE’s technical motion with strategic planning so that technical outcomes are designed with the business destination already mapped. Salesforce staffs one Deployment Strategist for every two FDEs — a ratio worth taking seriously, though it depends on your context. A high-complexity enterprise account with contested internal politics and an aggressive timeline probably warrants closer coverage than a well-scoped mid-market deployment. The ratio is a starting point. The account defines the answer.
The FD Strategist engages with the FDE. Their work is the foundation the FDE builds on.
At GitLab, I was running a version of this segmentation model: enterprise accounts got a more intensive engagement layer, mid-market got a scaled version, SMB got digital motion. Same logic, different ARR thresholds. What’s changed is the assumption underneath it. Traditional SaaS software delivered value out of the box for most customers: install, configure, use. AI platforms, data infrastructure, and agentic systems generally don’t. They often require embedded engineering to prove value, then produce value in the customer’s specific environment. That changes when you engage, what you do, and who the team needs to be. The FD Strategist is essential now in a way that was optional then.
The distinction between an FD Strategist and a CSM is not about scope of care. Instead, it’s about scope of accountability. A CSM runs a program: ongoing, relationship-driven, measured across the life of the account. An FDE and FD Strategist run a project: time-bound, outcome-defined, and accountable for whether the deployment delivers what was promised before the first line of code is written.
Three responsibilities define the FD Strategist:
Own the Outcome Charter before the first build begins. Define the business outcome, the timeline, and the measurable success criteria in terms the exec sponsor’s leadership will recognize. This includes use cases. Everything the FDE builds traces back to this document. Without it, deployment success and the customer’s success are not the same thing.
Maintain executive alignment and operator engagement throughout. Not just at kickoff and the quarterly business review. Many companies schedule executive involvement at kickoff and at the QBR — and what happens in between is a gap. That’s not alignment; that’s calendar management. The FD Strategist is in continuous communication with the exec sponsor: surfacing progress, flagging drift, keeping the internal narrative current. When the champion changes, the FD Strategist owns the transition. This is the function that keeps a technically healthy deployment from quietly becoming one where consumption plateaus instead of skyrockets. This division of focus — strategist on executives, FDE on operators and engineers — is what makes the pairing work.
Drive and communicate value realization. The FDE ships. The FD Strategist translates what shipped into terms the executive sponsor and their leadership can absorb and use, and watches whether the behavioral change that constitutes real adoption is actually happening. Not just whether the product is running: whether it’s changing how work gets done and whether the customer can see and articulate that change. This is the function that surfaces the gap between deployment completion and value delivered — before it shows up in consumption data.3
Four questions drive the Outcome Charter work before the FDE engages:
- What business outcome is this customer’s leadership accountable for, and how does this deployment accelerate it?
- What does the exec sponsor need to demonstrate, to whom, and by when, for this to be considered a success internally?
- What behavioral change in end users constitutes trust? Not access, but usage that changes how work gets done?
- What is in scope for this engagement, and who has explicitly agreed to hold that boundary?
And then there’s a second layer that doesn’t appear in any job description but matters just as much for the persons we work with:
- What has the exec sponsor already promised internally, to whom and by when, and what does it mean for them personally if this delivers or doesn’t?
- Who inside the customer organization will resist this, and what is their actual objection?
- What story does the exec sponsor need to be able to tell their leadership in 90 days, and are we building toward that story?
Without both sets of answers, the FDE has a deployment. With them, the FDE has a definition of done and relational trust, and the organization has a customer who can articulate what they got.
I’ve written separately about a five-part framework for this kind of outcome-first work: Outcome Charter, Current State Map, Ontology Mapping, and Outcome-to-Constraint Mapping. That post goes deeper on how to operationalize it. The short version: the Outcome Charter is what the FD Strategist produces. Everything the FDE builds should trace back to it. Read that post here.
Two Questions Before You Build an FDE Team
Granda’s diagnostic questions are the right starting point. Does your product require embedded engineering to deliver value, or does it deliver value out of the box? Where do your revenue growth priorities sit across segments? Does the resource-intensive FDE model accelerate or break your model?
But there are two prior questions worth asking before either of his.
The first: Who owns the definition of “done” before the FDE starts building? If the answer is “whoever’s available” or “we’ll figure it out in implementation,” you’re not ready to hire FDEs. You’ll build impressive things. You’ll hit deployment metrics. And you’ll wonder why consumption and revenue growth don’t follow.4
The second: After the code is running and the FDE has moved on, who holds the customer accountable to the defined outcome? The FDE engagement ends. The customer’s business doesn’t. If nobody owns the bridge between what was built and whether the customer’s numbers actually move, you’ve traded deployment velocity for stalled consumption. That gap is where good deployments quietly become ones where consumption plateaus instead of skyrockets. The strategist feeds that learning back into how your company sells, positions, and builds next. The engineer ensures the technical feedback loop to Product. Both functions matter. Neither is optional.
The segmentation model works: enterprise gets FDE plus FD Strategist plus CSM, mid-market gets technical CSM, SMB gets digital with expert-on-demand. The model itself isn’t new. What’s new is the cost of skipping it. Traditional SaaS software delivered baseline value out of the box. AI platforms, agentic systems, and data infrastructure generally don’t. They require embedded engineering to prove value at all, inside the customer’s specific environment. That changes when you engage, what the team needs to look like, and what happens when you cut corners on the outcome side. Skipping the strategist doesn’t save money. It delays the point at which you discover the gap and makes it more expensive to close.
You don’t have a deployment problem. You have a definition problem. Few FDEs can solve it all. Consistently defining the outcomes to execute will. But only if that person is in the room before the first commit, not after the first miss.
1 I realize many FDEs are hired because they are exactly that: unicorns who are fantastically technical, with communication abilities well above par, and are laser-focused on delivering rich business outcomes. However, with the need to hire thousands upon thousands and the rapid growth and acceleration of the FDE, I don’t think all companies can achieve this. Also, John at Success Venture Partners has a good point on different companies either focusing on the engineer or the deployment part of FDE.
2 There’s a reasonable counter-argument here: that the FDE, given sufficient access and the right disposition, can own both the discovery work and the technical build. Tanay Padhi, in a conversation with Milos Mandic (FDE — Process Debt: A Conversation with Tanay Padhi), argues exactly this: the FDE who asks the right questions is the FDE worth hiring, and the discovery work is inseparable from the role. He’s right about the individual. The problem is scale. One exceptional FDE can carry both functions. A team of fifty cannot do so consistently without a structural owner for the outcome side. That’s when the separation becomes necessary, not as a luxury, but as a quality control mechanism.
3 The FD Strategist role carries additional responsibilities beyond these three that matter at scale: defining and enforcing scope boundaries to prevent bespoke consulting drift; managing the handoff to the sustain layer when the FDE engagement ends; and owning the structured feedback loop from the field back into product and GTM. These are real and important. The three responsibilities above are where the role earns its existence before any of the others become relevant.
4 A note for earlier-stage companies: at a small FDE team, one person often carries both the strategist and engineering functions. That can work. The question is whether that person is actually asking both sets of questions, or whether the Outcome Charter work is the first thing to get compressed when the deployment gets complex. It compresses. That’s how the old failure mode re-enters through a new door, even when the person carrying both roles is genuinely talented.
Jeff Beaumont 