The development team is full of slacking, and the average base salary is no less than 11,000 yuan. How do you evaluate the quality and quantity of their work? What are the standards?

1. Currently, Amazon's development team consists of 4 people, with no management level. The team develops products based on product lines, and requires the launch of one premium product every month.
   
2. The problem we encountered was that the enthusiasm of the product development members was low , they often slacked off and looked at their phones, and there was no new product development.
   
3. Development level: Focus on more than 3 years of experience
4. The salary structure is: basic salary + commission + product launch bonus. For launching one more product, you will get a bonus of 2,000 yuan. The basic salary range is no less than 11,000 yuan.
   
   

• 1. If you are a development manager, how do you manage your developers? What forms and systems do you use? How do you check their work progress? How do you evaluate the quality and quantity of their work? What are good standards ? How high or low are the salaries of your developers? What are the reasons for high base salaries? Is there a step-by-step evaluation standard?
  
  
• 2. If you are a developer, can you share your current salary structure and commission method? What are the dimensions of performance appraisal?
  

"Wonderful Reply"

Lost Uncle -Drunk in the Sutra Pavilion with half a scroll of books, sitting in the well and talking about the vastness of the sky

Thank you for the invitation. I understand that the main questions of the poster are two:

1. How to solve the problem of developing employees’ work enthusiasm;

2. Specific indicators to quantify workload and quality, and indicators to quantify salary and ability.

In my opinion, there are at least three aspects to do a thing well:

(1) Whether the intention (or motivation) is strong;

(2) Whether the abilities and skills are sufficient or can be achieved with a little effort;

(3) Trigger mechanism. The poster mentioned above that he was not very motivated and often slacked off. At first glance, this seems to be a problem of willingness, but it does not rule out problems with insufficient skills and trigger mechanisms.

1. The big issue of enthusiasm is essentially a question of willingness.

From the perspective of willingness alone, there are probably three aspects: whether it is tempting to achieve the goal, whether there are obstacles in the process, and whether there are relatively large risks. You need to analyze your current actual situation one by one.

Regarding temptation, in addition to actual benefits, I think what needs to be emphasized more is the improvement of capabilities, because only when the capabilities are improved can we achieve greater success and have more actual benefits. This must be made clear to development colleagues.

In addition, if conditions permit, you can create an atmosphere of daring to fight and strive. People are the product of their environment and are influenced by it. You can also create an atmosphere by setting benchmarks.

In terms of abilities and skills, we should encourage everyone to actively learn and share, and improve each other's problem-solving abilities. This is relatively simple, but requires institutional guarantees and support. It does not necessarily require spending money, but of course it is also possible to spend a little money to promote this. The trigger mechanism is also relatively simple, such as scheduled weekly learning and sharing sessions.

In addition, willingness is a big issue. In addition to the company's atmosphere and the conditions provided, personal factors are also very important. As Kazuo Inamori said, you need to find people who are self-igniting, or at least combustible, not flame-retardant; if you accidentally find a flame-retardant or someone becomes this type of person during the process, you must ruthlessly clear them out, otherwise it will affect others. So when recruiting, you must pay special attention to this.

If the poster does not want to make it so complicated, I personally think he should do two things well. First, recruit people who have a strong desire to get things done. Second, pay attention to guiding the company's atmosphere (you can find relevant books on how to lead a team and manage to learn).

2. Questions about quantitative work indicators and evaluation criteria.

It is very necessary to quantify as much as possible, so that we can evaluate a person's value, which is actually good for everyone. In this way, good talents can be identified, and more work, more pay, less work, less pay, and no work, no pay. I personally suggest that we should be result-oriented and guide the company based on the results it cares about.

For example, if the company cares about profit, product success rate, payment period, experience sharing, etc., then you can set corresponding indicators and different weights for assessment. In the small company stage, it is not recommended to set too complicated. I personally think that profit and success rate are important. If it is set too complicated, it will be troublesome to assess, and people are also disgusted by such complicated things. I will not disclose the specific indicators. Please forgive me. At the same time, I also hope that the poster will set detailed quantitative items and assessment cycles according to the actual situation of the company and his own expectations.

For progress check, we can check the progress of specific product projects through weekly meetings and conduct routine communication on product development goals through monthly meetings. This is what we are doing now. This is just like the trigger mechanism mentioned above. Regular and routine triggering will avoid some human laziness.

