Scan the QR code with WeChat

Add your dedicated advisor

Save

Published: 2026-09-10 21:42:11 Views: 1997

Recommendation

Analyzes the key to winning in the enterprise market: the FDE role, from definition to practical guide, helping you become the bridge between technology and customers. Core content: 1. The background and value of FDEs: the experience and core judgment of Kevin, Rippling's founding FDE 2. A framework for deciding whether you need an FDE: two key questions and case studies from traditional industries 3. Defining the FDE role: a customer-facing software engineer who must combine the responsibilities of consultant, product manager, and engineer

Yang Fangxian

Founder of 53AI / Tencent Cloud (TVP) Most Valuable Expert

01 PART

What Exactly Is an FDE?

WHAT IS A FORWARD DEPLOYED ENGINEER

Kevin Bai is Rippling's founding FDE—he joined over a year ago as the first person to build this function at the company; before that, he spent several years at Palantir, which is often credited as the "inventor" of the FDE. His core judgment: FDEs are the best way to win in the enterprise market. But the prerequisite is that you first answer two questions correctly.

Q Tell us about yourself first. How did you become Rippling's "founding FDE"?

My name is Kevin. I joined Rippling over a year ago as the first person to help build the FDE function. Before that, I spent several years at Palantir, joining in 2021—which, given how fast this industry has changed, really was a long time ago. I genuinely believe FDEs are the best way to win in the enterprise market. So beyond my day job, I also give talks at various conferences and help founders and different types of companies build their FDE functions.

Q When founders come to ask you "should we adopt FDEs," what's your decision framework?

I always start by clarifying one thing: do you really need an FDE function? It's easy to get swept up in the hype—thinking you have to do it to raise funding, or because it's accepted conventional wisdom so you should too. I think that kind of thinking is really foolish. My framework comes down to just two questions: Who do you sell to? And what do you sell?

If you're selling something highly technical and complex—like the Anthropic API, or treating GitHub as a product—they are indeed very technical, but the buyers are software engineers; the profile is the CIO or CTO, who can understand and get started on their own. Conversely, if you're selling products like Slack or Jira, the tools aren't all that technical, and most end users don't have technical backgrounds either—that also matches well.

The situation that truly calls for FDEs is: you have a highly technical product, but your ideal customer profile isn't technical. Take Palantir's Foundry: we sold to Fortune 500 companies—but they weren't tech companies; they were in consumer goods, manufacturing, aviation. There were huge, thorny problems worth solving with great solutions, yet not a single person on the customer side could truly connect the software to their business problems. That's where the FDE comes in.

In today's era, generative AI makes it easier than ever to build powerful solutions, but "powerful" also means "extremely complex." If your customers come from traditional industries, most of them may not even know what an agent is. So it's wise to make sure that "their team has no technical talent" doesn't become an obstacle to your startup's success.

Providing technical solutions to non-technical customers—the FDE is the person who builds that bridge.

Q So what exactly counts as an FDE? Can you sum it up in one sentence?

Simply put, an FDE is a customer facing software engineer. There's a history to why the role exists, but let's break the role down first: in my experience, this role carries three sets of responsibilities at once—consultant, product manager, and software engineer. Some companies split these across two or three people, but as a function, the FDE is the combination of these three capabilities.

02 What It Is Not: The Triple Identity That Gets Misread

WHAT AN FDE IS NOT

Once a role gets hot, misunderstandings follow. The most common quip is: "It's just a Sales Engineer with a new name." Kevin says, please show some respect for Sales Engineers—they do excellent work—but an FDE is genuinely not one of them, nor merely "a developer pushed to the front line," and certainly not "consulting with a new name."

Q An FDE isn't a Sales Engineer? What's the difference?

A Sales Engineer is a pre-sales function, mainly building demos to win deals, and the engagement ends once the contract is signed. An FDE is not like that—it owns the entire process end to end, from discovery to delivery.

Q Then how does it differ from an ordinary software engineer?

The purpose of a software team's existence, in spirit, is to build "one-to-many" products—make something cool and scale it to 100, 1,000, or even 10,000 users. The FDE's purpose is exactly the opposite: it is "one-to-one"—building something that solves a specific problem for a specific customer. If your thinking goes one step beyond that, you've already gone off track.

