Why China Plays by Different Rules

The map is not the territory.

— Alfred Korzybski

Start with two people doing the same FDE job, and look at where a day's working hours actually go.

The first comes from Silicon Valley. An FDE at a model-platform company spends about 75% of his time on software engineering and model optimization, with consulting and customer relationships splitting the rest (the detailed time ledger is in Chapter 1).¹

The second comes from China. A consultant doing enterprise AI adoption inside China ran the same accounting: roughly 60% of his time goes to helping customers untangle business problems, or simply to building relationships — maintaining connections, chatting, dining out, digging for requirements. Technology gets the small sliver that's left.²

Put the two side by side, and the point isn't which is better. It's that the same job title, FDE, is two different jobs in two different markets.

The Silicon Valley FDE assumes a world that is already in place — requirements are clear, data is online, the payment mechanisms are mature — so three-quarters of his time can naturally go into engineering. The practitioner in China faces a different world: requirements get dug out over dinner, data gets hand-copied out of notebooks, payment gets counted by head. Transplant the Silicon Valley playbook unchanged, and the more faithfully you copy it, the faster you die.

This chapter takes up three questions: which structures the differences actually sit in, how the playbook has to change, and what native forms the Chinese market has grown of its own.

I. Different Structure, Different Playbook

The difference isn't technology — the model is the same model. The difference is structure, and it comes down to four things (see Figure 18-1).³

Figure 18-1: When the constraints on decisions, the data environment, and organizational adoption differ, FDE's sequence has to adapt too.

First: procurement and budget. The US market accepts subscriptions, usage-based billing, even outcome sharing; the corporate muscle memory of Chinese enterprises is "buy it outright and accept it as a project": annual budgets, project initiation and tendering, acceptance payments in installments. How the playbook adapts: slice the Minimum Viable Deployment into the acceptance milestones that already exist — the acceptance contract from Chapter 8 (business metrics, time window, judgment criteria) happens to look exactly like a project-style acceptance sheet, so push with the current rather than against it. Copy the subscription model as-is, and you die first in the procurement process.

Second: data constraints. "Data never leaves the building" is not a preference for Chinese customers — it is often a hard constraint, especially in state-owned and sensitive industries. How the playbook adapts: the architecture decisions around private and on-premises deployment have to move up into the design phase, not be left to the remediation phase. Field evidence: one team, constrained by budget, cold-started with a locally deployed open-source model plus retrieval — localization under cost constraints isn't a China-specific sideshow; it's the norm.⁴

Third: payment habits. Paying by the day is a market that has been mature for a century; paying for results has no line item in the procurement catalog. How the playbook adapts: the education cost of outcome-based pricing has to be built into your pricing (Chapter 20 covers how to run that calculation), or you transition through a hybrid of "stage acceptance plus value metrics written into the contract."

Fourth: talent supply. For hybrid talent who understand both the business and AI, the market consensus is "they're either expensive or they're not good; most companies have to grow their own."⁵ How the playbook adapts: internal transfers plus on-site practice — the big tech companies routinely move product managers and frontend engineers into forward-deployment roles and send them to customer sites to gather requirements and produce prototypes.

Dig one level beneath the four, and there's a shared foundation problem. Peng Xinyu, CEO of Alibaba Lingyang, whose team serves several hundred to a thousand-plus mid-sized and large customers, offers this judgment: American companies came through their informatization era with companies like Salesforce and SAP, which "laid down many of the workflows and set many of the data standards"; China lacks that layer, and "not one of them has a reasonably stable foundation" — so delivery in China often means "driving piles and raising the building from day one, then doing the interior finishing — the whole string of things has to get done."⁶ This one judgment explains several of this chapter's observations at once: data constraints are tight because the data foundation has to be poured on the spot; relationship-building eats so much of the calendar because there are no standard workflows to lean on, so requirements can only be mined out of relationships; payment recognizes person-days because "every large enterprise in China has an IT team" — pure feature-integration delivery is something the customer could do in-house, so the vendor has to create value beyond the internal team before anyone will pay for it.

II. Who Defines the Last Mile

Above and beyond the four differences hangs a more fundamental question: who defines the last mile?

On the same project, some people think the last mile runs from demo to go-live, while others think it doesn't end until frontline employees actually use the thing — a gap of several times over. Who gets to define the finish line directly decides whether the FDE is doing technical work or wrangling disputes. In the Silicon Valley narrative, the FDE defines that mile himself: he's stationed at the customer's site, watches people work, connects the broken links with his own hands, then carries the experience back to headquarters. In China, that defining right often isn't in the FDE's hands at all.

