After the FDE enters the enterprise: who puts out fires, who bears the responsibility, and who makes the money?

"I think 80% of programmers wouldn't enjoy this kind of work, because it really means long stretches of business travel," said Cao Jiang, co-founder and CTO of Sensors Data, when discussing FDEs.

Being "on-site" is the source of an FDE's value, but this way of working is anything but glamorous. To incubate the OmniGrowth product inside Sensors Data, Cao Jiang and his team traveled extensively for long periods, holding repeated discussions with client executives, technical leads, and business owners, and even sitting right next to front-line "operators," eating and working together. At first, they couldn't even understand much of the clients' business jargon, so they had to treat themselves as interns and go through business training all over again—first learning how clients work, and only then talking about how AI could transform that work. (For more on delivering FDE projects, click to see Cao Jiang's written column series and video course on GeekTime.)

The same trend is happening at Baidu Intelligent Cloud's FDE team. He Zhenjiang, head of Baidu Cloud's service delivery team, leads an FDE team that spends roughly 50%-60% of its working time on business travel. "Travel isn't the goal, but it's often a necessary condition," he said. Once requirements are misunderstood, much of the work that follows goes to waste.

He Zhenjiang's team emphasizes "short, fast, and lean" in daily work: in the morning, they spend an hour or two communicating with the client to quickly understand the business scenario and pain points, then rapidly translate vague requirements into requirement documents that AI can understand, and by the afternoon they produce a first-draft Demo to show the client directly.

The core of this FDE wave is not a change of workplace. What really matters is that once AI products enter enterprises, the traditional boundaries between pre-sales, product, R&D, delivery, and after-sales are all being compressed and redefined.

Multitasking, constant firefighting, and "translation"

He Zhenjiang sums up the FDE's daily state with three keywords: multitasking, constant firefighting, and "translation."

During the project evaluation phase, one FDE may follow three or four projects in parallel; once deep delivery begins after signing, two projects are often already close to the limit. It's not uncommon for FDEs to have four or five meetings a day, but these aren't routine status updates—they're business architecture confirmations, technical selection reviews, and risk alignments, and every one of them must push the client toward concrete decisions.

Unlike traditional delivery, FDEs often get involved from the pre-sales stage, facing many problems for the first time, so process breakdowns are inevitable—and the FDE's frequent "firefighting" happens at the solution level. A consulting firm can hand over a plan without caring whether it succeeds in implementation; an FDE cannot. What they "rescue" is every gap between plan and implementation—whatever is promised must actually be delivered.

"Translation" is what He Zhenjiang considers the FDE's most core daily work. Here, "translation" means breaking down expressions like the client's "I want intelligence" into concrete questions: which scenario, which model to use, which data to call, what metrics to measure effectiveness, and so on.

This is also one of the most easily confused yet most fundamental differences between FDEs and traditional delivery. A client's stated requirements usually cannot be directly converted into technical tasks. The boss, the IT lead, the business manager, and front-line employees often have completely different answers to "what is the problem": the boss wants an agent, the IT department first worries about system security and stability, the business manager cares about efficiency and results, while front-line employees may believe the existing process isn't at all what management describes.

Therefore, after arranging for a business manager to liaise with the FDE team, some executives repeatedly remind the team "don't just listen to this one manager," because the manager and front-line employees often have inconsistent understandings, pain points, and ways of operating the same process. If one key person's opinion is treated as fact, the resulting system may well be correct in the meeting room but unusable on the business floor.

So the FDE's first task after entering the scene is often not development, but interviewing, observing, probing, and deconstructing. A client may propose dozens of scenarios at once; the FDE cannot accept them all, but must filter out a few MVPs based on feasibility, value, importance, and ROI. He Zhenjiang's team typically spends one to two weeks selecting a few key scenarios; Cao Jiang also emphasizes that the best starting point is usually "the most important problem, one that can be solved end to end, with as narrow a scope as possible."

Next, the Demo becomes an important communication tool. Cao Jiang points out that the value of a Demo is not to get the client to nod, but to enable the client to "say no to it."

He explains that in traditional waterfall projects, after requirements are communicated, the client may not see anything roughly usable for two or three months—and if the direction turns out to be wrong by then, the cost of revision is very high. Now that AI has lowered the cost of prototyping, FDEs can move "being rejected" earlier: quickly build something close to the real workflow, let the user sit beside it and operate it directly, then listen as they point out "that's not how I do it," "this is wrong," "there's actually an approval step here," and so on. These rejections themselves are the most valuable requirements input.

Therefore, being able to understand what the client hasn't said out loud, to convert vague business language into technical structure, and to translate technical constraints back into business options the client can understand and decide on—this is an FDE's harder-to-replicate capability.

Moreover, FDEs are trying to push the endpoint of traditional delivery further back—but pushing the endpoint back also means the FDE cannot withdraw after go-live, and that is one source of the pressure.

The endpoint of traditional delivery is usually fairly clear: system launch, feature acceptance, sign-off, payment. In Cao Jiang's view, the ideal deliverable of an AI system is not a static software version, but a "curve of continuously rising effectiveness." For example, the system's effectiveness at launch might be only 80%, but as models evolve, knowledge improves, user feedback accumulates, and eval sets iterate, effectiveness could rise to 90% or even higher.

This requires the FDE to take on more responsibility in a project than traditional "deployment complete." Before launch, they must handle risks like data privacy, security, compliance, rollback, and model unavailability; after launch, they must gradually hand the system over to the client, help the client truly adopt it, and ultimately enable the client to iterate on their own to some degree. FDEs cannot stay on-site forever, otherwise "client dependence on the individual FDE" will eventually slide back into maintenance and labor outsourcing.

In fact, throughout the whole process, client emotions are also one source of pressure for FDEs. Many AI projects have gone off track or failed, so clients are usually more anxious about AI projects than about traditional ones. Meanwhile, AI scenarios often attract attention from senior executives, so client contacts at the project level are under pressure too, and they pass that pressure on to the FDE. Today's FDEs need emotional intelligence in addition to professional skills: they must both soothe client emotions and maintain professional judgment, without letting the whole project be carried away by emotions.

"High pressure isn't a problem unique to FDEs—it's a problem facing the entire AI delivery industry. Still, if the pressure shows up at the solution design stage, that's always better than an incident occurring after the system goes live," said He Zhenjiang.

When something goes wrong, who is responsible? FDEs must answer this question before the incident

So in practice, if an agent deployed by an FDE goes wrong, who bears the responsibility? The industry's answer is consistent: responsibility cannot be carved up after an incident occurs—it must be designed in from the very start of the project.

He Zhenjiang's team produces a solution proposal during the evaluation phase, listing technical choices, risk points, and responsibility divisions in advance: which parts are the FDE's responsibility, which are the client's, and which require third-party vendors' cooperation; if the FDE recommends Plan A but the client insists on Plan B, decision and risk records must also be kept. If the FDE recommends Plan A and the client insists on Plan B, a decision record is created so that every subsequent adjustment can be traced back to the original basis of judgment—so that professional judgment can form a complete closed loop.

Cao Jiang further breaks down AI system errors: for example, if the system's answer is inaccurate, first determine whether it's a model capability issue or a context issue; if it's a context issue, further distinguish whether the client's data itself is wrong, or whether the data is correct but the FDE made errors when building the knowledge base and context. Different causes correspond to different responsibilities, and this cannot be resolved with a blanket "the vendor covers everything" or "not my problem after acceptance."

Responsibility matrices and contract clauses are only the last line of defense; what matters more is converting the responsibility question into product and technical design. The more complete the mechanisms, the less room there is to argue about "whose fault was it really" after an actual incident.

Especially in heavily regulated scenarios like finance and government/enterprise, this kind of governance capability may even matter more than the number of features. What customers care about is not whether a vendor has 100 features or 90, but who can get approvals, audits, archiving, rollback, and fallback mechanisms clearly in place. In the AI era, governance itself is becoming part of the product, and it is also the ticket for FDEs to enter high-value customer sites.

But is it really FDE, or just "outsourcing"?

The FDE role in China is often the butt of jokes—most of the time it's just outsourcing or pre-sales implementation with a new name. This may not apply to every company, but it reveals a reality: FDE is still at an early stage in China. Many companies are just starting to build teams, and there is no consensus yet on job responsibilities, interview standards, organizational placement, or even business models.

In Cao Jiang's view, whether a team has truly adopted the FDE logic can be judged from three dimensions:

