A prologue is really just a list of excuses and explanations you make in advance to protect yourself from criticism, especially your own. So feel free to skip it.
Lately I keep hearing people talk about FDEs, or “Forward Deployed Engineers,” and most of them have no idea what the hell they are talking about. Not because they are stupid—though some might be—but because they have never been close to the real thing. So I am going to give you an account—mine, obviously—of what a team like this means, why you build one, how you run it, when it makes sense, how you hire and train it, and, while we are at it, why most of the clichés are bullshit.
But if you only remember one thing, make it this: FDEs are useful, they make sense, and you should consider having a team in your product company, especially if you sell high-ticket contracts.
This is really for founders or people building these teams: B2B companies selling to reasonably large companies—though not necessarily—with products that require some integration.
But if you want one of these roles, or already have one, I think it helps to understand how other people do it. That always helps, whatever the subject.
I am the founder of a B2B startup—Tinybird, around 70 million in funding, tens of millions in ARR. We build a technical product, and we built both the company and the product starting with an FDE team. The term did not exist for us then, but never mind. It was a good way to have customers fund your product research while getting useful help in return. You know, business.
The team is still running eight years later. It not only helps customers with specific problems, but is also part of the support team. Rather than having me tell you whether they are any good, let the people receiving the help do it for me.
I do not think many people have real experience with this, and even fewer are writing about it. Hence this document.
For those of you who just read B2B and have no idea what comes next: when you build a product and sell it to reasonably large and/or sophisticated companies, they normally need help. Some because they are hopeless, some because internal politics prevents their teams from executing, and others—the interesting ones—because they need your particular capabilities. In B2C, or even low-ticket B2B, you launch the product and leave people to figure it out. In high-ticket B2B, you do not want to leave them alone.
And, for the love of God, let us not kid ourselves: it is very hard for your software to fit a company’s requirements perfectly. There are always corners and nuances that need adapting. There is no shame in having a team that helps. There are legendary exceptions—Datadog, for example—where customer teams will happily beat themselves up solving the problems on their own, but even they always have technical people helping.
The best explanation—an indirect one, granted—is this excellent article by a former Palantir employee. Palantir are the friends who coined the term. To be clear, call it FDE or whatever you like; it is someone who 1) knows what they are doing, 2) gets a foot inside the customer’s organisation to understand and solve their problem, and 3) brings home knowledge you can apply to your own product.
Traditional consulting does 1 and 2. Well, some consultancies do very little of 1 and focus entirely on getting that foot in the door from 2. Ideally, an FDE should focus on 3. An FDE should be able to return from the customer and implement whatever the product needs. That is relatively easy when the team is small and very difficult inside a large company.
There is a better way to define the role, though. The difference between a traditional consultant and an FDE—or at least how I see it—is that the FDE has skin in the game. They stay until the end and take responsibility. At Tinybird I have watched people on my team take over the customer’s project management because they could see the customer would never make it to production otherwise.
My definition is simple, but it has been extremely effective for me: your objective is to get the customer into production as quickly as possible.
I have repeated that sentence roughly a thousand times a week, but it matters. Never get distracted by things like “billing more” or “providing technical assistance.” Sometimes the right help is to propose a solution that means not using your product at all.
To do that, obviously, you need to understand their problem. To understand and solve it properly, you need their context. You get context by asking, understanding, and asking again. Propose a solution, test it, validate it, ask again—and repeat. Developers happen to be experts at doing exactly that. We will get to this in the next chapter.
So if you stop reading here, you already have the key: do not get tangled up in metrics and stupid secondary objectives. If your customer wins, you win—in revenue, retention, your relationship with the customer. All of those are second-order effects.
One detail should not go unnoticed: when you go into a customer to solve a problem, sometimes the problem is not properly defined and you have to define it yourself. There is no more effective way to learn something than facing the situation firsthand. It is the difference between watching someone solve a maths problem and solving it yourself. You know what I mean.
Whatever you do, the team is the key. Ed Catmull explained it in one sentence far better than I could:
There is an important principle here that may seem obvious, yet— in my experience— is not obvious at all. Getting the right people and the right chemistry is more important than getting the right idea.
The right people with the right chemistry. Remember that. What you do still needs to make at least some sense, obviously. Catmull took that for granted, but we are Spanish (for the non-spanish reader, we are usually pretty bad at selling ourselves, so I wanted to laugh at it), so it is better not to risk it.
Our premise was: “people are working with data the way they did 15 years ago, but the technology and hardware are much better now; we can help them do it better.” Eight years later, I can say that premise was correct.
It depends on the product, of course. Ed and I have already told you that. But for the love of God, hire people who know what they are doing. Do not fill the team with paper-pushers who can only send emails and keep people warm. They are useless here. You need capable people with initiative. Those people are normally expensive. Do not cheap out. They tend to be engineers—that is more or less where the definition of FDE comes from.
I will say it again: do not cheap out. Every euro invested in these people pays back. A lot of companies try to save money here, in support, and in other things without an obvious return. In my opinion, that is a mistake.
In my case, I hire backend engineers. Yes, our field was “data engineering,” but “data engineers” were mostly people who knew how to use four tools, so we chose people with software experience and strong fundamentals. They did not know shit about working with customers, but that did not matter. People learn.
I feel ill whenever I hear that these profiles need business knowledge and must know how to navigate and play politics. My experience is that when someone knows how to do that, they use it and end up “solving” things through manipulation. I was going to use a softer word, but why bother. In the long run, someone who solves things with facts and has a bit of initiative is much better.
You can have people who “navigate,” but they are there to support the FDE. I will explain how later.
So forget that requirement. People can learn. At Tinybird I have hired people who spoke while staring at their shoes, and they ended up working with customers—and enjoying it.
Could they just be individuals? At the end of the day, it is one person working with one customer. Probably. But having a team makes sense, or at least that is how I have done it.
First, as always, somebody needs to keep prodding. Have you ever gone into a government office to do some paperwork? Did you see anyone who was not serving a desk, but simply watching to make sure the work got done? Someone who, when the civil servant says, “this requires form 405 and you need to go to another office,” replies, “no, we are sorting this out here.” That is what you need: someone who makes sure things happen.
Second, the team needs to prepare onboarding and processes carefully, organise and feed information to product, know when to apply pressure to get something finished, provide people to validate proposals with, and so on.
They help customers with the parts they do not know. They are not a bucket of billable hours; they are the resource that knows. In our case, FDEs do FDE work and also help in pre-sales, post-sales, support, and so on. Here I am only going to cover the work inside the customer.
There are three clearly defined legs to the work: 1) with customers—obvious, as Gen Z would say; 2) internally—not so obvious; and 3) with product—50% obvious.
1) The customer cycle is “relatively” simple:
The last part of this document covers the less technical management around all this.
2) Internally—what the team does as a team:
3) With product:
An important point: people get tired. AI does not, but people do. It is a good idea for them to 1) work with more than one customer at once and 2) change customers from time to time.
Ideally, an FDE should spend time in product. But let us be honest: moving people around is not trivial, and once you arrive in product you settle into the warm protection of product managers, engineering managers, support—the land of make-believe where problems are Linear tickets instead of situations in which you have to show your face.
Another good way to rest is to work on a difficult challenge. Customers regularly ask for absurd things. That is fine; I do it myself all the time. Things that look impossible at first. In our case those challenges look like “run this kind of query over 10 trillion rows in under 100 ms,” and they require going very deep. That research is pure gold. It keeps the team awake, raises the bar, and consolidates the fundamentals. It is expensive, but a demotivated team is more expensive.
If you think the objective of this kind of team should be to maximise revenue per customer, close this page and go sit in the thinking corner. The people who “know” call this “customer success,” and it is the absolute plague of the industry. No. Your objective, always, is to solve problems as quickly and as well as possible. Everything else is bullshit or something that will follow from good work—for example, money.
You might think you need people with customer experience, consultants, or unicorns who understand technology and can deal with humans, dress well, have charisma and presence, are tall and handsome, romantic but firm…
No. You probably need to hire whatever your customer needs. Here is an example: we deal with developers, and those people can detect bullshit from 200 kilometres away. They do not trust anyone who cannot prove they know what they are doing, and they usually have very particular communication habits. Put someone in a suit in front of them and they will tear that person apart in half a meeting, and you will have lost your chance.
You need a minimum of respect and manners, and you need to be clear about what you are trying to do. You do not need to be a con artist. You just need some basic rules, which I will cover in the section on working with customers.
At Tinybird almost nobody we hired into this profile had customer experience. They did know what they were doing, and that is what matters. Having said that, I led this team, have spoken to hundreds of customers, and my personality is not particularly friendly—as you can probably tell from this document. Politics is not my thing, and I cannot read the dynamics of a group of people.
I do not think this is very different from what you look for in a product, backend, or whatever engineer, but I put A LOT—an enormous amount—of weight on how someone discovers the unknown.
The process is this: I propose a VERY open-ended but extremely simple technical exercise. There is an example here1. Once I see their approach, I keep changing the rules in the follow-up questions to understand how they frame problems.
The selection criterion is simple: if they start solving without asking questions, bad sign. If they ask, form hypotheses, try to understand, clarify, and narrow the problem, that is your person. Bonus points if they are technically solid too, obviously.
One important detail about hiring: it never ends, and it is not something you do occasionally. You need to talk about what you do. You need to be attractive to people, so that when you publish a role you already have good people interested. This is as easy as publishing useful things regularly, which almost nobody does because they leave it to marketing people who usually have no fucking idea what they are writing about.
Finally, hiring is Tetris. You have to find the right piece at the right moment. Sometimes the long bar is useful; sometimes it is not. Balance is the key.
Onboarding is much more important than hiring. Good onboarding can fix a bad hire—and ruin a good one. The fundamentals are:
At Tinybird I use ancient techniques nobody could possibly have invented before:
Nobody likes talking about firing people because, culturally, it hurts. That is normal. If your country is a place where most jobs are low-skilled and the ultimate life goal is a permanent job—with the civil service as the final boss—it makes sense. Fortunately, in our industry, if one company fires you, you are doing four interviews the next day. It still hurts, but it is drama, not bloodshed.
With that out of the way, you can fire someone because they are not up to the job, do not fit the team, or whatever. But the one thing you must NEVER allow is a customer being poorly served or somebody making “excuses.” This is a business built on trust. That is the foundation you cannot lose. Likewise, if you are an FDE and your boss asks you to lie, start backing up your email and opening LinkedIn.
Not everything is technical. There are other important things to do with customers, especially reaching agreements, providing visibility, setting limits, and managing the relationship with the people in charge.
This is where a business person usually comes in: an Account Executive, a founder, the CEO, a CUSTOMER SUCCESS MANAGER KEY ACCOUNT ENTERPRISE SENIOR, or whatever God has decided to call them. I affectionately call them the suits. The important part is that this person sets the pace of the relationship, establishes limits, talks about money, and plays bad cop.
The suit NEVER, under any circumstances, gets involved in technical arguments. Two reasons. First, they will screw it up and lose credibility with the technical teams. Second, it is better to keep a clear line between operational/technical work and customer management. Think of them as two tracks, each doing its own thing. Eventually the FDE and the business person should be able to exchange a glance—over Google Meet, obviously—and know when one needs to step aside for the other. If you are the founder, you can do whatever you like and blow up the deal. That is what you pay yourself for. It is a joke, but it is not untrue.
As I said, work with a customer always begins by talking about the problem to solve, with all the urgency in the world. Ask for access, data, contacts, and anything else you need to discover things as quickly as possible. The nerd—the FDE—does this work, not the suit.
That said, expectations need to be clear: time, commitment, money, and limits. This costs this much; you will speak to these people; you will have access to this person with this response SLA; we need this and that; and it costs this much per month—which of course everybody will try to include in ARR so the AE earns more commission. As God intended.
On the commercial side, you need to understand how your customers allocate budget. There are several ways to charge for the work:
Whatever the model, limit the hours, dates, involvement, response SLAs, and so on, just as you would in any contract.
You can choose not to charge and assume there will be a return. Sometimes it works, particularly when you are swimming in millions after raising a wildly overpriced round and a few thousand a month makes no difference to you.
As I said, the business track has another job: making the work visible. The impact of an FDE is not always obvious. So when your “business” person meets—and they need to do this regularly—with the “business” person on the other side, the very first thing they explain is, “look, this is what we have done.”
Obviously, you prepare this meeting beforehand. The FDE and the business person get together, review the reports written by the FDE—hence that wonderful culture of documenting everything—and prepare:
Projects never end; they slow down. But it matters that you keep an eye on how things are going. You can do it semi-automatically, in check-ins, through metrics, or by asking the customer’s team.
And if you work at a product company—otherwise, why would you have FDEs?—you know perfectly well whether they are going to churn, fully or partially. So you can make those wonderful forecasts senior leadership loves so much. And if you are smart, instead of staring at the forecast, you will do something to save the customer. You can almost always save them.
People inside customers come and go. You need to pay attention and earn the trust of the new people. If you did good work, it should speak for itself, but always remember that humans are the worst and somebody may simply dislike you. If they dislike you, well, that is life. Just make sure it is not because you did a shitty job.
The work should be billed directly, billed as premium-support hours, or have a blindingly obvious ROI through expansion. This seems obvious, but especially in a startup it is easy to drift into “well, we will discuss it later.” In my opinion, you should jump into the pool and take some risk, but the numbers need to work after a few months. Otherwise, you are working for nothing.
Customers get used to incredibly good treatment and then refuse to accept anything less. That is why you charge and make sure the work is valued.
Leaving aside the fact that working and solving problems obviously makes money and teaches you things, there is something we forget: solving problems is fun and satisfying.
Many developers who had never worked with customers miss it once they move into other roles—normally product, because who is better suited to build a product than someone who has fought with it? Not only that: they have developed the habit of working with customers, they know how to ask the right questions, and they have ease. Soltura. I love that word.
It is not all sunshine and oregano. These are some of the problems we have run into:
Sign up for this course for only… nooooo, I am kidding.
If you made it this far, you have a B2B product company, want to build a team, or already have one and have questions. I am happy to help—write to me and we can talk. For free. I do not do this for a living; it is my way of doing my bit for the ecosystem.
If you read the post, you will see that I banned ChatGPT. Later, I would make it mandatory. ↩
As a manager, there are two important things I tend to do: