“An FDE is like a teacher” with Aircall’s Rockstar FDE Apoorva Sharma

Editor’s note: Welcome back to Anchor Deployed (and welcome to new subscribers!).

My request: Can you please reply to this email with the name or email of 1 person who you think would derive value from this newsletter? Could be an investor, colleague, portfolio founder, classmate, friend. I’d love to send them a message to personally invite them to the community.

Apoorva Sharma is an FDE in North America for Aircall, a voice AI company with over 800 employees and 23,000 customers. They are a unicorn and have raised over $200M. On any given day, he speaks with a half dozen clients while building solutions in advance of each deployment. He thinks at a systems level and in this interview, Apoorva provides an on-the-ground perspective of how the FDE role is evolving in real time.

Apoorva: I grew up in the Bay Area. Growing up here, everybody is kind of conditioned to get into tech. I was more interested in business and operations. My family ran businesses in India, and so naturally I was more curious about that. Technology was more of a tool rather than this thing that I would focus on my entire life. But just being in the Bay Area, I think through osmosis, you naturally get brought into technology and the startup world.

I got my first exposure to a real tech job during my first internship at Skale Labs, which is a blockchain infrastructure company. You could imagine AWS for decentralized applications, providing elastic side chains and elastic compute. I was a solutions engineer there, so it was very similar to what FDEs are sometimes being classified into now: sitting with the customer, troubleshooting their problems, understanding what they want out of the application, and then working directly with our Chief Product Officer to get those features built or prioritized.

A lot of the early FDE seeds were planted then. After Skale Labs, I tried to build my own startup, and that was really when I fell in love with the work that turned out to be what I do as an FDE day to day: talking to customers, learning about their business challenges, deeply understanding their business, and then devising a full custom solution to solve or automate the problem for them.

I never really considered “FDE” as something I would pursue. I always considered it to be a little more on the technical side because I knew people at Palantir who were FDEs. I was very much in awe, and I was like, "This is definitely not something I can do."

But a friend recommended it to me and said something along the lines of “Hey, this is something that you should try. It might work for you. It seems like a good fit." That's when I applied to be an FDE at Aircall, and I got in and pretty much have loved it ever since. 

Apoorva: For me personally, a lot of the two roles is the same: talking to customers and developing technical solutions for them. The difference is the structure. A larger company has multiple steps between the customer and the engineering solution. As a founder, you are engineering and you are sales. You are the one on the call with the customer. I think FDEs are doing that now, so it is very similar. Aircall provided a lot more structure than we had at my previous startup. 

As a founder, you own the entire outcome and have to build the structure for the next person, yourself. As an FDE operating inside an existing organization, you're still responsible for connecting the customer, product, and technical solution, but the organization owns the generalization step.

Apoorva: First off, I believe that FDE is not a job title. It's a group of characteristics, in other words it describes the type of person who does a given role. 

Somebody who is obviously curious would be at the top of my list. You have to be genuinely curious about business and technology, and you have to be hardworking. Those two things make the best FDE’s.

Apoorva: At a high level, we started in 2014 in Paris as a cloud telephone company. We integrate with your CRM and work really closely with Salesforce and HubSpot. Now we are expanding into voice AI, acquiring voice AI companies and models so we can serve them in-house. It's like a startup culture within a large company.

We have an AI solution, which is essentially an AI voice agent that will sit in your call flow, handling communication. Aircall has been around for awhile, so we have a range of large enterprises and smaller businesses as clients.

Aircall does over $100M in annual recurring revenue.

Apoorva: To be clear, this is what I've seen across the industry, not any one company. The market saw value that was being derived from products like ChatGPT. And, of course, the zeitgeist said, "AI is coming, and you need it to survive." Customer demand blew up. Then, to capture market share, companies exploded their AI features.

The block became how to actually implement the features that the company was advertising to the customers who were demanding them. 

From an economic standpoint, the projected recurring revenue for a client ended up halving or even even being cut by 10. How it often would work is AI companies would say "Hey, I can pitch this feature to you, but it's going to take me six months to actually implement it." The customer who was saying, "I'll pay $100,000 for this feature," now says, "Let me start off with a $10,000 or a $1,000 trial first and then expand into a $100,000 contract."

It not only extends the sales cycle; you end up providing care for that client over a longer time. Your company is investing more resources, but you're also not seeing the full expected ROI.

Then, your VCs are saying, "I'm dumping money into your company so you can add AI features, close market share, and capture revenue." What you end up doing is taking that money, advertising AI features, but actually capturing one-tenth of that expected return. Your VCs come back and say, "Where is all that money?" And you're saying, "It's stuck in potential pipeline.”

Herein comes the role of the FDE: they make the deployments possible so you can actually capture the revenue.

The goal of a FDE is to maximize the deal. Their job is to scope the project well and then be able to funnel that feedback back to product so they can build the requested features fast enough that you can capture the biggest deal size.

Apoorva: There is a camp of FDEs that sit under RevOps, and so they contribute to recurring revenue figures. Others sit directly under solutions engineering, and so they're measured by how many clients they've onboarded or implemented. Others don't have any of those, but still get rewarded for how big of a client they're dealing with and how much net revenue is retained through their work on that client.

It depends on how you're leveraging them. Again, I don't define FDE as a job role. I think that's quite narrow. It's a suite of characteristics, so it depends on what kind of value you're trying to extract from that type of person in your company and in that motion. The most common that I've seen is they sit under RevOps and contribute directly to recurring revenue.

I think revenue is the best metric to assess an FDE, both net new revenue and expansion. My rationale for this sits under the premise, which I believe, that FDEs are here to realize new revenue that is sitting in unrealized pipeline.

Apoorva: In the same way that account executives and account managers need to become technical to succeed as FDEs, software engineers similarly need to become commercial. Becoming commercial doesn't mean becoming a salesperson. It means understanding the customer's business well enough to connect the technology to the problem they're actually trying to solve. And the best way to make that connection is through education.

Ultimately, what an FDE does differently to succeed isn't necessarily sales; it's education. An FDE is like a teacher. They're educating the client on what AI is, how AI works within the product they're selling, and what else that technology might make possible for their business. Whoever can do that effectively is a good FDE. 

Apoorva: All the time. Every interaction I have with the customer is an opportunity I take to try to educate them.

For example, let’s say a client asks: "Hey, can you tell me how this is configured so I can validate that we're all good to go before I go live?" I can say, "Yes, you're good to go. Good luck. Looking forward to the results of testing.” But what a good FDE would say is, "This looks great, and this is why this looks great, how it will work, and why this will work." Then in the next call, you can explain why the other setup won't work.

You should be trying to educate the customer at every opportunity because there is a gap between what customers expect AI to be able to do and what the technology actually makes possible. The more they understand the technology, the more they can participate in the solution with you instead of simply telling you what they want built.

Apoorva: Aircall does business with a lot of different kinds of businesses. We work with small and medium businesses and large enterprises. 

Apoorva: Connecting the dots for them and making it very obvious how the dots connect. To truly understand how to leverage AI, you can't just understand it from a surface level.

Everybody says AI is non-deterministic. The roots of that non-determinism live very deep within machine learning. You need to start explaining to the customer where that non-determinism starts, and then connect the dots for them upstream through the layers all the way to the application where you're screen-sharing and showing them the button, so they can understand what is actually going on behind the application layer.

By doing this education proactively, you avoid the situation where something goes sideways and they call you and ask to cancel their contract. They're not a churn risk as soon as the AI model goes out of turn. They understand that non-determinism is baked in, and they're actually more tolerant and more open because you explained to them how all of that is impacting the product.

Frankly, everybody understands that we're all trying to work with AI and understand it as we go. If you can (1) explain potential breakdowns and relatedly, build trust that you know what you’re talking about and (2) almost add them to a secret club that they feel like they're part of because none of their friends know this, you become a trusted partner to that stakeholder.

They feel like, ‘Okay, I understand the technology a little bit better. I have an edge, so I am actually ahead. Let me expand, even if it's not perfect. Let me try more AI features because AI is going to change my world because this is how this person explained it to me.’

Apoorva: They're grateful that somebody can explain it to them at their level. You have to make it analogous to their life, almost like that joke everybody says: ‘Break it down and explain it to me like a five-year-old.’ You almost have to do that for your customer every time.

Apoorva: Slow down. Slowing down goes hand in hand with being very good at scoping. Oftentimes, if you come from a technical background, you hear a problem and are trained to jump to solve the first problem that you see as fast as possible. In reality, there might be an opportunity that's bigger and actually easier to implement, just hiding behind some questions. By slowing down and listening more, you'll actually find more opportunities for bigger solutions.

Apoorva: The core build is done at least two days before the deployment meeting; the final days are for collaborative testing and sign-off. Right now, I'm meeting with three to five clients a day on a regular basis. At present they're all virtual, but some are going to be on-site because the deals start very small and then expand over time. Being on-site matters more as deployments get complex. Remotely, you see the customer's remote version of their process; on-site, you see how people actually work and catch new problems."

When we have the deployment meeting with the client, we make sure that we have reviewed everything and gotten everybody's sign-off. Once we get sign off, it can be as simple as deploying a workflow from our no-code platform, or some of our FDEs will be on-site deploying things directly to customers.

I put together a deployment packet that covers all of the expectations with this deployment and everything we covered throughout the engagement cycle. Questions addressed in the packet include:

Apoorva: Building can mean working with somebody on our product team to get a new feature unblocked, or taking something to legal to get some sort of sign-off that is needed. It could also be literally building new features, new workflows, new applications, or new pages directly into the application.

Apoorva: You're going to be everything for everyone at all times. You're not just a software engineer debugging and writing code. You're not just an account executive or account manager following up on emails and setting appointments with clients. You're not just a product manager following up with engineers on product features.