• Performance evaluation. If the role directly carries sales targets and earns sales commissions, it is closer to the pre-sales or sales engineering system. Silicon Valley FDEs, though highly paid, are usually not evaluated on sales figures.
• Whether on-site customer experience can feed back into the product. If the project ends as soon as it's done and the product team doesn't care what happened on site, it still resembles traditional delivery.
• Whether the experience makes the next engagement easier to deliver. If the organization only makes its engineers more skilled without making its platform, product, and knowledge systems stronger, this efficiency gain still has a ceiling.

"Our basic logic for avoiding becoming an outsourcing company is to be clear about which money we won't make." He Zhenjiang also pointed to this: FDEs must work around the company's core products, and cannot do fully product-detached custom development just for service fees. Baidu internally leans toward starting from its own product system—"our logic is that FDEs must work around the company's core products, and cannot do fully product-detached custom development just for service fees."

This matters. The deeper an FDE goes into customer sites, the more likely they are to receive a flood of requests that belong to a single customer. Cao Jiang explained: for example, if ten requirements are discovered on site, seven may be generalizable and three completely non-generalizable—but if those three aren't done, the customer won't buy in, so most likely all ten still have to be completed. Therefore, what truly tests a company is whether it can subsequently use software engineering discipline to isolate generalizable requirements from one-off customizations: which go into the standard product, which are managed through OpenAPI or independent modules, and which can only stay at the project level—without letting a single customer's special requirements pollute the entire codebase and product system.

Therefore, a mature FDE today must serve productization. It allows the company to do deeper scenario adaptation in order to win the first industry benchmark customer, but the common knowledge from these adaptations must flow back into the platform, product, knowledge base, and methodology, so that the marginal delivery cost for subsequent customers keeps falling.

This is the most fundamental difference in incentives between FDE and traditional outsourcing. The outsourcing model can charge by person-day: whatever the customer asks for gets done, and as long as the ticket is completed, revenue is earned regardless of the outcome. But if an FDE is truly accountable for business results, it must have the ability to say "no" to customers. Some requirements, even if the customer is willing to pay, may generate no long-term value and cannot be consolidated into product and capability—the company may still choose not to do them.

China's FDE is heavier and harder than the Silicon Valley version

FDE is not a new role invented by Chinese companies. The model is usually traced back to Palantir, which first proposed it; later, AI-native companies like OpenAI and Anthropic also set up similar roles. But after this model entered China's enterprise services market, the two versions of FDE diverged.

Unlike OpenAI and Anthropic, which prefer seasoned engineers, quite a few newcomers and even interns in China are directly given the FDE title.

Cao Jiang is reserved about this. He noted that OpenAI's FDE roles typically require at least 5 years of engineering or delivery experience, and Anthropic requires at least 4 years. Palantir has started hiring fresh graduates, but on the premise that its product, team, and training mechanisms are already highly mature, and new hires still face real customers and bear real responsibilities. In other words, FDE can hire newcomers, but that doesn't mean there are truly "entry-level responsibilities."

He attributed the rise of newcomer FDEs in China to several possibilities: first, To B profits are limited, making it hard for companies to afford highly paid senior talent; second, some roles are essentially still pre-sales or implementation, just renamed FDE; third, some companies suffer from "premature FDE syndrome"—building an FDE team before the platform has formed a reusable foundation and before they have sufficient understanding of the target industry, ultimately falling back to one-off custom delivery.

The FDEs on He Zhenjiang's team mainly transitioned from internal members familiar with the company's products. The reason is not just talent scarcity, but also that they want FDEs to know their own product system well. A truly product-centric FDE who isn't even familiar with their own product's capabilities and boundaries will find it hard to make quick, reliable judgments on site.

"China's FDE work is more arduous and more complex," said He Zhenjiang.

He gave examples to explain: large government and enterprise customers in China often require private deployment, domestic technology adaptation, security audits, Xinchuang (IT innovation/localization) compliance, and data that cannot leave the domain, plus integration with a large number of internal systems, and the large models being called also require extensive custom fine-tuning. FDEs abroad can advance more around SaaS products and cloud services, while FDEs in China often also have to solve problems left behind by local infrastructure and legacy systems at the same time.

This makes "interface failures" and "missing SOPs" the norm. Traditional software delivery can proceed along mature processes, but FDEs are often doing things neither the company nor the customer has done before. For example, the original design might be to fully automatically call the customer's office system, only to discover on site that security requirements don't allow it; the plan might be to directly call a certain system interface, but after actually entering the intranet, the interface turns out to be incomplete, permissions can't be obtained, or there isn't even a unified data standard.

Therefore, the capability requirements for the FDE role in China may not be lower than in Silicon Valley—instead, they may be more varied and heavier.

"FDE is not a panacea." This is the boundary the interviewees repeatedly emphasized.

He Zhenjiang's team conducts an assessment before an FDE enters the site. If there is no one within the customer's organization who can provide business context, participate in solution discussions, and drive internal coordination, then no matter how capable the FDE is, they may end up "outputting into thin air." If the customer's organization is undergoing drastic restructuring, business staff resist AI, or even the real decision-makers haven't reached consensus, the timing of the project may not be ripe.

The second type of problem is technical debt. Some large enterprises have long accumulated complex ERP, CRM, office systems, and many in-house systems; systems from different vendors are coupled with each other, data governance is weak, and infrastructure has fallen behind. Such situations are not uncommon. An FDE can propose a phased governance roadmap, but if the customer hopes to smooth over all historical problems at once with AI, the gap between that reality and expectation is not something an FDE can fill.

The third type is a severe mismatch between budget and expectations. The customer may want to implement dozens of scenarios simultaneously, but the budget only covers a small portion of them. An FDE can help prioritize, but cannot "create something from nothing." If the customer insists on having everything while refusing to accept budget realities, business/commercial intervention will eventually be needed, or the project may even be strategically abandoned.

Cao Jiang's judgment framework is broadly similar. Before taking an order, you need to answer: does the customer have a truly influential internal champion? Are they willing to open real data and necessary permissions? Is the feedback loop short enough? Who pays for the uncertainty of exploration? If none of these conditions can be met, the safest choice may not be to force the use of FDE, but to return to the traditional delivery model.

It can be seen that FDE requires not just "satisfying the customer," but also the ability to refuse the customer. In the traditional client-vendor relationship, the vendor is often expected to execute according to instructions, whereas the FDE model requires both parties to jointly judge what is worth doing. If the customer insists on a strong-arm traditional procurement relationship, does not allow the vendor to participate in business judgment, and is unwilling to provide context, it is hard for FDE to deliver value.

This is also why AI implementation is often called a "top-leadership project." An FDE can fill gaps in technical and product capabilities, but cannot carry out the organizational transformation on the customer's behalf. Without internal champions, data access, and fast feedback, even the strongest engineers can hardly conjure business results out of thin air.

No "lock-in" of people, and no "lock-in" of models

When a vendor's FDE spends long periods deep inside a customer's systems, data, and workflows, a new question arises: does this create stronger vendor lock-in than the model itself?

He Zhenjiang candidly acknowledged that the cost of switching FDE vendors is often high, because what gets replaced is not just a product but a long-term partner who deeply understands the customer's business. The communication, judgment, hard-won lessons, and decision-making built up over years between the two sides cannot necessarily all be captured as structured data. Once a new vendor comes in, the customer has to re-explain past business context, failed experiments, constraints, and how value was created.

Cao Jiang's view is similar. In his opinion, everyone can use the same foundation models, and there are few secrets in common engineering tech stacks; what is truly hard to replicate is business insight, plus the operating mechanism for finding real problems, solving them, and continuously delivering results. A vendor's core competitiveness lies not in a particular model or piece of code, but in how it builds the capability to produce products and code, including working methods and long-accumulated business understanding.

Take Palantir, for example. It is often cited as the representative of this model, but Palantir's competitive moat comes not only from the software itself, but also from its FDE working mechanism and the ontology and industry knowledge built around business objects. Many companies can learn to "send engineers to the customer site," but find it very hard to replicate the organizational feedback loops Palantir has built over twenty years.

This means the commercial moat created by FDEs may be deeper than simply selling models. Once a vendor, through its FDEs, masters a customer's most core business processes and keeps converting that knowledge into product capabilities, industry templates, and organizational knowledge, competition shifts from "whose model is stronger" to "who understands this customer better, who understands this industry better."

Of course, this accumulation of knowledge must have clear data boundaries. Cao Jiang stressed that real customer data cannot be taken away, customer proprietary knowledge must be strictly protected, and the only thing that can truly be reused is anonymized, industry-general knowledge.