For the base salary and the corresponding standard, you can consider the matching of people and positions. This is a relatively large project, which requires the establishment of a personnel skill and quality model, corresponding to the relevant level, and then the corresponding salary. It is not recommended for small companies to touch this, as it is too complicated.

I had experience in this area in a Fortune 500 company. At that time, I needed to develop skill level classification standards, expert appointments, certification processes, and organize defense for skill certification. If the poster insists on doing this, first consider performance support, which is the most important part and has the highest weight; secondly, consider what professional knowledge is needed for the categories you are involved in, what knowledge and skill levels different levels should have, and the results of written tests and defense. In the end, you need to combine the two aspects to judge the skill level, and you can even include work attitude as a standard. For example, Alibaba has relevant annotation content.

The above is for reference only. It may not achieve the purpose of the specific tool or template that the poster wants to solve the problem. On the one hand, it is too troublesome to find relevant information and modify it for a long time; on the other hand, it may not be in line with the actual situation of the poster, because templates have specific usage environments, please forgive me.

Anonymous user

I think you need to first analyze the possible reasons for your low enthusiasm for development and frequent slacking off.
For example, a category/market has been developed, but the company does not adopt it?
The category/market has been developed, but the company's resources do not match it? It is not suitable to enter?
The category/market has been developed, but the feasibility is not high, etc.

Because development and operations are different, operations are after sales, and poor data, poor products, low market fit, etc. lead to poor performance, but product development is more about personal development and analysis awareness and the matching of company positioning. Of course, if it is an employee’s problem, it will be discussed separately, but if the whole team is like this, either there is a problem with the system design, or the screening work was not done well during the recruitment/probation period.

So I think before designing the management direction, you might as well communicate with the developers one-on-one and ask them what difficulties, doubts, and obstacles they have encountered this year. Whether it is daily work or docking with operations, gradually understand whether there are external points that make the other party feel that "developing something with opportunities may also be rejected and shelved." If some things are not communicated first, the plan made will be risky.

That is, first identify the problems or potential problems that may cause development to fail, and then think about how to solve them.

If you rely purely on tables, you can refer to the attachments, summarize the inspection points and analysis dimensions as much as possible, and then make a quantitative assessment for the other party. For example, how many category/market/product analysis tables need to be output in a month?

For example:

• Use the OKR (Objectives and Key Results) method to set clear monthly and quarterly goals. Refer to the attached design details.
  

• Hold weekly team meetings to discuss progress, challenges, and next steps. Developers can take turns leading the meetings.
  

• Daily stand-up meetings are held to quickly synchronize work status.
  
  

• If several tables are produced and have strong reference feasibility and valuable data analysis, they can be considered good standards.
  
  

When recruiting, we develop salaries based on product lines and category experience. For example, if we are planning to develop lighting products this year, we are willing to pay higher salaries to developers with lighting-related experience and good overall quality, because if the level of development is good and the job is well matched, we are willing to pay them 20-30% higher than the original salary.

During the assessment, output quantity is one aspect, success rate is another, suggestion output and meeting analysis leadership are also another aspect.

If you feel that some developers are just slacking off in terms of communication and assessment, then simply take out about 30% of the original base salary for performance assessment. If the assessment score is not enough that month, deduct this 30%. This way, the other party will either resign voluntarily or adjust their enthusiasm to cooperate with the work.

Anonymous user

I think to increase enthusiasm, the commission of subsequent orders should be taken into account, with the arrival of the first batch of products at the Amazon warehouse as the starting date. In the first year, you can get x% of the net profit commission, and in the next year, you can get x/2%. After 2 years, you will not enjoy any commission, or you can set a fixed amount of 0.3-1%.

If you want to encourage the development of explosive products, you can set it up in a step-by-step manner:
Annual sales/monthly sales

50w USD X%
1 million USD X+n
2 million USD X +2n ...

Another thing to consider is the performance of development. The promotion of operations will have a great impact on it. To solve this problem, developers can first filter out several important data for operation reference, and operations can also check whether the data given is correct.

After confirming the product, the operation department will calculate the funds for product promotion, the operation mode, promotion goals and cycle, and give them to the development department. In this way, both the development department and the operation department can clearly know whether to make this product.

Of course, if you develop infringing products, your performance will also be deducted.
Deduct the performance/commission of the current month/quarter
Fixed amount fine Liability as a percentage of actual loss