Worktile, a 200-strong startup whose r&d accounts for half of the company’s total research and development, is managing its r&d team

What is a r&d team? To put it simply, your familiar team of programmers in plaid shirts is the r&d team.

You might expect grid guys to be nice and boring, and to be much easier to manage and collaborate with than sales and business, but the reality is that grid guys are not that easy to manage, and the complexity of the code world can be much higher than the complexity of the financial world.

As a company committed to teamwork, we have studied the R&D mode and management of many outstanding domestic and overseas companies, such as OKR’s application in Google and Facebook, Uber’s efficient meeting system, Alibaba’s performance system and Tencent’s product process. In addition to doing a lot of different experiments and reflections on our own team, we also wanted to share a lot of good experiences with our users. To talk about the method, it is necessary to understand the problems. The core problems of R&D management are nothing more than the following aspects.

Typical problems of R&D management

1. It is difficult to KPI and assess

Ren Zhengfei famously said that when money is divided, most management problems are solved. I can’t agree with you more. The problem is, how to divide the money is really a test of ability, experience and intelligence. The difficulty of research and development lies precisely in the failure to kpIS the work itself. All those attempts to KPIS engineers and code farmers end up with ridiculous, ugly and thankless results. In my past experience as well as the actual R&D management of clients, KPI-based R&D has always been the efforts of different teams, including but not limited to the following ways:

  • To solve the bugs
  • SLA
  • Functional completion
  • Overtime, 007 is better than 996, and 996 is more rewarding than 955
  • Revenue bundled
  • NPS

These seemingly digital indicators are of little value and do not provide positive incentives to companies and organizations, except as evidence that R&D managers are slackers in their performance reviews.

2. Close to the code, far from the user

Another practical and frustrating problem is that engineers and product managers seem to do product and development in ivory towers, often too far away from users. This kind of problem can be much more damaging than other things, but it is essentially a problem that has not been properly addressed by the development rules, so that the engineers themselves do not have any goal or motivation to be close to the user and customer scenarios. We often say that we should make products that users like, but those products that are against human intelligence are often the result of collusion between product managers and engineers. If the goal of R&D management is to improve efficiency, then the synchronization of R&D teams towards a unified goal is the most important first step of efficiency management. Therefore, what kind of system to drive R & D to look at customer scenarios is one of the core tasks of all R & D management.

3. Frequent inter-departmental wars

Because they work with their heads down, the goals of the R&D team and the business team are often not the same, and the cross-department wars between the R&D system and the business system are simply too numerous to record:

  • Business think, how so many bugs, a small problem need to spend so long time to fix
  • However, R&D thinks that business intelligence is not enough, and such a good product cannot be accurately conveyed to customers
  • Business bowing and scraping to customers; R&d thinks customers are business customers, not r&d customers
  • The business demand scheduling is 12345; The r&d demand schedule tends to be 54,321
  • Business commitment to customers is like falling in love, pick the stars also dare to continue;
  • You write the code to deliver what the developer thinks you promise
  • Business that r & D high wages blowing air conditioning, their daily run outside in the sun; Research and development thinks, the business commission is so high, I made this product, I don’t get commission

This kind of cut ceaseless, reason also disorderly relation, is the common phenomenon of many companies. Because of the lack of understanding between different departments, internal friction between teams will inevitably result in information discount and low efficiency. What is more important is the deviation and buck-passing of customer service and understanding caused by cross-department war. No company or team can achieve 100% customer satisfaction in an unsmooth environment.

So how to solve the above problems?

Start with the OVERVIEW of R&D management

The following r & D panorama is the r & D management experience gradually formed by our team in the past few years, which mainly includes the following contents:

  • The core of R & D management is to build an open, self-learning, self-driven organizational culture and sense of ceremony, which is the foundation of the most kernel of creating an efficient R & D team.
  • On the left are tools and methodologies, including: OKR-driven management by objectives, Scrum-based agility, and evolving DevOps.
  • The right side is the system and rules, the core of which includes: performance and assessment of r&d team, cross-department cooperation, other rules driven by ritual sense, especially the construction of self-learning environment and sharing mechanism.

Build an open and competitive organizational structure and culture

