FDE (Forward Deployed Engineer) is having a moment in China. The Palantir definition: engineer goes on-site, embeds into the client’s actual business flow, and doesn’t leave until things are running for real. The AI era revived this concept, because the biggest problem with LLM products is “demos are impressive, deployment is hard” — and FDE looks like the answer.
But here’s a less comfortable take: before you bring the FDE label to China, you need to understand three real collisions. These aren’t “things to watch out for.” They’ll hit you in your first month, and none of them have clean answers. This article isn’t a checklist. It’s just these three.
Collision 1: You want to co-build, but your co-builder doesn’t want you there
The FDE model, at its core, is about co-building. Requirements are fuzzy so you figure them out together. Outcomes are uncertain so you iterate. Success is measured by business impact, not a signed-off feature list. This works at Palantir because their clients — CIA, BP, Airbus — already have strong business analysis capability and internal willpower. What they’re missing is a technical partner who can operate at that same level.
That’s not the reality in China. Thirty years of enterprise services have settled into a clear pattern: “I state the requirements, you write the code, I verify delivery.” Behind this pattern are two hard structural reasons:
First, Chinese enterprises aren’t buying capability — they’re buying certainty. Procurement hates uncertainty. Requirements must be explicit, timelines must be committed, outcomes must be predictable. Nobody cares about what actually happens — the contract needs to spell it out. This isn’t the client’s fault. Decades of IT outsourcing — from early system integration to the SaaS era — have trained the buyer-supplier relationship into a transaction of deliverables. The buyer pays for features, not uncertainty. And the core value of an FDE is precisely the uncertain, process-driven, iterative part.
Second, Chinese enterprises lack a “business-technical partnership layer.” Palantir-style FDE works because there’s a peer on the client side: someone who knows their business, has decision-making authority, and is empowered to define problems with you. In China, the organization you face is fractured: business people don’t understand technology and have no authority, IT people understand technology but not the business details, and the person with actual authority — the boss — only shows up at key milestones. You can’t find a true co-building partner. You end up playing both the technical role and the business analyst role yourself.
Stack these two realities together and the FDE gets squeezed: you show up ready to co-build, but the client evaluates you on delivery. You care about “does this process actually work now?” The client cares about “did you deliver item 3.5 on the requirements doc?”
But there’s an even deeper problem: the person you’re supposed to co-build with probably doesn’t want you there at all.
Let’s trace the buying chain. Who pays for the FDE? The boss. But is the boss the one with real requirements? No. He won’t sit down with you to walk through business processes. He says one thing: “I want to use AI to transform my organization.” Then he assigns you a point of contact — typically a department head or middle manager.
This person is your supposed co-building partner. Now put yourself in his shoes. What does your arrival mean for him?
First, more work. His job used to be writing requirements and managing a vendor’s delivery. Now he has to sit with you, map processes, define problems, iterate. The more thorough you are, the more of his time you consume.
Second, risk. After you co-build and the process is automated, what about him? Is his position still valuable? Could he be replaced? You say “we’re here to make you more efficient.” He hears: “we’re here to make you replaceable.”
Third, the comparison. Before you showed up, he could just allocate budget to an outsourcing firm — clear requirements, straightforward delivery, simple acceptance, and if something went wrong, he could point at the vendor. Your presence breaks the rules he’s comfortable with. Are you empowerment or threat? The answer usually depends on whether you’ve even seen his actual situation.
So in Chinese organizations, co-building isn’t a technical problem. It’s not even a procurement culture problem. It’s an interest problem. The person you imagine as your co-builder is actually your stakeholder — and your highest-priority one. Fail to handle him, and Collision 1 and Collision 2 will detonate simultaneously.
Don’t try to re-educate clients about procurement culture. You can’t undo thirty years of inertia. What you can do is break co-building into verifiable short cycles — two-week milestones, each with concrete deliverables. Use deliverables to earn trust, use trust to earn space for the next co-building cycle. But before any of that, answer one question: why would your assigned point of contact want to cooperate with you? If you can’t answer that, nothing else matters.
Collision 2: You think you’re empowering — you’re actually redistributing power
An FDE shows up thinking “I’m here to help deploy AI.” Inside the organization, everything you touch is actually a redistribution of power and interests. Automating approval workflows threatens approval authority. Connecting data systems threatens data ownership. Agents replacing manual work threaten job value. Direct reporting lines to the boss threaten middle management’s information asymmetry premium.
But there’s a problem deeper than “whose cake are you taking”: as an external role, you have zero authority to redistribute anything. You see the conflicts in the interest structure, but you have no organizational mandate to resolve them. You’re not the CIO, not the HR VP, not a department head. You’re the engineer they hired.
This is why so many FDE projects die in a particular kind of silence: nobody openly opposes you, but nobody truly cooperates either. Data access drags on for a month “going through approvals.” Requirements reviews can never get everyone in the same room. During acceptance, historical issues suddenly surface out of nowhere. Most of the time, these aren’t technical problems. You’ve stepped on someone’s core interest, and they’ve chosen to let you fail by doing nothing.
Faced with this, the FDE has exactly two cards to play:
First card: the stakeholder map. Your first week on-site, don’t look at the code. Map the people. Who initiated this project? Who signs off? Who will actually use it? Who gets replaced? Whose data gets taken away? Whose information advantage gets disrupted? Draw the interest structure clearly, and only then can you identify allies, neutrals, and potential resistance — and the right strategy for each.
Second card: the top leader. There’s no way around this. Redistributing interests cannot be done by an external engineer. It can only be driven by the highest authority inside the organization. If you don’t have genuine backing from the project’s decision-maker — not verbal support, but someone who will step in and take the hit for you when things get hard — then you’re not driving transformation. You’re just a technical advisor who can be sacrificed at any moment.
Lack either card, and Collision 2 is most likely unsolvable.
Collision 3: You thought you’d be tuning models. You don’t even know where the data is.
The least glamorous of the three — and the one that drains you the most.
When AI circles discuss FDE, the conversation is always about model selection, agent architecture, prompt engineering, evaluation frameworks. The picture painted by Silicon Valley blogs: structured data sitting in data lakes, APIs complete, permissions clear, all you need to do is design the reasoning pipeline. But in China — including mid-size companies with billions in revenue — what you actually see on the ground is something else entirely:
- Core business data isn’t in a unified system. It’s scattered across Excel files, WeChat groups, OA systems, aging ERPs, and some Access database that’s been running for a decade.
- Department systems don’t talk to each other. Each has its own data format, its own account system, its own export mechanism — some don’t even have APIs, and the only way to get data out is manual CSV export.
- Worst of all: a lot of the data you assume must exist simply doesn’t. You want to build a competitive analysis agent? Where’s the competitor data? In an Excel file some marketing colleague manually compiles by scrolling Xiaohongshu and Douyin every day. You want to optimize supply chains? Historical supplier delivery data is scattered across procurement staff’s WeChat histories — never structured, never consolidated.
This is the reality for a huge number of Chinese enterprises: the IT debt is still unpaid, the digital transformation ledger is already open, and here come the AI demands. Many people have never experienced real enterprise operations — they assume data is naturally accessible and structured. In the field, what you face isn’t “how do I tune the model,” but “where does the data live, what form is it in, how do I get it out, and is it usable once I do?”
More ironic: this problem is rarely discussed seriously in technical circles. You won’t find a chapter in agent framework blogs about “how to ingest business data from Excel files and WeChat messages.” Yet on the real battlefield, an FDE likely spends 60-80% of their time on data acquisition, data cleaning, and system integration. Actually writing model code and prompts is the minority.
In China, your core competence as an FDE isn’t just model capability — it’s data engineering capability. Can you rapidly map an enterprise’s data landscape? Can you design a minimum viable approach under conditions of data incompleteness? Can you make an agent deliver visible value without an ideal data infrastructure?
This loops back to Collision 1: the client wants delivery certainty, and you don’t even know where the data is. When both hit at once, your project will likely turn into an endless data governance exercise — while you were hired to do AI.
There aren’t many solutions, but one is practical: do a data reconnaissance before doing a solution pitch. Don’t walk in telling the client which model or architecture you’ll use. First ask: where is the data for this process? Can I see it? What does the first real dataset actually look like? Put the data reality on the table. Write the data work timeline into the first section of your project plan. If the client won’t accept this precondition, every AI promise that follows is empty.
Three collisions, done. They’re not isolated — the client wants certainty (Collision 1), you need consensus within a hostile interest structure (Collision 2), and the prerequisite for consensus — data transparency and system interoperability — is exactly what’s missing (Collision 3). These three lock each other in place.
In China’s market, FDE has never been just an engineering role. It’s fundamentally three jobs: stringing together fragmented systems, smoothing friction between departments, and digging data out of Excel files and WeChat histories. Miss one capability, and you’ll get stuck on the corresponding collision. Miss two, and your project almost certainly dies mid-flight.