It is worth noting that this accumulation of experience will not produce an "irreplaceable FDE"; rather, it settles into capabilities the company can reuse. What customers ultimately trust is not a particular FDE engineer, but the vendor's system for continuously understanding the business, solving problems, and delivering results reliably.

Today, He Zhenjiang's team is trying to use agents to re-automate part of the after-sales workload. Their original after-sales team turned years of operations experience and problem-handling paths into an after-sales service agent; once deployed in customer environments, it can automatically detect, troubleshoot, and even resolve some common issues. Reportedly, such agents can currently relieve on-site FDEs of about 70%–80% of common operations issues, with deeper, less familiar problems passed to second-line specialist engineers in the back office.

FDEs spanning multiple roles does not mean a company should really make one person do everyone's job. On the contrary, the back of the organization still needs senior specialists in project management, testing, deployment, operations, security, and so on—it is just that these capabilities are increasingly being packaged into tools, agents, and the like, which frontline FDEs can call directly. The long collaboration chains once built to ensure professional specialization are being compressed by AI into fewer people and shorter feedback paths.

He Zhenjiang calls this organizational capability the "arsenal" behind building "super individuals." If an FDE is unfamiliar with project management, the organization can provide a project management agent; if they are not good at automated testing, they can call testing tools; if a deployment issue arises on site, a deployment agent can handle it first. The industry knowledge, business processes, solutions, and hard-won lessons from projects must also go into the organizational knowledge base, so that subsequent FDEs can quickly generate solution proposals, requirement sheets, and development design checklists.

Early-stage "losses" are becoming a deliberate investment

If you spend large amounts of time on-site and invest headcount at the pre-sales stage, can the project actually make money? This is a question the FDE must face once it moves from a job concept to a scalable business model.

He Zhenjiang compares an FDE to "planting a fruit tree." In the first year you buy the sapling, water it, and fertilize it, and it may not bear fruit immediately—but you cannot conclude from that that the whole tree is a loss. From the third year on, it bears fruit every year, and can even yield new saplings. The logic is similar for FDEs investing early at the pre-sales stage: costs occur earlier, while returns come from subsequent contract signings, continued purchases, renewals, and improved delivery success rates.

As a result, the observation window for FDE project P&L has lengthened. Traditional projects usually start counting delivery costs from the contract, with pre-sales investment relatively controlled; an FDE, however, may spend one or two weeks or even months on scenario validation before formally signing. A large customer may first run a small-scale pilot, then expand to more people and more business lines. For large state-owned enterprise customers, three months from vendor selection to confirmed MVP is not uncommon.

He Zhenjiang believes these investments are not unconditional money-burning; they aim to raise the customer success rate downstream and to solidify industry benchmark scenarios into replicable capabilities. The first customer bears the cost of the 0-to-1 exploration, and the investment is then gradually recouped through 1-to-100 replication. If scenario delivery efficiency keeps improving and customers are willing to pay for real value, FDE project gross margins may even exceed those of traditional delivery.

Cao Jiang reminds us that calculating FDE costs cannot look only at salaries—opportunity cost must also be counted. Suppose three FDEs have direct annual costs of 3 million yuan; that does not mean completing a 3-million-yuan contract breaks even, because those three people simultaneously gave up other projects and R&D opportunities. Whether the first project is worth doing at a loss depends on how big the target market is, whether the project can build industry knowledge, and whether enough replicable customers exist downstream.

In terms of contract size, his rule of thumb is: projects worth a few hundred thousand yuan are better suited to standard products and industry templates; million-yuan projects can justify on-site presence in key scenarios and exploring a "base fee + performance share" model; only larger projects with higher strategic value are suitable for full-lifecycle FDE embedding. But contract value is only a surface-level indicator—if a project helps the company enter a new industry, establish a benchmark, and accumulate key knowledge, it is acceptable even if the first deal itself loses money.

Thus, the FDE economic model inherently depends on two loops: externally, delivering sufficiently good business results again and again; internally, bringing back sufficiently useful knowledge for the company. Only when both loops are turning at once can the expensive early-stage headcount investment truly achieve economies of scale.

Pay-for-results sounds great, but it isn't ready yet