Q Some people also lump FDEs into the "professional services / consulting" category.

FDEs do draw some elements from those practices, but at its core it's a highly engineering-focused role. If your organization doesn't operate that way, that's fine—you can call it an FDE, but in the form that brought Palantir enormous commercial success, those are not FDEs.

So always remember this standard: the final output of an FDE engagement should be software.

An FDE engagement should end with software as the final output—think of it as inventing new SKUs one by one.

03 Three Hats: From "Listening" to End-to-End Delivery

CONSULTANT · PM · ENGINEER

Consultant, product manager, software engineer—this role is most effective when all three capabilities are concentrated in one person. And in any engagement Kevin has been part of, the first step is never talking—it's listening.

Q Where does an engagement usually begin?

The first step isn't talking—it's listening. Your task is to earn the customer's trust—from the executive sponsor, to VPs, to the CEO—so they see you as a trustworthy partner. You want them to tell you not just the problem that closed the original deal, but the ones that truly keep them up at night—problems that, if they were a public company, could even tank the stock price—because those are the ones worth solving.

The FDE's most important communication skill is listening.

Q What does "listening" look like in a real conversation? Can you give a concrete example?

Generally, what customers tell you is just the symptom. Suppose they come complaining that "the dashboard loads too slowly and it's really affecting us"—I won't start by saying you're wrong; that would be flippant and dishonest. But I will try to dig out the underlying root problem together: why does this affect your business? You chose to work with us in the first place certainly not because our dashboard loads the fastest. What business problem are we actually here to solve?

If, by the end of the conversation, their real goal turns out to be "selling more stuff" and they're worried a slow dashboard hurts conversion—then the question isn't how fast it loads, but how well it converts. Latency itself is a quagmire: solve it, and next week you'll want it faster, and the week after that even faster; even a tenfold speedup might produce no real impact at all. So my goal isn't just to figure out what you need, but also to persuade you, as much as I can, to buy into the problem that's actually worth solving.

Q Once the direction is aligned, how do you decide "what exactly to build"?

The ideas never stop coming: making the dashboard faster is one way; digging into this person's search history and recommending the most relevant courses is another; making the call-to-action button bigger; or even making leaving the page super annoying until they buy something—but you can't build everything. Even if the customer had unlimited money, their time is finite. Your job is to find the one thing most likely to achieve the goal and completable within the given time.

Suppose the pilot is only four weeks. What I'm looking for isn't the perfect solution with the biggest impact, but "the best thing I can finish in two and a half weeks"—because I'm certain you'll hate the first version, and then we'll have to keep iterating. It's a bit counterintuitive: some would pick an optimal solution that just barely fits into four weeks, but then you'd lose the deal, unless you can deliver flawless code on the first try—and that never happens. The key principle is iterative development, with focus concentrated on high-priority wins.

Kevin's criteria for trade-offs

Ship a minimal-scope first version, then iterate from there.

Q Does this ability come from product management experience?

What makes someone good at this isn't necessarily product management experience, but the ability to truly "own" the problem—rather than merely "owning" the project, and the difference is significant. Someone with a strong sense of ownership over a project will do grueling work and put in long hours, which is all well and good; but at the end of the day, the customer doesn't care whether you're happy or whether you work fast or slow—they care whether their problem gets solved.

So a truly excellent candidate is someone who can articulate the framework in their head—why they made a certain decision, and how they justify it along the dimension of "the problem being solved." There's no standard answer here, but there is a right way to answer the question.

Unlike a regular engineer, you can't close a PR and call it a day. You're fully responsible for end-to-end delivery: how it's built, how it's demoed to the customer, how feedback is elicited, and how you get them to ultimately accept the solution. Most people from a development background have been "shielded"—there's no DevOps team to hand off to, no QA team; you are everything, from start to finish.

One last distinction to draw: "quality" versus "completeness." Quality means the code itself is well written, with no bugs within reasonable bounds; but that doesn't mean it's complete—because the customer probably won't read that code at all. Complete means: does it run? Does the customer understand that it runs? Does it produce the business outcome the customer is paying for?

04 Who fits the FDE role? What do interviews actually test?

WHO FITS · HOW WE HIRE

FDE is a hot title these days, but Kevin puts it bluntly: reasons driven by the hype are all bad motivations—this job is essentially three careers stacked into one, with triple the surface area for failure. The real question is: what kind of person is suited for it?

Q Based on background, who is best suited for this role?

This role is a great fit for people who were founders in the past, or want to be founders in the future. The FDE role looks a lot like a design-partner style collaboration: you don't know what you're going to build, and the customer doesn't know what they're going to buy. You show up, talk with them, and then build the thing—even if at first nobody's sure whether it's actually needed. Institutions like YC and a16z will teach you the same thing over and over: go talk to customers, then build the thing.

But not everyone is a founder. This role truly sits at the intersection of three disciplines: consulting, product, and engineering: a software engineer who has always carried a product perspective, or a product manager who has always been deeply technical, is a great profile—you're basically already doing this job, just perhaps not under the title of FDE. At the end of the day, this job is for people who genuinely crave "three jobs in one."

A word of advice

Reasons driven by the hype are all bad motivations—your surface area for failure is three times that of a regular job.

Q When interviews assess the "engineering" side, what specifically do you look at?

I look at ownership and completeness. Writing the code isn't enough: where are the test cases? Do you yourself know where things might go wrong? Which edge cases could cause failures? How would you design around them? And what usage instructions would you give the customer so they don't fall into traps?

Take the simplest example: I ask you to write a function that adds two numbers. If you just write it without telling me "you can't pass in strings—this function only accepts integers," then the moment a customer passes a string, they'll think your app is broken and your platform is no good. Completeness means truly understanding the full picture of the problem: how it can be used, and how it might be misused. The good news is these fundamentals also help in regular software engineering interviews—far too many people write code without ever thinking about test cases.

Q What about the behavioral and communication side?

It's hard to demonstrate in an interview that you're a good listener, but it's not hard to demonstrate how you show up and how you work with customers—your interviewer may well be your customer, and you're selling yourself to them. The consulting industry has a term for it: "executive presence"—how well you perform in front of senior leadership. Maybe you've never been an FDE, but have you reported to a VP of Engineering at a startup? Presented to a CEO? How did you do compared to your peers? These are things you should practice repeatedly before even entering the interview process.

You can't grind LeetCode for two weeks and master every problem, and you can't become a compelling presenter just by watching YouTube videos or reading a book on public speaking—you have to actually speak and practice. The real way to improve clarity in communication is to do it with intention and preparation. My mentor used to say: "fail to prepare, prepare to fail." You can't vaguely make yourself a better speaker, but you can think about every word you say, how those words will be received, and how to prepare to deliver them.

Also, everyone has to work with people at their job—ask your colleagues how your communication is: would they say you express yourself clearly, that you can make complex things simple? If they don't say that, then ask how you could do better. Actively seeking feedback is an underrated skill too.

Q If there's only a week or two left, is there still time to prepare for the product side?

Product sense and clear writing actually have a lot in common. Start with the habit: make some decisions, then write them down, explaining clearly why you chose this over that; then find someone with zero context on your situation and no knowledge of your decisions, and see whether they can understand you purely from what you've written. Judgment can't be trained in a week, but you can spend time studying truly excellent products and understanding how they were made. The best people—in tech, art, or sales—all spend time watching others do something exceptionally well, then learn from them—you have to know what "excellent" looks like before you can apply it to your own problems.

///

LAST

The future, the ladder, and a final word

THE FUTURE, THE LADDER & A LAST WORD

Will the FDE "self-cannibalize within two or three years," as some have predicted, or is it here to stay? Drawing on more than twenty years of practice at Palantir, Kevin talks about the future, the promotion ladder, and leaves that "last word" for everyone entering the field.

Q How do you think the FDE role will evolve in the future?

Palantir has been around for over 20 years, and the FDE role has existed since the company's founding—because we realized that in environments that are extremely complex, and where neither the ultimate buyers nor the users have technical backgrounds, this is the best way to deliver software that actually works. As long as this type of problem exists, the FDE role will continue to exist.

Some FDE positions being absorbed, some companies using FDEs failing—these things will definitely happen, because there are many companies doing all sorts of things and calling it FDE, and I can't judge the entire function based on a name alone. But if what you're doing is: working directly with customers, listening to what they want, producing a plan they endorse, and then building the thing and delivering it to them—I don't see how that could fail.

Every great product is made this way—first understand one person, then build the thing and deliver it to them.

Q So what does the FDE career ladder look like?

At Palantir, FDE is a "terminal title": you're an FDE on your first day, and you're still an FDE in your tenth year. The business lead who runs the entire commercial business and manages a book of over nine figures (hundreds of millions of dollars) has the title of FDE—and that fits the Palantir spirit perfectly: there shouldn't be anything above this title. Of course, some companies now have Senior FDE, Staff FDE, and that's fine too—people are free to take the title and use it however they like.

But in this customer-facing, results-oriented role, the growth path looks like this: you gradually take on larger scopes. At first, you may not be expected to independently own a customer account; instead, you follow a more senior colleague and handle a small piece of that customer's problems. Gradually, you can own one customer on your own, then all customers—then an industry, a domain, a region. The model Palantir taught us is: give you a company, and you are that company's CEO. You have one customer, and the only way to generate revenue is to make that customer as successful as possible. If you do well, maybe we'll give you a few more customers.

Q Finally, any advice for people who want to enter this field?

At the end of the day, you have to figure out what you truly want to do—you only get one career. Do you want to be an FDE because that's what you genuinely want to do, the role you've been waiting for? Or because someone told you it's what you should do, or because it's trendy and in the news? The people who perform best in interviews are those who have a real reason for the role and genuinely want to succeed in it. If you don't have those reasons yet, that's completely fine—take the time to figure out what you truly want to do, then go there and do it to the best of your ability.

I also want to offer a reminder: FDE is a very special job, but it's still just another job—not a panacea that will solve all your problems. I can assure you that at many good companies, including Palantir, there are plenty of FDEs who are deeply miserable. It's a profession, just like software, product, and recruiting are professions. At the end of the day, choose something you think you're good at, then find a role that brings it all together.

The skills themselves haven't changed—only the form, the titles, and the roles have. FDE isn't just another trendy title, but a combination of capabilities for "truly solving problems for customers," requiring someone who is both willing to listen and able to deliver. Kevin has also brought his years of practice into his own podcast. If this "one job, three roles" role appeals to you, you might start by doing what he suggests: write down your first decision—what is the problem I truly want to solve?

53AI, the top service provider for enterprise LLM deployment

Products: scenario deployment consulting + LLM application platform + industry solutions

Commitment: free POC validation, partnership only after results meet the bar. Zero-risk LLM deployment, delivered to 160+ mid-to-large enterprises

Loading...

Scan to consult

Scan to log in

By logging in, you agree to the "53AI Website Service Agreement"

Service Agreement

Welcome to the [53AI Official Website] (hereinafter referred to as "this website" or "we"). This "Membership Service Agreement" (hereinafter referred to as "this Agreement") is a legal agreement between you (hereinafter referred to as "Member" or "User") and [Shenzhen Bosi Xiechuang Network Technology Co., Ltd.] regarding registration, login, and use of this website's membership services.

Before you register or log in, please carefully read and fully understand the terms, especially the liability exemption and limitation clauses, intellectual property clauses, and dispute resolution clauses. Such clauses will be highlighted in bold for your attention. When you successfully log in to this website via WeChat official account authorization, SMS verification code, or other means, you are deemed to have fully understood and agreed to accept the entire contents of this Agreement.

I. Definitions

This website: refers to the website operated by [Shenzhen Bosi Xiechuang Network Technology Co., Ltd.] with the domain [53ai.com] and its related mobile pages.

Membership services: refers to the knowledge base article access, content search, and other related value-added services provided by this website to registered members.

Knowledge base content: refers to the digital content resources published by this website, including but not limited to text, charts, data, research reports, industry analyses, etc.

II. Account Registration and Login

Login methods: This website supports the following login methods, which you may choose based on your circumstances:

