Part Four · Landing
Chapter 12
The Chinese-Style FDE: Driving Piles and Doing the Renovation at the Same Time
Facing Chinese enterprises with uneven foundations and complex systems, the FDE must both shore up the data and engineering groundwork and deliver business results quickly. This chapter discusses the balance between reuse and on-site work.
A team walks into a customer site with an AI application, originally planning two weeks for data integration and two weeks for launch.
On day one, they discover that three branch offices use inconsistent customer codes; key approvals are still completed in chat apps; the legacy system has no interfaces and can only export files; and there is no clear answer on who can approve write-backs to production.
Before the application has even started being built, the project has already turned into data cleaning, process mapping, interface retrofitting, and permission confirmation.
This is not "Chinese companies all lack foundations." Within the same industry, some companies already have stable data platforms and clear processes, while others have only just moved their core business off paper. Even within a large conglomerate, different subsidiaries can seem separated by two eras.
When discussing the Chinese-style FDE, we cannot lazily frame it as "China doesn't have it, America already has it complete." What truly determines the workload is company size, industry constraints, software foundations, and organizational maturity.
Some need the model; some need the foundation first
A company with a high share of online business and well-built interfaces may quickly plug the model into its existing workflows. Data is generated in real time, and actions happen inside software, so the FDE's main work is defining use cases, controlling risk, and validating adoption.
A manufacturing company's key facts may be scattered across ERP, MES, equipment records, and shift-team experience. Before the system can give production scheduling or equipment disposal recommendations, it must first solve whether codes, timestamps, and statuses can be aligned.
A regional service company may not even have stable records of certain processes. Deploying an AI agent directly in this case means the system can only guess at reality from scattered files and chat logs.
Guidance documents from the Ministry of Industry and Information Technology on SME digital transformation specifically emphasize differences in foundations, differences in needs, and phased advancement, and also encourage lightweight, subscription-based products and end-to-end accompaniment services. Such policy language is deliberately restrained: there is no single roadmap on which all companies start running at the same time.
So there is nothing shameful about an FDE shoring up some groundwork first upon arriving on site.
The question is how much to shore up.
If a claims-assistance project must first rebuild customer master data, overhaul all approvals, and replace core systems, the original use case cannot bear that cost. The team must either narrow the scope of action or admit that the customer is not ready for this yet.
"Being able to do everything" is not a sign of capability—it may also be a refusal to do the math.
The cost of driving piles and renovating at the same time
Traditional projects usually build the foundational platform and the upper-layer applications in separate phases. AI projects pursue quick wins, and customers are unwilling to wait two years, so the FDE is asked to do two things at once: finish a visible room while also patching the foundation underneath.
This creates three kinds of pressure.
First, timelines spiral out of control. Every field you connect may pull in legacy systems and conflicting departmental definitions behind it.
Second, responsibility loses focus. The original goal was to solve one work problem; later, the project's success depends on company-wide data governance.
Third, costs are hard to reuse. The customer sees an application, but the team has invested heavily in one-off on-site adaptation.
The FDE's value was supposed to lie in shortening the distance between the problem and the product. If they spend every day manually moving files, fixing one-off interfaces, and chasing approval stamps, the role degenerates into an on-site team that is faster-reacting but more expensive.
This is not to say on-site grunt work should never be done. Some temporary scaffolding exists to validate value as quickly as possible, which is entirely reasonable. The dividing line is: does the team know it is scaffolding, has it agreed on when to tear it down, and does it consolidate the recurring parts?
Which differences should stay on site
The customer will not turn into the same company as every other customer.
Industry regulation differs, organizational authority differs, legacy systems differ, and risk appetites differ. Trying to eliminate all differences will only produce an abstract product that satisfies no one.
What should stay on site is usually the customer's unique business rules, allocation of responsibility, process rhythm, and change management. For example, who can approve a special payout, or which level of personnel takes over a production anomaly—these decisions cannot be made by the vendor on the customer's behalf.
What must be reused are the technical and methodological assets that recur again and again:
- Connectors and data mapping approaches for common systems;
- Eval set structures covering typical errors, edge cases, and attacks;
- Industry templates for objects, states, actions, and permissions;
- Control strategies such as limits, approvals, circuit breakers, and replay;
- Delivery playbooks from problem discovery to production adoption.
Reuse is not copying the previous customer's configuration over. It is keeping the "why we did it this way" and extracting the customer-specific values.
For example, two manufacturing companies' inventory codes will never be identical, but when identifying available inventory, both must distinguish book quantity, frozen quantity, and committed quantity. The specific fields belong on site; this set of questions can go into an industry template.
What to distill from a single customization
One retrospective at the end of a project is not enough.
The team needs to take the deliverables apart and examine them.
Which code only serves the customer's legacy systems, and which can become a universal connection layer; which prompts depend on individual skill, and which business judgments should become rules or model behavior; which exceptions will be encountered again and can go into the eval set; which approvals were purely ad hoc coordination, and which should become product capabilities.
This step is often squeezed out by sales pressure. One customer has just gone live, the next is already on site, and the fastest approach is to clone a team rather than distill a product.
The project model thus has strong inertia: revenue tracks person-days, the organization rewards firefighting, and the most capable people stay bound long-term to the hardest customers. Every delivery succeeds, and every delivery feels like the first.
Whether the FDE can be the antidote to the project model depends on whether there is a genuine feedback loop between product and service.
The field discovers problems, and the product absorbs the commonalities; the product carries more of the commonalities, and only then does the field team have the bandwidth to tackle new hard problems. If only the first half holds, the FDE is just custom development carrying AI tools.
Stay close to the field, but also know how to say no
The Chinese-style field often interprets "taking responsibility" as going one step further.
No one will build the interface, so the FDE builds it; no one will define the definitions, so the FDE helps define them; no one will coordinate the business side, so the FDE chases them down. In early projects, this kind of initiative is precious—it can get something moving that would otherwise be stuck forever.
But going one step further cannot become walking the customer's path forever.
Business rules need confirmation from the customer's accountable owner; production permissions must have explicit authorization; and when foundational retrofitting exceeds the use case's benefit, it should stop. Refusing unreasonable customization is not about lecturing the customer from a product manager's stance—it is about laying out the long-term costs openly.
Sometimes the best solution is to step down one level: make recommendations first, not automatic write-backs; cover one branch first, not unify the whole group; solve the high-frequency, well-evidenced parts first, and leave extreme exceptions to humans.
This restraint is harder to sell than "end-to-end intelligent automation," but it is closer to real delivery.
Will the FDE eventually disappear?
If a problem becomes standardized enough—connectors, models, controls, and delivery processes all mature—will FDEs still be needed?
Perhaps not as many.
The mature parts will move into the product, and the field role will shift toward more complex problems. Excellent FDEs may also turn the pain points they repeatedly encounter into their own products and companies.
But companies will not stop being different from one another, and technology will not stop changing. As long as new capabilities must enter old organizations, someone will still be needed at the boundary who understands both software and business.
Whether that role keeps the name FDE doesn't really matter.
The opportunity for the Chinese-style FDE comes from a vast and unevenly digitalized landscape; its barrier to entry is not the ability to stay up later or stay on site longer, but the ability to stay close to the field while preventing every difference from hardening into permanent customization.
At this point in the book, the assets and debts left by generations of technology are all on the table. The final question to answer is no longer whether this role will be hot, but what those who have walked the old road should take with them—and what they should leave in the past.
Chapter references
- Ministry of Industry and Information Technology: Policy interpretation of the "Guide to Digital Transformation for SMEs"
- Ministry of Industry and Information Technology: SME digital transformation city pilot program
- China Academy of Information and Communications Technology: "Research Report on SME Digital Transformation Development (2024)"
- OpenAI: Forward Deployed Engineer job description
Scenario note: The opening scenario and the manufacturing, claims, and other situations in this chapter are composite representations of common delivery problems and do not correspond to any specific customer.
This page is synced with the chapter Markdown on GitHub. Corrections are welcome.