To some extent, the FDE model in China has not yet fully turned profitable. And the "pay-for-results" (RaaS, Result as a Service) model once favored by the industry for FDEs is progressing far below expectations.

He Zhenjiang's team has tried pay-for-performance, but the practical obstacles are hard to overcome. Results require hard metrics, yet the data usually sits in the customer's own systems; at project kickoff, the customer may agree to pay based on a certain metric, but after the project is done, the data definitions may change. So they now prefer to first pick one or two scenarios the customer cares most about and where clear results are easy to demonstrate, quickly prove the value, and then build a hybrid pricing model combining product licenses, per-scenario fees, performance fees, and labor service fees.

Cao Jiang has observed something similar. The market has already seen various attempts, including per-seat subscriptions, fully managed services, and revenue-sharing on business increments.

He explained that in theory RaaS could better align the interests of both buyer and seller, but the biggest resistance comes not entirely from technology, but from procurement systems and trust structures. The procurement systems of banks and other large institutions have long been built around software, person-days, and clearly defined SOWs, and new pricing models struggle to enter existing processes directly. Meanwhile, neither side has enough historical data on how much incremental value agents actually deliver, making precise attribution difficult.

What is more likely to happen in the future is that organizations get re-compressed

After FDEs became hot, many people began defining the role as an "external CTO" or "super engineer," and even more granular new roles such as "Forward Deployed Product Manager" have emerged.

Cao Jiang disagrees with this view. He believes AI is lowering the execution cost of many existing functions, so the organizational trend should be fewer roles and shorter chains, not adding a "Forward Deployed" prefix in front of every old job title. With AI, excellent engineers and business people can already accomplish work that once required collaboration across multiple roles, and the boundaries between product managers, engineers, and designers are themselves shifting.

The practice of He Zhenjiang's team also reflects this trend. After an FDE enters the pre-sales stage, they intersect with SAs; after moving into delivery, they merge with project managers, technical architects, testers, deployment staff, and after-sales operations. But merging does not mean all positions disappear—rather, much of the standardized work is taken over by tools and AI agents, while frontline personnel spend more time on customer judgment, solution design, value validation, and key responsibilities.

SAs are still responsible for the overall product and architecture-level solutions, convincing the customer's senior and mid-level management that the product can realize the vision, and driving bidding and contract signing; FDEs come on-site when a POC or scenario validation is needed, working face-to-face with real business people to turn abstract visions into verifiable results. Product and R&D teams handle the underlying platform and product capabilities, and FDEs feed field problems back to them promptly. Once an industry benchmark scenario has been proven from 0 to 1, there is then an opportunity to hand it over to traditional delivery teams to replicate it from 1 to 100.

Therefore, the likely future trend is: highly standardized, automatable work will gradually be absorbed by tools, while work that requires business judgment, cross-department coordination, taste, decision-making, and accountability will be concentrated onto a small number of frontline roles.

Conclusion

Now, people have returned to the most critical position in AI commercialization. Only this "person" is no longer just a salesperson, nor just a delivery engineer, but an FDE who is expected to simultaneously understand product, business, technology, and organization, and to bear longer-term responsibility for the results.

This is not an easy job. Long-term on-site presence, frequent travel, multiple projects running in parallel, firefighting before launches, customer anxiety, internal collaboration, and continuous learning are all part of the FDE career experience.

He Zhenjiang has also observed that some colleagues under prolonged high pressure show signs of burnout, such as declining attention and losing sensitivity to customer problems. Therefore, the team reduces cognitive load through project rotation: if someone has been in high-intensity projects for several consecutive months or has been stationed long-term in a poor environment, a transition period will be arranged, moving them into relatively eval-oriented projects. On the other hand, as long as each customer's problems remain different, FDEs can keep gaining new learning curves, and this sense of growth becomes part of the role's appeal.

Beyond technical depth and breadth of capability, Cao Jiang believes that what truly determines whether a person is suited to being an FDE long-term is often soft qualities: some people feel drained after a day of communicating with customers, while others draw energy from such interactions.

And in the longer term, the name FDE may not exist forever.

As long as there remains a gap between the boundaries of AI capability and real business needs, there will always be a need for someone to bridge it. The name may change, but the person forced to run back and forth between the business front line and the technical server room, understanding both code and business jargon, will not disappear anytime soon.