WeChat official account authorization login: You agree to authorize your WeChat OpenID information to this website for the purpose of creating or linking a member account.

SMS verification code login: You must provide a genuine and valid mobile phone number and complete identity verification and login/registration via SMS verification code.

Account security: Your account is for your personal use only; gifting, lending, renting, transferring, or selling it is prohibited. Losses from account theft or password leakage due to your failure to safeguard them shall be borne by you.

Real-name verification: As required by relevant laws and regulations, we may require you to complete real-name verification for certain features. If you refuse to provide it, you may be unable to use some or all services.

Protection of minors: If you are under 18 years of age, please read this Agreement accompanied by your legal guardian and use this service only with your guardian's consent.

III. Service Content and Standards

Knowledge base access: After logging in, members have the right to browse and search relevant articles and content in this website's knowledge base online, within the scope of permissions corresponding to their membership level.

Service changes: We have the right to adjust, change, or terminate part of the service content based on business development needs, and will notify you in advance via website announcements, official account messages, etc.

Prohibited conduct: When using the services, you must not engage in the following:

Using technical means to bulk crawl, download, or re-save knowledge base content;

Using knowledge base content for commercial purposes or disseminating it to third parties without authorization;

Interfering with the normal operation of this website or infringing on the legitimate rights of other users;

Publishing illegal or non-compliant information or engaging in activities that violate public order and good morals.

IV. Intellectual Property Statement

Rights ownership: The intellectual property rights of the layout design, software code, and other content in this website's knowledge base belong to [full company name] or the original rights holders, and are protected by laws such as the Copyright Law of the People's Republic of China.

Limited license: This website grants members a non-exclusive, non-transferable, non-sublicensable general license, limited to online access to knowledge base content for personal study and research purposes only.

Infringement liability: Without written permission, no organization or individual may copy, reprint, excerpt, mirror, compile, or otherwise use the above content in any form. Once discovered, we reserve the right to pursue legal liability.

V. Personal Information Protection

We value the protection of your personal information. For how we collect, use, store, and protect your personal information, please read the "Privacy Policy" separately.

The information you provide through WeChat official account authorization or phone number verification will be handled in strict accordance with the Personal Information Protection Law, and will only be used for necessary purposes such as identity verification, service provision, and security authentication.

You may at any time exercise your rights to access, correct, or delete your personal information, or withdraw your authorization and consent, through the website settings or by contacting customer service.

VI. Disclaimer

Content Accuracy: The knowledge base content is for reference only and does not constitute professional advice. We make no express or implied warranties regarding its completeness, accuracy, or timeliness. You should make your own judgment and bear the risks of using it.

Force Majeure: We shall not be liable for breach of contract for service interruptions or delays caused by force majeure events such as natural disasters, changes in policies and regulations, network failures, or third-party platform interface anomalies (such as WeChat interface maintenance or carrier SMS channel failures).

Third-Party Links: This website may contain links to third-party websites. The content and services of such websites are beyond our control, and you should assess the risks yourself.

VII. Liability for Breach of Contract

If you violate this Agreement, we have the right to take measures such as warnings, feature restrictions, service suspension, or account cancellation, depending on the severity of the violation, and reserve the right to demand compensation for losses.

If your breach of contract causes us to suffer administrative penalties, third-party claims, or damage to our reputation, you shall bear full liability for compensation (including but not limited to fines, damages, attorney fees, notarization fees, etc.).

VIII. Governing Law and Dispute Resolution

The formation, performance, and interpretation of this Agreement shall be governed by the laws of Mainland China.

Any dispute arising from or in connection with this Agreement shall first be resolved through friendly negotiation between the parties; if negotiation fails, either party may file a lawsuit with the people's court of competent jurisdiction in the location of [Company's Place of Registration].

IX. Miscellaneous

This Agreement constitutes the entire agreement between the parties regarding this service and supersedes any prior oral or written agreements.

If any provision of this Agreement is held to be invalid or unenforceable, it shall not affect the validity of the other provisions.

We have the final right to interpret this Agreement and reserve the right to modify it at any time within the scope permitted by law. The modified Agreement takes effect immediately upon publication, and continued use of the service shall be deemed acceptance of the revised content.