Douban's R&D Management Philosophy: Constraints, Rules, and Incentive Mechanisms

Overview

Douban's R&D management philosophy is built on a set of constraints and rules, where constraints are fundamental and rules are derived from them. The three basic constraints are: (1) the final evaluation standard depends on contribution to the product line; (2) work must be done in the right way; (3) there must be technical goals.

The first point is essentially a performance recognition principle—what counts as performance? 1,000 lines of code is not performance; the value delivered is.

The second point rejects low‑quality code; good engineers naturally have a sense of quality.

The third point requires members to pursue technical excellence. If a hire treats work merely as a task without passion for improving their own skills, even a technically strong person would be rejected.

Based on these constraints, a series of rules are created, which in turn generate further rules, and each team may also develop its own internal rules.

For example, all code must be reviewable—a general rule that requires tooling support, which was the original purpose of developing the CODE platform. Code review is a relatively autonomous process, not top‑down nor bottom‑up. Typically, each team has one or two “code‑cleanliness” enthusiasts who act as the low‑quality code detectors.

After establishing the CODE platform, other rules emerged, such as running CI before merging, branch‑creation policies, and commit guidelines, all supported by tools.

Teams may also define their own rules for division of labor between PMs and engineers. Some teams allocate 20 % of time to non‑feature work, focusing on long‑term value like paying down technical debt. Others negotiate the distribution of invisible work each sprint. These practices stem from the team's technical aspirations.

Overall, constraints remain constant while rules can be adjusted.

How Rules Are Formulated

According to the book *Management 3.0*, good managers are not rule‑makers. Teams are encouraged to democratically create their own rules, with managers intervening minimally. Early in a team's life, managers may set some initial rules, but these are quickly replaced by rules generated internally.

Managers may be tempted to design rules like a game, but this is neither possible nor desirable. Emphasis should be on constraints, defining the boundaries of rules, and ensuring no conflict between them.

Some companies value employee consistency, especially ideological consistency, which the author rejects as meaningless. Consensus has three levels: vision (what should or should not be done), values (how things should be done), and rules & constraints (behavioural level). Rules are easily copied, such as using pull‑request workflows, which reinforces values.

The author prefers behavioural consistency over ideological uniformity. Rule creation should be democratic, involving conflict, compromise, and negotiation; once established, everyone follows them.

How to Motivate Cross‑Team Collaboration and Sharing

In Douban's early days with only about 20 people, tasks were posted in a public pool on Trac, and engineers chose what interested them. After 2009, the organization shifted to product‑line structures to improve ownership and responsiveness, which limited horizontal connections and knowledge sharing.

To address this, the company first created a public pool for showcasing individual achievements, but results were modest. The current focus is on performance rules that allow cross‑team contributions to be recognized by Douban's performance system, which has shown better alignment.

Incentive Mechanisms

The use of incentives is approached cautiously. While acknowledging contributions is important, over‑incentivising can corrupt intrinsic motivation, turning voluntary actions into reward‑driven behaviour.

For example, an employee voluntarily cleaned up unused database data, dramatically improving query speed. Giving a cash bonus might shift motivation. The team considered a points system for sharing, but feared it would turn internal drive into external drive and create “cherry‑picking” of tasks.

The author believes bonuses and salary should follow performance evaluation rather than be tied to specific events. Immediate, non‑monetary incentives—such as CODE badges—recognize effort, are visible to others, and avoid harming intrinsic drive.

Evaluation focuses on two basics: face‑to‑face assessment with the tech lead, and transparency—evaluation criteria are public. Evaluations occur semi‑annually, involving several tech leads discussing each engineer. The author participates in all evaluations for a team of over 130 engineers and hopes the process will evolve into a committee model.

However, performance evaluation is not the most important part; goal setting and regular check‑ins are. Management should treat the team as a system, aligning goals and constraints, enabling teams to create their own rules that harmonize with objectives. Managers should limit themselves to incentive mechanisms and avoid micromanaging task allocation.

Many management theories focus on isolated aspects like KPI or bonuses, often conflicting because they ignore the whole organization. The author recommends two books: *Management 3.0* for a solid framework and *Complex* by Melanie Mitchell for fundamentals of complex systems, with additional reading from Hou Shida for deeper insight.

Disclaimer: The content is sourced from public internet channels. The author remains neutral and provides it for reference and discussion only. Copyright belongs to the original author or institution; please contact for removal if infringed.