Few people have lived the forward-deployed engineering model as deeply as Anjor Kanekar. A physicist by training, he spent the better part of a decade as a forward-deployed engineer at Palantir, the company that invented the role, and his writing on it has become a reference for teams trying to build the same motion. He now advises founders on standing up FDE functions and is putting the model to work through his own venture. We sat down to map the territory: what an FDE actually is, how the operating model shifts from company to company, and how to hire for it.
Ask ten companies what a forward-deployed engineer does and you'll get ten answers. Anjor thinks that's by design, not by accident, and that almost all of the confusion dissolves the moment you stop arguing about titles and ask one thing instead: how far are you from product-market fit?
The conversation below is lightly edited for length and clarity.
There's a lot of confusion in the market right now about what an FDE even is. Why do you think that is?
The role was designed without clear definitions or boundaries, very deliberately, and that's the value of it. If you hire high-agency, high-autonomy people who are outcome-driven and think critically about where the value is, you don't want to confine them with a definition. That's how Palantir approached it. From 2015 onward the role kept changing, but people could just adapt and start doing different things; they never had to go through the theatre of "oh, what is my role now?" Your title is always FDE.
The flip side is that the "forward-deployed" part gets all the attention, so people assume FDEs are just consultants. Sometimes, for a stretch, they are, but only as a means to an end. That client work is how you get signal on the core product you should be building.
On your website you split FDEs into two archetypes: product-facing and business-facing. Can you unpack those?
Those are the two big buckets I noticed about halfway through my time at Palantir. It's not a comprehensive framework. I suspect there are others. A lot depends on what your company does. If it's a standard SaaS model where someone can put in a credit card and get your software, you don't need the business-facing FDE at all.
The product-facing FDE does client-facing work to understand what core offering you should be building. The business-facing FDE is diagnosing the client, understanding their org structure and business context really well, to find opportunities where you can add value, and then actually going and unblocking access to those things, not just identifying them.
How much variance is there between one company's FDE function and another's?
Quite a bit. At one end the FDE is basically a founding engineer: it's so early there's no product, and they're just figuring out how to make their own next deployment easier. That's even before "what do I build for the customer"; it's "what do I need to build for myself." At the other end you have very successful services firms in the Palantir ecosystem, like Northslope or Foxtrot, building on top of Foundry. They get huge leverage from the platform, so the profile they need is completely different. And some companies hire both forward-deployed engineers and deployment strategists but call them all FDEs, which only adds to the confusion.
If you had to distill it to a single variable, what would it be?
How far are you from product-market fit. That's the variable. You can be far for one of two reasons: there are product gaps, or you haven't identified your market, and that maps onto the two archetypes. There's a rough correlation with company size, but it's not clean. The reason Palantir sustained the motion for so long is that the ambition is enormous: they want to be the operating system for the world's largest enterprises. So even when parts of the platform had product-market fit, there was always more to figure out. Smaller companies may need FDEs too. They just might not call them that. At an early-stage startup, everyone should be talking to users.
“How far are you from product-market fit? That's the variable.”
Anjor Kanekar
Has AI changed the operating model over the last six to twelve months? You've written about an "AI wrinkle."
In a pre-AI world, doing FDE work pushed you toward a SaaS offering, because that's where the margins were, unless you deliberately wanted to build a services business, which is also fine. What's changed is that one person can now do five or ten people's jobs. A thing that would have taken ten consultants can be done with one.
For the product-facing FDE, that shifts what counts as "the product." The job becomes building tools to make yourself more efficient, rather than perfecting the UX for an end user. It's just a CLI, it's never going to be rendered beautifully, you have to look at the JSON, and that's fine if it's an internal tool. The signal you bring back is slightly different. On the business-facing side I haven't thought about it as much, honestly. That's not who I am; I'm a product-facing FDE.
One of your essays argues for one client per FDE. Do you still hold to that?
I'm not super tied to it. It comes back to how far you are from PMF. The superpower startups have is focus, and a deployment-strategist-plus-FDE pairing is basically a self-contained CEO/CTO pair running a self-contained startup, so when you're far from PMF, one customer is just easier. As you get more product leverage, one FDE can handle several, as long as there's a common thread: for a product-facing FDE it might be a part of the stack that's relevant to three customers; for a business-facing one it's usually a shared domain or use case.
We've felt the pressure to put fewer people on each project because of agentic coding tools, but then you risk a bus factor of one. How do you think about that?
I've seen a version of this in the Palantir ecosystem for years, just from Foundry. It's not even an AI thing; it's simply very easy to do a lot with Foundry. Fundamentally, the point of this motion is to do R&D, either on the product side or the market side. It is not to service the clients. So find the bus factor where you can still do that R&D. If you're just doing services, underwater juggling multiple clients, you don't have the space to actually be a valuable FDE.
You describe the ideal FDE as high-agency and high-autonomy. Should that be the main hiring criterion, above technical and product skills?
It depends what you mean by technical and product skills. Ability to learn should be highly valued. Maybe because I didn't study computer science, I never placed much value on whether someone knows some particular bit of Python syntax. When I assess technical talent, I'm looking at problem-solving: are you latching onto the right abstractions, are you thinking about the system properly?
Above all I look for value orientation: the drive to get to value. Sometimes that means getting very tactical (sitting outside the CISO's office until they come out, just to unblock data access) and sometimes it means zooming out and asking what we're actually trying to build. I genuinely enjoy interviewing, which is a strange thing for a software engineer to say. But I'm a physicist by training: a person is a complex system, a company is a complex system, and you're trying to understand why this one might thrive inside the other.
What about after you hire? At Palantir there were thousands of FDEs to learn from. How does a startup with one or two preserve the craft?
Honestly, this has been on my mind and I don't have a good answer for you. The cop-out is that you hire a couple of cultural anchors and it spreads by diffusion, but that's not a real answer, I'm evading the question. In the very early days the culture and the approach to problems come from the founders. How you systematise it after that, I haven't cracked.
Can you give one example of something a great FDE did that impressed you?
I wrote something I called the FDE manifesto. It was the onboarding document I'd share with the FDEs reporting to me. The expectations are deliberately unglamorous: get into the weeds, actually understand the product, go through the painful process of reading the logs and debugging, root-cause everything, build your network. A lot of it I learned from watching Chris Stokes, a legendary Palantir FDE. I never actually worked with him, but I learned a huge amount just watching him operate.
Last one. For a founder setting up an FDE or product-strategy function, what's the one thing to pay attention to?
Keep asking yourself: do you need FDEs, and if so, why? That matters more than anything else, and be honest with yourself. It's perfectly fine to call your solutions engineers FDEs because it helps you attract talent. But be honest about whether they're actually doing R&D, or whether they're just last-mile delivery and you have a service business. There's absolutely nothing wrong with that. Just be honest.
To read more about Anjor visit https://anjor.xyz/ and https://platypustech.xyz/.
And if you wanted to read more interviews like this with FDE practitioners subscribe to this newsletter!