An open and transparent culture is the nuclear weapon of performance management. In general, no matter how rich and refined your methods and systems are, they are unlikely to drive extremely effective value from a rigid, rigid, and lethargic team. Therefore, when we talk about R&D efficiency, we always focus on other people’s team is in line with management, but ignore the core of team activation is to build a team culture with super freedom, transparency and sense of mission. From the point of view of efficiency, any improvement without transparency is compromised. The primary cause of inefficiency in an organization is not execution, but transparency. Organizations requiring multiple levels of approval and reporting, and teams with multiple levels of barriers and information walls are bound to be very inefficient. A single point of improvement in execution does not change the low efficiency gene of the whole team. Therefore, it is crucial to build open and competitive organizational structures and cultures.

1. Special forces

How to design the organizational structure of the R&D team is a big question. Our team has experienced several different organizational forms, and we often adjust the R&D team. To put it simply, the roles of a R&D team are mainly as follows:

  • The product manager
  • The designer
  • Server Engineer
  • Front End engineer
  • test
  • other

For example, many companies will regard the design team as a completely independent department, and other teams and projects will allocate design resources as required. The design team is like the role of Party B in the company, and matches execution through resource allocation. And another kind of form is widely exists in the way the Internet companies such as Facebook, design, development, testing, product manager of the short of special forces, in the research and development team in team form combination, as a developing business interface, a clear input and output of clear, have clear objectives and clear boundaries. Obviously, when it comes to fighting, a special force-style team is super powerful from execution to objectives, which can also facilitate the landing and motivation of the PERFORMANCE appraisal of the R&D organization.



Another benefit of special forces is that each group’s functions and objectives are fixed, executing a precise target and unit within the larger framework of product development. However, team members can be transferred to other teams, thus avoiding the boring and unchallenging problems of the r&d staff.

2. The sense of ritual

A sense of ritual is the spice of team management, a necessity, like salt. Development team managers, such as cTOS, need to consciously design valuable rituals in the team to increase team cohesion, chemistry and seasoning. A good sense of ritual, like a religious ritual, reinforces the execution of team goals, the shaping of culture, and the motivation of stages.

For example, our own team has a lot of ritualistic stuff going on:

  • OKR phase synchronization
  • Turn a major release into a phase of motivation for the development team
  • Regular One One interviews with management
  • Monthly interview of r&d personnel, synchronous to company monthly report
  • Thoughtful group construction
  • Monthly product assessment
  • mentoring
  • Go out and attend various external technical conferences
  • .

There are many other rituals and rules, and almost every one of them is worth talking about.

3. User Experience Committee

In the Worktile team, we set up some virtual organizations outside of the organizational structure. The design of the virtual organization can solve the problem of cross-department communication and information synchronization. Take the user experience Committee as an example, we formed a virtual committee of colleagues in r&d, design, product, sales and customer success. The chair of the committee is essentially the secretary of the organization, and the core goal is to solve user experience problems through regular meetings or discussions. A committee tea party can effectively advance many things at a time:

  • Full discussion on key issues of user experience, listening to product and r&d from different perspectives, sales and customer success more represent suggestions from front-line users.
  • Promote cross-departmental mutual understanding. In many cases, cross-departmental wars are caused by mutual incomprehension and contempt. For example, in a tea party, we had a discussion on a long-established core requirement. The sales side thought it was a simple requirement, but after discussion, it was found that the customer actually had a very different understanding of this simple requirement, which completely overturned the original design scheme of the product. In turn, sales colleagues fully understand why product solutions are so difficult.
  • Specify action plan, quickly drive product development to implement improvement plan. The USER Experience committee is not only to discuss, but more importantly to drive action plans and quickly solve user concerns about the experience.

4. Technical Committee

Also in the R&D team, we use the technical committee to achieve cross-team technical communication, sharing and technology selection. The technical committee ensures that the company’s technology-driven business foundation is not diluted, bringing together the most technically capable circle of the team to make more self-driven input and technical contributions. The main objectives include:

  • Company-level technical solutions
  • Rank evaluation of r&d posts in frontier technology R&D group, and technical committee is responsible for rank evaluation of technical ability
  • Drive the company’s technology progress and learning, such as organizing hackathons, technology sharing, and external technology output
  • Export technical content to market and sales r&d to the countryside

5. Research and development go to the countryside

Is to let the RESEARCH and development to the customer, close to the customer needs, understand the customer situation, and then come back to improve the product to meet the customer needs. Worktile itself is an enterprise service product, and customer needs are extremely complex and diverse at the B-side. It is impossible to make good products if you stay in the office. Therefore, it is necessary to drive research and development, product and design to customers from the system, instead of staying in the ivory tower. Research and development to the countryside to each r&d staff fixed indicators, need to the countryside to the customer site, so the sales and customer success has the legitimate grounds for r&d colleagues indicators, from another aspect also to strengthen the research and development and business cooperation and collaboration, because both sides have a common KPI, everyone together to do one thing becomes very strong power.