One real case reported by practitioners: at a state-owned enterprise, the contract was signed by the top boss, but the people executing on the ground couldn't articulate requirements — so they let the FDE find them, propose them, and build them himself. Seven agents got built. Nobody used any of them. The last mile had been stretched into a swamp, because from start to finish nobody ever said clearly where the finish line was. The chain often has middlemen in it too: plenty of domestic projects are taken on by a cloud vendor's resellers, and requirements reach the work site through several layers — each one amplifying and distorting the promises.³

The play for the fight over definition isn't confrontation. It's turning "definition" from something spoken into something written: use the Chapter 8 acceptance contract to put "what does finished look like" onto a single page both parties sign — and the question of who decides where the finish line is becomes a question of what the finish line says in black and white. Until the signature, you're working toward someone else's expectations — ones that don't match your own.

III. Two Soils, Two Logics of Advance

When the structural differences land on a specific customer, another feature of the Chinese market shows up: it runs on two tracks. Private companies and state-owned companies are two entirely different soils.

The private-company logic is "get the thing done." The owner cares about exactly one question: I spend a few million — does revenue go up, or does cost come down? Whether AI is involved, he doesn't care. The play: go straight to the person who signs off, let results do the talking, and don't take detours.

The state-owned logic is "get the people sorted." The contest over authority and accountability inside the organization is ten times more complicated than the technical solution, and fear of making a mistake is the background color. The play: first map out who is responsible and who takes the blame; translate project progress into language your point of contact can carry upstairs and report with — give him material to show for himself, rather than leaping over him and making the decision for the boss; and at the same time, list the small things that can move this week, banking whatever inch you can. One line above all: push the process forward, but never make the final call for someone else — unclear authority and accountability is the customer's own ailment, and you're in no position to operate. Step outside your lane and absorb that responsibility, and if the project dies, the blame is entirely yours.

Mixing the two logics is where things break. One move works on both sides: get in front of the person who signs the contract — the closer to the source, the truer the requirements.³

Ten minutes spent judging the soil before you enter is worth more than three months spent remediating afterward.

IV. Field Observations from the Chinese Ground

The practitioner who described spending "60% of his time on relationships" has three first-hand observations.²

Observation one: build the data first, talk contracts second. "In a lot of under-the-radar businesses, there is no data — customer information lives in a notebook." The Data Contract in Chapter 10 assumes "the customer has data to connect to" — on the ground in China you often have to take one earlier step: first transcribe what's in the notebook into a system, first draw the veteran's in-head process into a diagram. Only then is there a contract to talk about.

Observation two: the last mile jams in the most mundane, unglamorous places. One store customer was still running an old XP machine that couldn't install new software; a fully configured bot "went on strike" one day, and after half a day of digging, the cause turned out to be that someone had switched the computer off. The first technical decision in a deployment plan often isn't which model to pick — it's which year's operating system you need to be compatible with.

Observation three: relationships are infrastructure. Look again at that 60% of time spent on relationships: connections aren't lubricant, they're load-bearing walls — requirements are mined out of relationships, and trust grows across the dinner table (this time cost has to be priced into cost estimates and quotes from the start; Chapter 27's deal screening and pricing will put it to work). Where your trust comes from — the endorsement of a major company, past cases, a personal brand, or referral by people who know you — directly determines what kind of practitioner you are.

Xiaopeng Lu is one of the very few who has done FDE work on the ground on both sides — in the US he founded a company doing North American healthcare AI adoption (Ventus AI), and before that he worked back in China for two years, where he saw the domestic version of the role up close. His summary of the domestic customer's state of mind stings: "two or three people tinkering could put something like this together too" — customers will even ask point-blank: "you're giving me two people on the project — why shouldn't I just hire two people myself and manage them?"⁷

That rhetorical question and this chapter's third structural difference (payment habits) are saying the same thing: the Chinese customer assumes by default that an external team is selling "person-days," and if person-days are affordable, there's no reason to outsource. Paying for results, for sustained judgment — that itself requires educating the market first. This isn't Chinese customers being irrational; it's a perception gap between the two markets over "what an external team is actually selling" that hasn't been filled in yet.

Looking at the same question across both the US and China actually makes it easier to see clearly: this isn't one market's defect. Low-teachability complexity — complicated problems that are very hard to hand over for the customer to run themselves — is a line of business that has to clear this exact same first gate in any market where the trust structure isn't yet mature.

V. The Answers from Those Who Went First

The Chinese market is not without its answers. Line up the pioneers with public records, and two clear paths appear: how a service provider productizes itself, and how the big companies turn this into an institution.

Productization for a service provider works the same problem on two levels: first set boundaries, then define stages. One domestic provider in the real-estate and facilities-management industry draws its line against on-site outsourcing in three sentences on its own website: delivery by stage, acceptance by result, not settlement by hours worked; engineering done with a formed product in hand, not written and patched from scratch on site; we leave when it's done, with the capability deposited in the system and in the customer's team, not staying ever longer. It has even built a mechanism for turning away the wrong business — no unvalidated scenarios, no engagements where the data could be exported in a single spreadsheet, no customers who just want to learn about AI. Three sentences plus a set of turn-aways is just about Part Two and Part Four of this book, turned into advertising copy.

Once the boundaries hold, the next step is turning the methodology into replicable stages: one financial-services provider has settled its delivery into three phases — scenario diagnosis, one to two weeks (identify the three to five highest-value scenarios, quantify the return on investment) → embedded delivery, eight to sixteen weeks (from model selection to production integration) → production deployment and continuous evolution (iterating with the business) — while making "data never leaves the domain" explicit.⁸ Notice the structure: the diagnosis phase is Chapter 6's discovery and the five filters, the delivery phase is Chapter 7's Minimum Viable Deployment, the evolution phase is this chapter's after-delivery — the methodology carries straight across; it just grew on China's procurement rhythm.

The big companies take a different road: not persuading customers with boundaries and stages, but with institutionalization itself. Volcano Engine has stood up dedicated FDE teams; its president, in a public interview, described the role in words that nearly match this book's definition verbatim — "not sales, and not pre-sales; they must have a strong ability to land technology in production" — and team members are deliberately staffed with diverse industry backgrounds.⁸ The head of efficiency engineering at the e-commerce company Dewu broke an AI transformation ten thousand people strong into three steps: first, company-wide consensus, lowering the threshold so people actually start using it; then, sorting scenarios into quadrants by tolerance for error, handing the higher-tolerance ones to agents first; and finally, standing up a knowledge-operations group to move experts' tacit experience into space the agents can see — consensus, scenarios, knowledge, in that order and no other.

The deepest sample of institutionalization may be the team led by Peng Xinyu, CEO of Alibaba Lingyang. As the founder of Alibaba's data middle platform methodology, his team was called CSM (customer success) before the word "FDE" became fashionable, and had done it for five years, first serving several hundred to a thousand-plus mid-sized and large customers on the strength of its data-platform business — in his own words: "before the term FDE existed, this is what we were already doing... we've had a team called CSM for five years now."⁶ They have condensed the practice into three principles: oriented by business outcomes (the problem must come with a business goal, business numbers, and historical records, such that an eval set and a metrics system can be built), founded on enterprise data as the base layer, and defaulting to the benchmark performer — the starting persona for an AI customer-service agent is "a rep who has worked the seat for five to ten years."⁶

Down to the concrete case: the "shipment-chasing" after-sales flow at a consumer-electronics customer came apart into more than 260 steps — three kinds of chasing (a whole unit under-shipped, an accessory missing, a gift not yet arrived), internal and external systems tangled together and spanning JD, Tmall, and several other platforms, covering over 95% of scenarios; meanwhile the human agents answering today respond "on the order of hours or days," and customers who can't wait simply cancel the order.⁶ They also give a copy-ready three-question standard for choosing scenarios: where is the most people-time burned (phone calls made and taken, complaints handled), where the most money (payouts and loss control, marketing spend), where the most clock time (shipment-chasing inquiries) — those three questions are saying almost exactly what Chapter 6's value-density filter says. Organizationally, their answer is "our approach isn't one person, it's an organization": business analysts oriented by business outcomes (industry experts in beauty, appliances, automotive — responsible for orchestrating the workflow and setting the evaluation standards), AI architects (translating business problems into which model to use and which steps a human intervenes in versus which the machine takes over), and a coaching team drawn from the customer's own best service reps and salespeople — speaking directly to Chapter 24's capability model and Chapter 26's team building.

Behind all of these answers presses one shared financial fact: in their 2025 annual reports, Yonyou's revenue per employee was about 480,000 yuan and Kingdee's about 620,000; in the same year, Palantir's revenue per employee was about a million US dollars — an order-of-magnitude gap in per-person productivity.⁸ This is what "the curse of the project model" looks like on a financial statement: the big customers demand customization, the vendor loses money on every engagement, the code gets abandoned when the delivery team walks, and the very best engineers are consumed by heavily customized, non-standard delivery. The same set of numbers also contains the Chinese market's biggest upside for this business: whoever rewrites the delivery engineer's output from "person-day" pricing to "results" pricing rewrites, at the same stroke, the market price of hundreds of thousands of people and the financial structure of the business itself.

The demand side deserves a hearing too. A targeted survey of enterprise CIOs put three numbers side by side: 73.3% of the CIOs surveyed endorse the forward-deployment model and are willing to pilot it; at the same time, 60.0% worry that vendors don't understand their industry well enough, and 53.3% believe the market lacks quantifiable proof of input-output return.⁸ Translated into one sentence: the endorsement is real, and so are the reservations — customers aren't hesitating over whether to buy a new job title; they're evaluating an entire value-realization mechanism that hasn't been proven yet. And that list of reservations — industry understanding, quantifiable input-output — is exactly what this book's Chapter 6 and Chapter 8 take up.

VI. Two Native Forms

Under these structural constraints, forward deployment in China has grown two forms of its own — both differ from the Silicon Valley original's responsibility structure, and both genuinely run inside their own structure.

Form one: the big-company on-site prototype engineer. As a frontline practitioner in the community describes it: the company sends product-plus-frontend engineers "rolled into one" to the customer's site to gather requirements and produce prototypes on the spot with AI — frontend pages on pure demo data, revised on-site to the customer's requests; once requirements are settled, they go back to the in-house backend developers for implementation and integration.⁵ Run it against the three tests from Chapter 2, and it covers the "discovery + prototype" stretch of the spectrum — production and the feedback loop live somewhere else. Under China's procurement structure (reseller layers in between, vague requirements, acceptance-driven sign-off), this is a rational division of labor — the prototype is the fastest lever for prying a requirements confirmation out of the customer, and it happens to route around the fights over who defines the last mile: put the prototype on the table, revise it three rounds, and the requirements have defined themselves.

Form two: the independent FDE and independent service providers. In another community practitioner's own account: three years building custom agents, most of it taking orders online, with a self-built case library and reusable modules — but "work for yourself and you have no endorsement; work for someone else and it's misery."⁹ That sentence puts its finger on the two real constraints of the independent form: the credibility cost of personal endorsement (no big-company halo to open the first door for you), and the incentive drain of the employment form. Its mature shape is the "enterprise AI adoption services" business run by people whose main axis is consulting and sales ability, focused on mid-sized companies, replicating a case library up and down one industry — engineering ranks third, behind consulting and sales. It isn't that engineering doesn't matter; it's that in the Chinese market, digging out a problem worth solving and closing the deal are scarcer than standing up the system.² Chapter 27 develops this form in full (whether an individual can do FDE independently).

Put the two forms back against the responsibilities from Chapter 1, and the conclusion is this: the Chinese sample is generally narrower than the Silicon Valley original — but "narrower" doesn't mean "wrong." Form is a function of constraint: if the procurement structure means the only requirements that reach you are prototype requests, then take the prototype to its highest polish; if the trust structure requires relationship-building first, then turn relationship-building itself into a methodology. Before judging any form better or worse, see clearly which constraint it is answering.

VII. A Stress Test Under Tighter Constraints

On that premise, this chapter's conclusion comes in three sentences.

First: the Chinese market isn't FDE at lower specs — it's a different way of surviving, forced out by a different set of constraints. The procurement structure means you can often only start with a prototype; the trust structure means that without a big-company endorsement, you accumulate through relationships and cases, bit by bit. The on-site prototype engineer and the independent FDE are not "settling for second best" — they are plays that can stand upright under the constraints each of them actually faces.

Second: China's constraints aren't "one more item" — they're "tighter." The procurement rules, the state of the data, the payment habits, who owns the definition of done, the investment in relationships — everything this chapter has walked through adds up to one sentence: the same thing takes several more passes of work in China before it holds up. The methods in Part Two and Part Four are bonus points in a market with loose constraints; under constraints this tight, they are mandatory questions you can die for leaving unanswered.

Third, and to every reader: treat the Chinese sample as a stress test. If a delivery method still holds under the constraints of the Chinese ground — still finds problems worth solving, still pulls the acceptance criteria into a defensible definition, still manages to exit cleanly — then in markets with looser constraints, it will very likely hold even better.

Organization, adoption, handoff — all discussed. But hanging above all of it is a more fundamental question: with a delivery burden this heavy, does this business actually hold up as a business model? Part Five runs the numbers.

---

Footnotes

1. Baseten, "What I Learned as a Forward-Deployed Engineer Working at an AI Startup" (Het Trivedi) ↩

2. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩ ↩² ↩³

3. "100 Questions About FDE" (open-source ebook) ↩ ↩² ↩³

4. "AI Job Sense: Stop the Agent Rat Race" ↩

5. "Anyone Out There Actually Doing FDE Work?" (linux.do thread) ↩ ↩²

6. Silicon Valley 101, Episode 248: "China-Style FDE, with Alibaba Lingyang's Peng Xinyu" ↩ ↩² ↩³ ↩⁴

7. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩

8. Fan Bing, Forward Deployed Engineer (FDE) (XDash open-source book) ↩ ↩² ↩³ ↩⁴

9. "Doing FDE Work in Wuhan, Looking for a Partner" (linux.do thread) ↩