Ctrip Lets Operations Rate Architects’ Performance—Can This DRI System Actually Take Off?

Last week, Ctrip rolled out a product-R&D integration system internally. Product, operations, frontend, backend, algorithms, and QA—roles that used to have strict divisions—were broken up and recombined into small teams called DRIs.

DRI stands for Directly Responsible Individual. Apple used it early on, and Silicon Valley companies such as Anthropic have been adapting it. The core idea is to make one person fully accountable for one outcome and smash through the boundaries of functional departments.

The scenes in the pilot groups are somewhat disruptive: operations or product can be the owner and rate senior architects’ performance; backend may report directly to operations; frontend can propose a business requirement and ship it itself, as long as the DRI nods. As departments such as travel, flights, and the content center respond one after another, Ctrip is trying to make everyone both a product manager and a full-stack developer.

In the big-tech processes of the past, this would basically count as a rules violation. China has talked about product-R&D integration for years, but most efforts stopped at connecting frontend, backend, and QA. Nobody touched the turf of product and operations.

The reason they did not dare to move is not complicated. This kind of small closed loop sets an extremely high overall bar for the person in charge. To do product, you need to understand algorithm depth and engineering schedules; to write code, you need to understand user psychology and business aesthetics. Slight imbalance becomes a decision-making disaster.

But the organizational dividend is also direct. In the past, product blamed R&D for slow schedules, R&D complained that product changed requirements, and algorithms complained that operations did not provide data. This classic internal friction fails in a group with the same metric and shared blame. The chain is short enough to leave only one idea and one delivery.

One netizen (AYi) judges that when big companies run this kind of radical experiment, it is the inevitable evolution after the whole industry has been backed into a corner by AI. When the threshold for basic execution and code generation is pressed down to nearly zero, the huge pipelines built on fine division of labor become the most expensive communication tax. Hu Yanbin can demonstrate coding to Tim Cook in person, and a ride-hailing driver can single-handedly crank out over a thousand episodes of animation. In the outside world, the boundaries of one person have already been widened, so there is no need for the high walls between job types inside companies to keep standing.

This judgment aligns with another AYi tweet about Musk’s five-step method.

Musk’s order is: first question the requirement and confirm it is not that stupid; then desperately delete parts and delete processes until it hurts; the third step is to simplify and optimize; then accelerate; finally automate. Most people rush into the last three steps right away.

The fiberglass pad on the Model 3 production line is an example. The pad jammed the entire line. At first people thought about optimizing robots and speeding up the takt time, and after struggling for a long time they turned back to ask what this thing was for. The safety team said it was for noise reduction; the noise-reduction team said it was for fireproofing; they blamed each other. In the end, they removed it and compared, could not hear any difference, and also conveniently bypassed that $2 million robot cell.

The $2 million robot cell itself is not scary. What is scary is that from beginning to end it was carefully serving a pad that nobody needed. This kind of thing is the most expensive in organizations.

Back to Ctrip. The comments are not one-sided.

A netizen (Kiki) worries that laypeople managing specialists and product rating technical performance can easily cause technical architecture to rot. AYi’s response is that there will certainly be a painful period, and Ctrip also emphasizes that it will not impose a one-size-fits-all approach; the key is that technical architecture can no longer exist independently of business outcomes. As delivery tools become more and more idiot-proof, it is a trend that people who can directly take responsibility for the final business outcome gain command.

Someone else (琴.剑.酒) says that small teams taking end-to-end responsibility plus AI is indeed smooth, but the fear is that evaluation is still calculated according to old roles—then it is all wasted effort. Another person (neoragex2025) is more direct: if such small teams can really run, why not a few people leave and do it themselves? Why stay and rely on that boss who offloads risk?

Organizational flattening and special-forces-style teams have another side: they tear down the safe harbor where mediocre employees hide in long chains. From now on, every delivery ticket will carry a living person’s name. If you can do it, you can; if you cannot, there is no way to pass it to upstream or downstream.

Can this system be pushed forward in your company?