6. Polish Week

Polish Week is a popular culture from Silicon Valley, which allows the R&D team to have enough time to rest after a tense iteration and then focus on solving the needs or problems from customers. This system design is a very efficient method, which can focus on solving the remaining problems in a short time.

7. Technology sharing and going out

In the past five years, our technical team has regularly shared hundreds of times a week, and everyone in the R&D team has more or less completed the technology sharing of their department. Newcomers to the team can gain a great deal of legacy knowledge from the hundreds of times they have shared it.

(Technology sharing pool shared in r&d system)

On the other hand, Worktile’s core customers are development teams and engineers. The market dimension requires developers to be able to share valuable technical content, and the technology sharing mechanism provides the soil for engineers to create content. In fact, the content shared internally can be further optimized into the content that can be transmitted externally, and the secondary communication can be realized through market means. At the same time, it can also push the partners with vitality and sharing spirit in the team to the foreground to share in the technology conference or the technology sharing conference organized by the company.

OKR and Scrum-based development management

Due to the business relationship, we have conducted tests in N different customer scenarios, which is to conduct a survey of the goals of the team leader in the company group. The reality is that 99% of the time, the goals of the leader and the goals of the executive are not the same, and most of the time, they are very different. So, going back to implementing OKR at the development team or company level, essentially addresses the core problem of congruity.

As the saying goes, the same desire wins. If goals can’t be agreed upon, then all efficiency and efficiency optimization is nonsense. Because the more efficient you are, the more you run in the wrong direction, the farther you run out of direction. Isn’t that embarrassing?

Therefore, understanding OKR can help us form a basic capability in the team, which is strategic synchronization and strategic communication, to achieve unity of purpose. (Worktile OKR Topics page is recommended for basic OKR knowledge)

(OKR is a strategic synchronization and strategic communication tool that serves the team’s mission and vision)

1. Writing O and KR is the hardest first step in implementing OKR

Implementing OKR on the development team was not an easy task in and of itself. It took nearly three years of trial and error for the Worktile team to gradually get a feel for how to implement OKR, and of all the difficulties, how to write your O (goals) and KR (key results) at the beginning.

(A typical R&D O and KR definition)

Therefore, the initial phase requires continuous implementation of the OKR in form, which is a very necessary and consistent thing, and then continuous refinement of the O and KR definitions for each cycle. Here are some OKR templates to see how OKR defines a good team:

  • OKR templates for product managers

  • OKR templates for technology and development

2. OKR + Scrum methodology

Scrum cannot be covered in this article because it is such a big topic, and there is a big picture of how Scrum is implemented in our team, which includes agile development, code hosting, continuous integration, continuous deployment, and continuous release.

The chart below is a very basic example of agile development, with very professional and detailed management details from how meetings are held, how team sizes are defined, how roles are divided, how iterations are done, and how testing is done.

However, going back to Landing Scrum and the OKR team, Scrum + OKR is an extremely valuable combination of tools, and our own experience is combined in the following ways:

  • Department-level OKR drive + department-level agile drive. OKR is not at the individual level, but the best people in the team can be OKR driven

  • Iterations match OKR cycles, and Sprint Meeting and OKR Review Meeting are combined

  • OKR assists in prioritizing the product Backlog

  • Scrum Master participates in OKR Master target revision

We generally control the units performed by OKR at the company level at the department level, and do not force individuals to make their own O and KR. Therefore, when it comes to the management of the R&D team, the general direction and goals of the department are guaranteed by OKR. Intra-department iterations, Product and Sprint backlogs are executed with agile cycles and principles.

Big direction is guaranteed by OKR and affects priorities, small iterations and task planning, executed based on agile principles, are a perfect match.

3. Conference system

We recommend Review and planning meetings centered around Sprint Meeting and OKR Review Meeting.

The Worktile team typically has a very long synchronous meeting on a regular basis every Friday morning. The core of the meeting is a Sprint iteration based on Scrum to review progress and resolve objections. The product and development come together to effectively communicate progress and issues in the current release, quickly negotiate solutions, and appoint an executor.

On the other hand, we would review and update the development team’s goal tree together during the regular meeting, and the projection would display two pages, one for the iteration’s storyboard and one for OKR’s goal tree.

For the r&d team, through OKR and Scrum meetings, the core content of each meeting is well regulated and the efficiency is not the same as the response.

(Regular Scrum meeting with review of iteration progress and OKR target achievement)

4. Stand daily

Daily 15-minute stand-up sessions are a must for agile r&d teams. Quickly communicate yesterday’s progress and problems, quickly discuss solutions, then quickly plan today’s work arrangement, every day to spend a small time review, this is small iteration.

Of course, it’s nice to talk about Worktile’s iterative storyboard without having to stick a bunch of labels on the wall.

(Short, snappy stand-up meetings that take place every day)

5. Landing various pits in OKR

When implementing OKR, some pitfalls are common to first-time teams, which can be summarized as follows:

  • And performance appraisal
  • All hands on deck from the start
  • Become a target decomposition tool
  • HR is responsible, not the team leader

OKR is not a panacea. It’s more like a two-shot doctor. You can do it if you believe, but you can’t if you don’t believe. OKR provides the basic methodology, rituals, processes, and rules to create a basic framework for teams to synchronize their goals, and the actual implementation requires the company’s decision makers to stick with it. If they don’t try it once, they have to adjust and then try again. Our own team from the beginning to today, OKR attempt is the third time to gradually find the feeling.

Talk about R&D performance

For so many years, well-known foreign companies, head companies, small and beautiful overseas enterprises, especially bureaucratic domestic companies, including our co-construction and co-creation of customers, I experience and understand at least more than 100 companies.

But to be honest, it’s very rare to do a good job in r&d performance management. In itself, r&d performance, goals, management, rewards and punishments are always a difficult matter. Do not try to solve it with too simple solutions.

I have seen a company with a r&d team of 500 people divide their R&D work into thousands of indicators in order to index THEIR R&D KPIs, and then use the dynamic results of thousands of indicators to guide performance and direction. It’s an attempt at skeletal wonder, but I’m deeply skeptical from past experience. None of the great companies we know do this, but more often in a way that human intelligence can understand and agree on:

  • 360 degrees

  • rank

  • Peer Review

  • Project based rewards and punishments

  • Grading evaluation

Below, we share some of our own performance and reward and punishment methods in operation.

1. 360 degrees

In terms of our R&D performance system, we mainly implement 360 evaluation every six months, with 30 percent of the evaluation at the middle year and 70 percent at the end of the year. It includes self-assessment, colleagues, immediate superiors, HR and boss. The core of assessment is the influence of an individual on the company as the most important criterion.

Therefore, the debriefing process before the assessment is very important for everyone, because you need to clarify what valuable things I have done in this cycle, what meaningful results HAVE been brought, what problems exist, and how to avoid and solve them in the future.

Our department assessment is directly replaced by the 360-degree result of the department director, so this means that the individual assessment result of the department director, which is the result of the department as a whole, will affect the coefficient of the department as a whole.

Where there is assessment, there are rewards and punishments. 360 assessment is to determine the reward or punishment of an individual or a team for one year. Good or bad work is judged by this result.

Bonuses are determined by results, and we usually define the company, department and individual coefficients, each of which means different things, and then the weighted results represent how much you’ll get:

  • Company coefficient: it is basically related to the company’s overall revenue and the achievement of the overall target, and determines the total bonus pool and salary adjustment pool of the company.

  • Department coefficient: The department director’s individual coefficient, which determines the department’s ranking among the company’s multiple departments, as well as the department’s overall incentive coefficient.

  • Personal coefficient: it is the assessment result of the individual, which determines the rank of the individual in the department, and the total reward coefficient of the individual.

These three factors, taken together, basically define a year’s harvest for each person and sector.

360 degrees may not be the best performance plan, but it is the most effective method and way in the current universally implemented rules. Of course, there are a lot of details in the implementation of the 360-degree assessment, which is an important balance in the implementation process, and what adjustments should be reviewed at the end of each assessment.

In general, rewards and punishments are not always absolutely fair, only relative. However, in the definition of rules, how to realize the evaluation according to influence can guarantee the basic common sense that the most talented can do more work.

2. Rank driven

One of the most valuable tools for r&d teams is the rank system, which is an occupational sequence that conveniently defines the rating and sequence of an individual’s impact on the company, rather than the position sequence. So, for a senior engineer or architect, he or she may be senior to his or her department head, but he or she may be junior.

The hierarchy defines both a salary range and an option range, making the rank an inevitable path for a programmer to move up the ladder, since it may define the upper limit of his salary on the company’s scale and must be promoted to break through a salary bottleneck.

