Why Do You Think You Need FDEs? A Conversation with Anjor Kanekar
FDE Operating Model Consultant
Anjor Kanekar spent seven years at Palantir, mostly as a Forward Deployed Engineer, with stints as an Infrastructure Quality Engineer and Software Engineer. He worked on major commercial accounts including Airbus. Since leaving, he's been advising early-stage companies on how to build FDE organisations: the hiring, the structure, the interfaces with product and sales. We talked about what companies get wrong when they try to copy Palantir, why one FDE per ten customers doesn't work, and what he looks for when hiring.
You spent seven years at Palantir across different roles. What did you learn as an FDE that you couldn’t have learned as a software engineer?
The FDE role accelerates learning a lot. Coming from academia, where you work on these super long projects that are very obscure and specialised, it was a bit of a rebound exercise for me.
The FDE role was fun and exciting because I got to do something different almost daily. I also got to deliver value very quickly. Unlike academia, it’s highly gratifying.
What FDE managed to do for me was horizontal learning. I didn’t specialise in one thing. I was always identifying what’s the highest value thing I could be doing, and then learning through that.
There was this entrepreneurial exposure: what are my client’s problems, how do I solve them? But then also: I suddenly need to think about stability, so I’m an SRE today. Or now I need to design a UX. Or I’m a product manager working with internal teams on the product story, but I’m also doing backend debugging. You just did a ton of different things.
You joined Palantir early in Foundry’s development. What was that like?
Foundry did not work. I joined two months before the first release and it was just not great. Very bad.
But that’s actually what made the FDE role so valuable. Working with users to understand their problems and how they do their work, and then using that as a means to actually improve Foundry — that was the job. The product wasn’t there yet, so we had to figure it out alongside the customers.
You now help companies implement the FDE model. When a company comes to you wanting to “build like Palantir,” what do they usually get wrong?
The first thing I always dig into is: why do you need FDEs?
The FDE thing is not really a new idea. It’s the standard advice that has existed in the startup world. Y Combinator, anyone: as founders in early stage pre-product-market-fit, go work with your users, understand what they need, and solve their problem in a way that doesn’t scale. Then once you have product-market fit, worry about scaling.
Palantir did the same thing, except the ambition was very, very high.
Did Palantir have product-market fit when they started the FDE motion?
They didn’t. Foundry didn’t work. That’s the definition of: we have a market we’re targeting, we have some idea of what the product should be, but the product isn’t there yet.
As the product matured, a lot of FDEs moved internally and became Core Software Engineers. They started thinking about how to scale. That was a natural evolution as the platform became mature and stable. The hiring scaled as well. It just happened later in Palantir’s trajectory because of the market they were going after and the very high ambition of wanting to be the operating system of the largest enterprises in the world.
So the thing I always dig into is: do you really need FDEs? Why do you think you need them?
Getting to the bottom of that question is important because it’s not an easy function to implement. Hiring for the role is very hard. The standard trap a lot of companies fall into is they basically just build a services wing. You can do that and it’s fine. But if you want to be a product company and that’s why you’re building an FDE org, you want to avoid falling into the trap of just providing services.
Then how you structure the teams and their interfaces becomes difficult to manage because incentives are not aligned in the short to medium term, even though they’re aligned in the long term.
There’s pull from product, pull from services to sell more, to upsell...
There’s that, but there’s also the pull from FDEs. The FDEs are pulling product in one direction, and the product team is pulling it in another direction. That friction is good because it results in a better product. But it’s not great for morale, and it’s very hard to manage.
Do you think FDEs are qualified to define how the product should look based on their customer interactions?
They are the ones forming opinions based on what’s working and what’s not working.
But is there a danger the product goes in too many directions?
Exactly. A good example is the Palantir ontology. It could have easily fallen into the trap of defining what the ontology should be for different verticals. If you’re a bank, this is the ontology you should use. These are the object types and relationships.
There was this realisation that we don’t want out-of-the-box things. We want a configurable ontology, a higher level abstraction. That came from product.
The FDE’s focus is: I need an airline object, I need a flight object. If the FDE was writing code, they would have probably just hard-coded all of those things and not thought about making it configurable.
Making it configurable takes longer. You have to go through proper design. And the FDE is impatient because they want to solve the business problem. It’s very short term.
So the short-term goals are very misaligned. But in the long term, having that signal from the field is what shapes your product the correct way.
With over a thousand companies now hiring for FDEs, I asked what startups should actually take from the Palantir playbook.
There are now over a thousand companies hiring for FDEs, many with just one or two. What’s transferable from the Palantir model?
First, ask yourself the question very honestly: why do you think you need FDEs?
There are largely two buckets of FDEs. There’s the product-facing FDE who helps shape the product. And there’s the business-facing FDE who does the land-and-expand motion of what more can we be solving.
Another way to think about it: if you think of the phrase “product-market fit,” one type of FDE is going after the product, one type is going after the market.
If you have either of those needs as a startup, then the motion makes sense.
Think about the timelines too. It’s not like you answer the question once and it’s done. You have to keep asking: do we still need FDEs? There’ll come a point where you won’t need it.
For the individuals functioning as FDEs, treat it like a future founder job. Someone who wants to build something. Someone who will do whatever it takes to figure it out and drive outcomes. If you keep doing that, you’ll be a good FDE.
It’s no surprise that a lot of ex-Palantir people are founders today. It was the training ground.
What do you look for when hiring for FDE roles?
It’s a misconception that one person did all those things at Palantir. There were different types of FDEs who did different things.
I’m a huge fan of the Palantir hiring approach: you hire spiky profiles. You hire people who have a huge spike in something. You don’t hire people who are six out of ten in everything. It’s rather ten out of ten in something. And others can be lower. Then you think about how to assemble teams with complementary spikes.
So it depends on who you have and what your business strategy is. That will guide what type of people you need. The FDE role is not well-defined, which I think is by design.
I’ll give you a slightly more satisfying answer. Go up one level in abstraction. You look for people who are very value-oriented, who think about what’s the most valuable thing I could be working on, and have the autonomy and agency to go do it. People who have high grit, who can tolerate a lot of pain because they’re working on something valuable. And people who are critical, who question things and think from first principles. Just because the CEO says something doesn’t make it true.
A lot of startups are hiring one FDE and expecting them to service five, ten, fifteen customers. Does that work?
I don’t see how. Honestly, this is true today at Palantir where one FDE services multiple clients. But that works because the product has come that far.
So it’s a lot of configuring, not a lot of building?
There’s a bit of building, but it’s just a lot quicker to build. When I joined, it would be a team of three to five people working on one use case with one client. That transition happened purely because the product works really well now.
So Palantir started with one FDE per customer, then as the product matured, one FDE could service more. But now startups without a developed product are trying to have one person service multiple customers from day one.
Yeah. I’m working with two founders right now, still in stealth. The way we’re approaching the FDE function: they haven’t really hired for FDEs yet, but we’re going to try having an internal software engineer do this. He’ll be attached to one customer. The most important customer, not in the sense of revenue, but where we get the most product signal.
That’s his job: make that customer successful. They have around ten or twelve customers, but he’s going to work on just one.
It goes back to the first-principle question: why do you think you need FDEs? The answer should be either to expand the market you’re attacking or to shape the product. I can’t imagine one FDE servicing ten clients being able to provide signal on either of those.
We talked about the future of the role.
There are a bunch of YC companies building platforms specifically for FDEs. Do you think there’s a need for those?
I don’t know if such a thing exists. The role is so general and ill-defined by design that you want something super general purpose. For specific companies and their specific flavour of FDE, there will be tools tailored for them.
Looking three to five years out, do you think this role will still exist? Or will it be broken into multiple smaller roles?
It will still exist. Any company that values innovation, any company whose success depends on their ability to innovate, will need these people.
In theory, that should be every company. You could run a professional services company and not innovate at any point and be extremely successful. But for startups, yes, you’re going to have to innovate.
It doesn’t matter if you call it FDE, entrepreneur in residence, whatever you want. But what the title does is give you the freedom and autonomy to go do the valuable thing.
Anjor Kanekar advises early-stage companies on FDE hiring and operating models. You can find him at anjor.xyz.