Every AI company we talk to is asking the same question: Should we hire Forward Deployed Engineers?
The honest answer, more often than not, is no. Not yet, and possibly not in the way you think.
OpenAI recently launched an entire deployment company. Anthropic is scaling its services arm. Startups are spinning up "FDE" titles before they've worked out what the role actually does. And in nearly every talent conversation, the same question surfaces: everyone wants someone who sits between product and customer, who can build, sell, and iterate in the field, but nobody can quite articulate what makes that different from a good solutions engineer or an expensive technical consultant.
We recently brought together portfolio founders, CTOs, and operators alongside Anjor Kanekar, a former Palantir FDE of seven years and now an advisor helping companies design FDE organizations, for a working session on this problem. What follows is our synthesized perspective.
A Role Defined by Refusing Definition
The first thing to understand is that the FDE role is deliberately undefined. That's both its power and its confusion.
Anjor's own career illustrates the point. Over seven years his work shifted from DevOps-style deployment stabilization, to building applications alongside a large enterprise customer, to leading a team of 35, to writing backend code as an IC, to product oversight across government engagements. His title throughout? Always Forward Deployed Engineer.
That's not organizational sloppiness. That’s the point. The role is a container for whatever the company needs at the boundary between its product and its customers. That shape changes as the product matures, the market evolves, and the individual develops. Companies that try to pin FDEs to a fixed job description are already misunderstanding the function.
What does stay constant is the feedback loop. An FDE builds bespoke solutions for specific customers, but the real deliverable isn't the customer-facing output. It's the product signal that comes back: the gaps exposed, the workarounds invented, the patterns that reveal what should become platform. Anjor captures this well in a recent essay imagining what would happen if LEGO had Forward Deployed Engineers: the FDE's job is to deliver a dragon to the customer, but bring back the weird bricks they had to invent to build it. If no one is walking back to product with those bricks, you don't have an FDE org. You have a services team.
When You Actually Need FDEs
Anjor offered a framework in our session that cuts through a lot of noise: think about the phrase "product-market fit." If you're still figuring out either side, the product or the market, you probably need FDEs. If both are established, you probably don't.
Finding product. Your core offering exists but requires significant customization per customer. FDEs fill gaps, build bespoke solutions, and bring validated signals back to core teams. In the earliest version, the FDE essentially is the product: sitting with customers, building in the field, shaping the roadmap in real time. One founder in our session described exactly this: a platform open enough that customers need someone from the team to configure and prompt-engineer use cases on top of it. That's textbook FDE territory.
Finding market. You have a working product and want to expand within existing accounts. An FDE working with a bank on anti-money laundering might, by being on-site and earning trust, identify an opportunity in adjacent workflows. FDEs are the land-and-expand mechanism.
The contrarian take: Once your product works out of the box and the market is buying, split the role into traditional solutions engineers and solutions architects. Holding onto the FDE model past this point is how companies accidentally build consulting firms. If the gap between what product ships and what customers need isn't shrinking, more FDEs won't fix it. Something else is wrong.
Misaligned Incentives, by Design
The hardest part of running an FDE org is that the incentives between FDEs and product teams are deliberately in tension. FDEs optimize for winning their customers. Product teams optimize for building something general. Those orientations pull against each other, and that discomfort is where good product comes from.
This has direct implications for measurement. FDE performance should never be tied to engagement-level revenue. The moment you do that, FDEs stop being product scouts and become account managers. They optimize for extracting more from each deal instead of identifying what should become platform.
A principle Anjor advocates, and one we think more companies should adopt, is that FDEs shouldn't even know the contract value of their engagement. Their role is product signal, not revenue extraction. The metric that matters is revenue per forward-deployed person at the company-wide level: a measure of product leverage, not individual billing. The second metric to track is FDEs per client. In the early days, you might need three to five people on a single use case. As the product matures, that should drop to one person handling multiple accounts. If those two numbers aren't moving in the right direction (revenue per FDE up, headcount per client down) your product isn't absorbing lessons from the field.
Compensation follows from this. Avoid commission or revenue-share structures for FDEs. Tie rewards to product signal generated, milestones achieved, and internal contributions. Performance reviews should be holistic and bespoke. This is not a role where a standard engineering ladder applies.
Hiring: Assessing for Ambiguity, Not Algorithms
Traditional technical interviews are increasingly unreliable for FDE hiring. AI tools have made coding assessments less meaningful, and the role demands skills that standard loops don't test.
What matters is critical thinking under ambiguity, specifically the ability to use AI tools well while maintaining judgment about when the output is wrong. As one founder in our session put it: you can't be lazy, but you have to be smart enough to use the tools.
Three approaches that surfaced:
Realistic scenario-based interviews. Design a role-play that mirrors actual FDE work. Anjor described one he built for a client: the interviewer shows up as a panicked customer. "I have a meeting in two hours, the dashboard is showing wrong numbers, help me debug it." The candidate triages, communicates, and problem-solves live.
Work trials. For early-stage companies, nothing reveals FDE capability like a few days of actual work.
Assess AI-augmented judgment. The best FDEs in 2026 aren't the best coders. They're the best at choosing which tool to use, prompting effectively, and knowing when to reject the output.
One structural point worth highlighting: if you're hiring both FDEs and core engineers, consider having a shared hiring bar across both functions. A single hiring manager or a consistent assessment framework across the two ensures the technical standard stays high and lets people move fluidly between field and product roles as the company evolves.
Pricing, IP, and Org Structure
The business model evolves predictably. Early on, you're selling services: FDE time is the product. As the platform matures, you shift to license fees with subsidized implementation. At scale, it's pure SaaS with premium services rates.
IP ownership is the perennial headache. The clearest framework: the tooling and infrastructure that enable FDE work is your IP. Custom applications built on top for a specific customer are theirs. The abstract class is yours; the instantiation is theirs. The gray area requires case-by-case contract negotiation. Get this wrong early and you set painful precedents.
Organizationally, FDEs should sit in a customer-facing org, separate from core product engineering. This separation preserves the productive tension between field-driven priorities and platform thinking. Collapse it and you lose the feedback loop that makes the function valuable.
The Strategic Fork: Product Company or AI-Powered Services Firm?
The most provocative thread from our session was about what happens to the FDE model as AI tools keep getting more powerful.
One founder described the new economics: a single person using their platform can replicate functionality that previously cost a customer tens of thousands in annual software fees, in half a day. If the unit economics of bespoke delivery just dropped by an order of magnitude, do you even need to productize? Or is the right move to keep delivering custom solutions forever, pricing on outcomes rather than licenses?
It's a real fork. Some companies are leaning into it, building internal tooling that makes their people dramatically more efficient, then capturing services revenue at software margins. Others are using FDEs in the traditional mold, as a product discovery function that eventually gets absorbed into the core.
The right answer depends on your market, your ambition, and how much of what you're building can genuinely be generalized. What matters is that the choice is conscious. The worst outcome is drifting into services without realizing it. Waking up to find that your FDEs are billing hours, your roadmap is a collection of client requests, and you've built a consultancy at a SaaS valuation.
The Test
Most companies hiring FDEs today don't actually need them. For those that do, the function is one of the most powerful organizational tools available: a way to learn from customers at the speed of deployment, while building product that compounds.
Two numbers tell you whether you're on the right track: revenue per FDE going up, headcount per client going down. If both are moving, you're building a product-led company that uses deployment as an accelerant. If they're flat or going the wrong way, you're building a services-led business, which can be valuable but demands a fundamentally different playbook on hiring, pricing, and margins.
A well-run FDE function offers something that a deployment team at a large AI lab almost certainly can't: founder-like ownership over an entire engagement, real product influence, and the kind of structured ambiguity that turns good engineers into future founders. For the companies that get this right, that's both the recruiting pitch and the competitive advantage.
This piece draws on a Northzone working session with portfolio founders and operators, and on Anjor Kanekar's essay "If LEGO Had Forward Deployed Engineers."