The value of ranks is that they are clearly defined and transparent rules, including salary ranges, options, fringe benefits, rating criteria. Such transparency standards can maximize the motivation of everyone to grow up. For example, we will include an annual amount of external training that you can take for your rank, which is a great little benefit for learning engineers.

(Rank system)

The ranking system is not a simple tool. There are many details that need to be considered and the rules that apply to different companies, such as how the ranks are rated, the technical committee’s definition of the technical competence of each person in the R&D position, the cycle of rank evaluation, and the requirements for each rank.

Overall, ranks are an effective tool to drive upward team members in the most transparent and fair way possible down the upward path.

In addition, our R&D team uses OKR+ 360 degree + ranking system to establish a relatively perfect management system, while in the business team, including sales, customer success and marketing team, KPI orientation is more prominent, so KPI is not poison, KPI should be used in the right place and in the right way.

3. Graded assessment

Graded assessment is a plan that we are trying step by step. It is only a discussion stage and has not been completely implemented yet. The reason for the implementation of hierarchical assessment is that any organization and team follow the 2-7-1 principle of common sense, there must be 20% of the outstanding people to bring the company forward in the long run, and there is a large probability that 70% of the executive layer need to rely on rules and excellent roles to influence the progress.

Therefore, there cannot be uniform rules in the way of assessment. Otherwise, too low a standard is set for outstanding people, or too high a standard is set for people of average ability.

On the other hand, graded assessment can also drive 70% of the partners from the rule, and have the motivation and standard to improve to 20%. Of course, we are still exploring and trying, but this is just a primer.

4. Total rewards are tied to total revenue

This is originally a common sense conclusion, but in this era of too much financing companies do not have a good understanding of the nature of rewards, many times to take money to reward financing, is immoral. Therefore, it is the most reasonable and courageous way to link total revenue to total rewards.

In our logic, the total revenue affects the company-level coefficient of performance appraisal, which can be defined by the core management.

tools

It is true that to do a good job, you must first sharpen your tools. The core value of tools is not just that they improve productivity, but that they fix the plumbing for the team.

There are a lot of things that can be channeled into the management, performance, and workflow of the R&D team, so using the right tools is the most effective way to help the r&d team repair the channel and achieve the team’s goals.

Of course, the main recommendation is our own effective tool that we use ourselves: Worktile. The core reason is that Worktile helps the development team in two areas:

  • Agile – based whole-process project management

  • Okr-based targeting tools

1. Drive the agile R&D process through Worktile project management (Scrum and Kanban)

Hundreds of thousands of teams have worked together through Worktile, with the highest percentage of r&d teams, due to our ability to provide complete toolchain support for the entire Agile process and a better product experience:

  • Support Scrum and Kanban agile practices

  • Complete iteration, storyboarding, requirements, task, and defect management based on agile methodology

  • Rich statements and data statistics, research and development decision management at a glance

  • Connect r&d and business, better cross-department collaboration support

Landing quickly requires simple tools to support the entire process, and Worktile gives you everything you need.

2. Use the Worktile OKR tool to execute the OKR

Worktile is the first product to implement OKR as a tool in China, providing better, more convenient and more data-oriented support for team implementation of OKR, including:

  • OKR performs the entire process management, from start-up, cycle, scoring and review

  • O and KR management based on company, department and individual levels

  • An object tree based on the object system

  • Automated operations analysis based on target execution, along with statistical reports, informs the team of OKR execution and updates

  • Automatic target update alert

(Define OKR in Worktile in a more efficient way)

OKR is a simple methodology and the tools themselves are not complex, but an automated approach is clearly more valuable to the team than an Excel shared approach. These are the channels that Worktile has already fixed, and you just have to bring water in.

conclusion

Well, this is a collection of r&d team, from the person in charge to the person in charge of some bit of experience, behind the projection of a hundred-person R&D team in the past growth of the road of continuous iteration of experience and methods.

Every team is unique and different, so experience and methods may not be suitable for all, but I hope that some possible ideas can bring some turning points and inspiration to your team.

Programmers group, a group of lovely guy is unique and different, they have the habit of pretentious, also has the transformational ambitions, they would not conform, is not to have been 996 bound hand and foot, drive this difficult group of people is not an easy thing, need to stand in the perspective of developers to understand their work and fun, And then create solutions that can be implemented, incentivized and digitized. That’s what we at Worktile are trying to do, and that’s our gift to our engineers.

Welcome to contribute your team experience, message me, or leave a message, let’s see what better way, free the world programmers.


Worktile’s website: Worktile.com

Author: Worktile CEO Anytao

This article was first published on Worktile’s official blog.