A depressing team structure for programmers -- On the structure of R & D teams

A depressing team structure for programmers -- On the structure of R & D teams

Author: bell Weibo: @ Bell programmer

Today, a former HR beauty colleague asked me to give her a suggestion on the R & D team architecture. After reading the structure chart, I told her: This is a very depressing R & D team and everyone will change jobs!
For example:

She is puzzled: What is wrong with my team structure? It's all about you!
Well, I will explain my conclusions here. Author: bell Weibo: @ Bell programmer
 

I. A good team structure should be separated by several factors: 1. Separation of rank and position; 2. Separation of management level (M) and technical level (P)

 

1. Separation of rank and position

That is to say, the level of rank has nothing to do with the position. For example, a director's level is P3, but one of his architects is P4, which is acceptable.
The advantage of this is that the rank becomes a standard for objectively evaluating the competence of a person, and it has nothing to do with the specific position he has done. If not a senior position, he can also get a higher salary, people do not have to compete with each other for a position or title, so that everyone can focus on their own technology and management capabilities.

 

2. management-level (M) and technical-level (p) Separation

This separation is an effective way to classify business capabilities more effectively and avoid the use of skilled people to take over everything in the company. The voices of M-and P-level people are equal in the company. In this way, the two sides form a mutually supportive and constrained relationship on the same issue.
Without the separation of M and P, either the company's leaders do not understand the technology, or the company's leaders are technically strong and do not understand the management.
Both m and P are effective, and their [business capabilities] are recognized by the company at the job level.

 

2. The purpose of rank division is not to pay the salaries, but to give employees a promotion channel and hope.

Many HR people misunderstand that the rank is to set the salary, but it is not. The rank you set up is to give everyone a channel of promotion and hope.
Both m and P are effective in the same way, and their [business capabilities] are recognized by the company at the on-the-job level. This is a channel and hope for the promotion of people in each rank sequence, employees with lower ranks will know that their efforts in their own sequence are more important.
Everyone knows their next goal and where the next step is.

 

III. The purpose of separation of rank and position is

As a company, the position will be bound to its specific work content, and the adjustment of the position is often difficult. It is often only possible to go up and down. Once the position is reduced, it means that the person is discarded.
However, the rank has nothing to do with the work content and is only related to its business ability. When the position remains unchanged, it can be placed down.
If the rank can only go up or down, it will lead to a situation where [mixed days, mixed years], people will think that [as long as the year is mixed up, the rank will naturally grow slowly ]. Of course, if the rank cannot be lower than the upper level, it is best to manage teamleader and HR. You only need to check the employee's employment life to assess the rank.
However, this violates the original design intention of separation of rank and position.
 

Iv. Management of personnel at m and P levels

There is also a wrong idea that people in the p sequence cannot manage people. For example, "architects" can only manage technology and teams can only be managed by m people, no more technical personnel can bring teams.
Q: How can I confirm the technical direction and architecture direction of tech experts? Is it determined by m who doesn't know the technology ??
Of course, this will inevitably become a disaster.
A good R & D team relies not only on management capabilities, but also on the technical capabilities and charm of teamleader.
If a person without technical knowledge manages the technical team, I'm afraid that all the people in the team will leave.
 

To sum up, let's look at the figure above.
It seems that everyone is here and there is a well-organized way. Actually, what?
1. The rising channel is closed and cannot see the subsequent development path...
2. management-level figures are all about the sky and sky, all of them are empty characters, and they all do not understand technology...
3. I was surprised that the architect could go through a separate sequence!
 
You are welcome to write so much for the moment.

 

By the way, at your request, I have posted the correct architecture schematic for your reference...
 

 

In this structure, each position defines a job description and a job quality model.
This is mainly achieved. The separation of rank and position is not confused. Each major has its own independent rising channel, and rank is linked to salary. Rank is the result of business capability evaluation, people focus on improving their business capabilities, rather than focusing on specific positions.

You are welcome to continue the discussion or follow my weibo blog.

 

My microblog: http://weibo.com/useway @ :@zhongsheng programmer Bell, author of "Java programmer, at work"   Thank you !!