Dev management in Douban

Chinese version: https://www.infoq.com/cn/articles/douban-dev-management

English  translated
version: https://www.microsofttranslator.com/BV.aspx?ref=IE8Activity&a=http%3A%2F%2Fwww.infoq.com%2Fcn%2Farticles%2Fdouban-dev-management

 

 

Based with Douban’
Engineering Vice President Duan Nian Wei Zhuang table conversation rather than
into, the two sides mainly discussed how to give the team a set of rules, how
to transmit values, right motivation strategies, how to examine topics such as
engineers.

 

Introduction of guests

Duan Nian, incumbent Douban
Vice President of engineering. Started programming (BASIC) in 80s, individuals
interested in entering the software industry with the support of, successively
serving in companies such as Huawei, new technology, joined Google in China. In
software development, testing, software, team management and other fields are
involved, recently focused on team-building, engineering culture. Interested in
ways to improve team productivity and personal skills.

 

Profile

Douban’ s development
management is based on a set of constraints and rules. Constraints are
fundamental, rules based on constraints to development. We have three basic
constraints:

 

1.Final evaluation
criteria depends on the contribution to product line

2.To do things the right
way

3.Must have technical
objectives

 

1st is arguably performance
recognized principles, that is, what kind of performance can be recognized.
writing 1000 lines of code is not a performance indicate, what value you
bringing is. When you don't have a direct contribution to the business, but increasing
productivity, this is also count.

 

2nd is that we do not accept
low-quality code. Good taste of engineers natural with it.

 

3rd can also say we are
asking members of the pursuit of code. If we are looking for a person, if he
only work as a task, lack of enthusiasm for upgrading their technology itself,
so even if he was again well, we refuse. Such a person might just focus on
performance, rather than focus on smarter, more efficient way of doing things.

 

Based on this three-point
constraints, we have formulated a number of rules, these rules can lead to
other rules, but each team also produce their own set of rules.

 

For example, each code must
to be do code review, this is a general rule. This rule needs the support of
tools, which is why we develop CODE platform in the first place. Our code
review is a process of relative autonomy, not from top to bottom or from bottom
to top. Basically, every team will be formed inside one or two people with code
cleanliness, and they're finding low-quality code for such a role.

 

Code review tasks, under the
CODE platform, derives from other rules, such as in the merge code before you
implement CI, as well as branching rules, submitted to the rules of the code,
and so on. Of course, this also requires tools support. CODE as a platform can
be implemented well to accommodate these rules.

 

Within each team, if your PM
want to decide how to do distributing the task, they may have different rules.
Some teams had created 20% not function development rules, specifically do with
20% time to generate long-term value development, such as debt-repair
technique. Some teams take consultative manner to distribute workloads that are
not visible at a time. These are derived from the team's pursuit of technology.

 

Overall, the constraints are
the same, the rules can be adjusted.

 

how to formulate the rules

 

The management 3.0, this book
says: good managers is not the rules of the game makers. We tend to let the
team his own team rules in a democratic way, I try not to meddle. Of course, in
the early stage of team development, and you can also try to set some rules,
but you will find that these rules will be replaced by new rules arising from
within the team.

 

As managers, we could not
help but to like a game designer to design rules, but this is impossible to
define the rule, we should not do so. We ought to emphasize constraint defines
the boundary rules to ensure no conflict rules with constraints.

 

Some are more attention to
consistency, especially ideological consistency, unity of values, I disagree on
this point. I think the unity of this thing makes no sense. The so-called
consensus, there are generally three levels:

1.Vision: Is "what to do
and what not to do." For example to put ads on the page, it should do it,
everyone will have their own opinions.

2.Value:  Is the
"how to do things," under the vision, reflected by rules and
constraints. I think values is not something pasted on the wall--the mantra on
the wall, are generally less stuff.

3.Rules and restrictions.
That is in practice. Rule is a thing which can easily be copied, such as the
development process, you see everyone with a pull request to submit, you can
easily do so. In this process, the values have been enhanced.

 

For me, I prefer all
consistent in behavior rather than to pursue the thought consistent. Rule
creation process should be democratic, the process requires conflict,
collision, compromises--because our thought is not consistent and rule once it
is established, every individual should abide by the rules.

 

How to encourage
cross-team collaboration and sharing

 

In early time, our company
only have no more than 20 people, was not yet divided into product lines, all
the tasks in a pool, open on the Trac, if you interest one taks, do it by
yourself. Of course, there are some constraints, such as a practice is
"maintains its own code." After year 2009 , in order to solving the
ownership and rapid response to keep small teams, we entered into a product
line approach. In the line mode, engineer's job is relatively fixed, not like I
used to walk a public pool.

 

This horizontal linkages
weakened between engineers, good experience, systems, principles cannot be
shared across product lines, while engineers also are limited to a product line
within a long time may seem boring.

 

So last year, we used a lot
of energy to push cross-team collaboration. First approach is to establish a
common pool, giving individuals more chance of the outcome, but there is no
particularly good results. Now we focus on the performance rules, makes
cross-team's contribution can be recognized by bean performance system,
although they can't say a lot, but compared to last year's attempt is more
suitable for some.

 

Incentive mechanism

 

Our use of incentives very
carefully. On one hand you have to say they saw the employee contribution, care
about the contribution, on the other hand you have incentives to avoid
excessive and cause deterioration, becoming inspired to do spontaneous behavior
is one thing.

 

Last year, we have an
employee voluntarily cleaning up unwanted data in a database, put a lot of
spare time, let the database access speed has been greatly enhanced. So, I
should give him a bonus? Obviously, this is a very valuable and should be
encouraged to contribute, but instant cash rewards are not the best way.
Because the direct cash incentives would likely lead to motivation to change.
And sharing is, we also considered to share a points system, but we're very
concerned that would metamorphose into an internal drive to an external drive –
not the reward, we will not share it? And you set the score, some tasks more
credits, and some tasks less integral, and would lead to "pick"
problem.

 

Incentive balance how can
this thing do? I agree that bonuses and salaries had better go with the
performance appraisal, rather than an event-specific bonuses – would lead to
spontaneous behavior modification is on the one hand, on the other hand is very
likely to be fair. For employees doing good rates incentive is as it should be,
but not necessarily with money. Coat of arms of the CODE system is a good
instant incentive--the coat of arms of saw his effort on my behalf, can also be
displayed for others to see, you can have very good communication without
adverse interference on the internal drive.

 

Assessment systems mainly to
solve how to evaluate engineering problems. Basically, we did not set specific
quantitative targets, primarily two basic points: one is face to face, face to
face with tech lead assessment of every engineer. Another is public, is that
all of the engineer's assessment basis is open to the public. We did an
assessment every six months, and 3 days each time 5 or 6 tech lead, we can
discuss and even PK, all kinds of reasons to have an article. Now all of the
assessments I have participated throughout the development team now, more than
130 people, basically I need everyone, long-term growth in the future, I hope
that the assessment process into the Commission's Forms.

 

However, I think the
assessment of performance evaluation is not the most important part. Evaluation
the most important part of goal-setting and should be checked on a regular
basis, there has been more, such as how to delegate and how to target
selection, and so on. Administrators manage objects not people, but the system:
for the team this system, how do you make team recognized objectives and
constraints, how to make the team are capable of forming their own rules, to
harmonize these rules with the goal, this is the team managers should focus on
things. For people management, managers should do a maximum incentive level,
people further down the assigned things don't fit anymore. Team themselves as
long as there is a goal, it will spontaneously go, you don't need to pay
attention to the team what to do.

 

Now market Shang many
management of theory, are has respective stressed of points, like KPI or bonus,
actually you will found many theory Zhijian is conflict of, because they no put
company overall into considerations, but only see a a level, a part, on with
this a part derivative out set management theory, looks is has truth, but
really to practice up, which many are just is "looks is beauty" just.

 

Finally recommends two books:
a book is mentioned by me earlier management 3.0, which provides a very good
framework and managers need to consider the dimension. Although the author of
this book in order to snap "management in complex theory" this
"subversive" theme, referring to a lot of classical management theory
also exist in concept, deliberately using different names or description--from
this point that the author is a little "trick", but the book is still
a good book. The 3.0 refers to the complexity of the theory of knowledge
management can be found in Melanie's book, the complex, the complex, this book
introduces the basic theory of many complex areas, such as cellular automata,
ants, chaos theory, non-Turing machine, bio-information engineering and for
understanding complex systems has been a big help. Of course, you want to know
more about complex theories, Hofstadter book is not to be missed.