You're everything, and you're doing each thing all the time. If you are awake and there are questions coming in about the product that are somewhat technical, you are expected to answer them and to get help to the person who needs it. You're the front line both outside the company and inside the company.

Apoorva: FDE is a strong training ground because you develop technical, commercial, and product instincts at the same time. From there, people can move into product, solutions leadership, applied AI, or founding a company. You're learning how to identify a problem, design a solution, and get people to adopt it. These skills transfer almost anywhere.

Apoorva: Today, I would say yes, but I would not say that is what the standard should be. In the short term, yes it is on the FDE, and FDEs are best suited to do that given we're sitting where a lot of that information is being created. We're hearing what customers are asking for, where they're getting stuck, what workarounds they're creating, and where they see new opportunities for the technology. We have a unique view into those patterns. But in the long term, it should not be an FDE's job to funnel that feedback back. It should almost already be there.

For a lot of the companies I've spoken to, such as Palantir, much of their FDE motion is the same: an FDE is paired with a deployment strategist to solve their client’s problems. What's less mature almost everywhere is the loop back to product which means that that problems across clients aren’t necessarily being systematically solved. Right now, any kind of way that you can funnel feedback back and get other product leaders involved is the right way. There is no structured way. I hope it stops being a person's job and becomes part of the infrastructure. 

Apoorva: I've definitely heard of some companies solving the data scatter problem. It's not an uncommon problem. Each company is solving it in a different way because their data lives in specific places. A large healthcare system has a very different system of record than a small e-commerce company, so how you capture that information differs for each. Nothing is centralized.

Apoorva: We’re going to start seeing more specialization within the FDE umbrella. Every role will start with ‘forward deployed’ or ‘deployment strategist’ something. 

We'll see more people taking meetings in-person and being on-site with customers. Those FDEs are there to understand the customer's main pain point and solve that problem fast. I think that's what differentiates a good FDE from another FDE. Yes, you may be measured against recurring revenue generated, but you should not be talking to a customer with the goal being, "How can I maximize usage of my product?"

You want to maximize the solution. You want to give the best solution to the customer, not maximize usage of your product from the customer. FDEs are in a position where we can do that. It depends on how you're incentivized, and the best FDEs will try to solve the problem, not focus on product usage.

Apoorva: That's where FDE motions start to split: the FDEs who are incentivized to drive revenue and the FDEs who are incentivized otherwise. Those are two different kinds of FDEs.

I think everybody will move toward driving revenue. It's just that the mechanism you're going to be using to drive revenue is different. It's not going to be the [AI] model. I'm not going to be charging you based on how many tokens you use. For most FDE-driven companies, the value their customers are going to get from them is the ontology they build on the customer [editor’s note: this concept of ontology was first made famous in Silicon Valley circles by Palantir; see more here].

Apoorva: FDEs accelerate AI adoption by disrupting processes. That’s why we’re becoming mainstream for every AI company. But this comes with pros and cons.

Pro: We can go into a client and say ‘Tell me your biggest problem,’ and I'm going to come in, rebuild it, and solve it for you. We’re breaking the processes that didn't let the company accelerate before.

Con: if you are tacking an FDE motion onto an existing company, it's going to disrupt the existing processes too. They will suffer to keep up with how FDEs are rebuilding their own company from within.

Apoorva: It's not the same as software engineering. If you're afraid that you have to be super technical, that’s not the case for many companies. FDEs come in all different shapes and sizes. I'm hearing about people at Palantir coming from really remarkable backgrounds and being forward deployed engineers. You imagine them being super technical and super sharp. That is true, but that shouldn't deter you from trying to be a forward deployed engineer. You'll be surprised at what kind of skills companies are looking for in the people they put in the FDE position.

I have friends looking for jobs who are focused on building their coding skills, and I'm saying, "Don't LeetCode." [Editor’s note: LeetCode is a platform to help job candidates get ready for technical coding interviews]. A better use of time is to pick up the phone and start dialing. Talk to customers. Get on the phone with businesses. Go through the motion of being on camera, being customer facing, and diagnosing problems, because that is the value, not only the coding work.

Apoorva: Being able to connect the dots and explain it that way. Where there may be a disconnect, and this is what I've seen from software engineers who step into a forward deployed role without the business background, is that they often think spewing a bunch of technical jargon at the customer is going to convince them that you know what you're talking about. That's not the case.

You want to explain to them what you're doing. Again, the education part. Break it down to their level. That's often what people underestimate about the job.

Apoorva: You should be obsessed with the customer's problem, not necessarily with doing exactly what the customer asks you to do.

A customer might come to you and say, "I need this feature built." A good FDE asks, "Why do you need that? What are you actually trying to accomplish?"

You're not just trying to make the customer happy on the next call. You're trying to understand their business well enough to solve the problem (even the problems they may not immediately see) and then make sure what you learn doesn't die with that one deployment.

The best outcome is that you solve the customer's problem today, but you also uncover something that helps the company build a better solution for every customer tomorrow.