Ways to evaluate employee performance
Many managers face one very interesting problem in the IT field. And the name of this problem is an assessment of employee performance. Half a century ago, such a task did not cause migraine attacks and panic among managers or economists, because everything was simple. The worker spun 50 nuts — bad; twisted 150 nuts — great! But the information technology revolution has come, and performance evaluation has become the cornerstone.
Let's see what's what. Suppose we have an abstract IT worker who looks a lot like a programmer who will create at least an abstract product in a company of such abstract workers. The first thing that an appraiser of the mid-19th century would have done was to produce quite clear labor indicators. And it would be the time and amount of code. The more code an employee creates, with minimal time costs, the more efficient the employee . All this is good, but it does not work.
')
And this does not work because the complexity of the tasks is different. One problem can be solved two weeks, the second 15 minutes. Yeah, so we need to change the pricing formula. Let's take a certain coefficient of complexity of the problem and multiply the amount of code by it. The more complex code in a shorter period of time an employee makes, the more effective it is. The formulation is excellent, only for a longer period of time an employee can perform two light tasks, two hard, one medium difficulty. This seriously reduces its effectiveness, judging by the wording.
No matter how we try to beat around the bush, the sense of these calculations will be zero. The problem lies in the indicators. If time can still be used, then the amount of code is not. This is not a performance indicator at all.
Many companies, at the dawn of the IT industry, tried to pay for the number of lines that the programmer wrote. Someone realized that you can write a working crap with a terrible amount of excess code. Money is paid for the number of characters, not for the quality or efficiency of the code.
For me personally, employee performance indicators are completely different. Some of them are subjective, and I do not deny it.
The fewer mistakes a worker makes in work, the better his work. The quality of the code easily turns into the pleasure of users who can choose your product exactly for this indicator. The second plus of quality code is to minimize the cost of support, testing, and more. Yes, a person is not perfect, but if he didn’t test the results of his work on his own, but had already reported on the completion of work, then his laziness would lead to a whole chain of ineffective gestures in the company. For the mistakes of employees, the company pays out of its own pocket, and this then reflects on the well-being of the workers themselves.
In the development team, there should always be an information exchange. Employees must share useful information about convenient code designs or techniques, about the successful implementation of some functionality, about technologies, about the results of their research, about problems and their solutions ... If a person does not generate information, he ceases to be an effective employee. how his knowledge does not help others. This does not apply to newcomers to the team, but even newcomers can create a positive information background.
Employees who can independently generate ideas are, in my opinion, the most valuable employees. They do not need to write detailed TZs, they do not need to scrupulously explain the difference of one approach from another, and why it is worth choosing a different path, rather than the one that they have read somewhere. These workers will come up with 10 ways to solve non-trivial tasks, and will find 10 reasons why each of them will not work. They drag the whole team with them and are not afraid of difficulties. Because they are interested in reinventing bicycles, and in no case should this opportunity be taken away from them.
The more simple abstractions a person operates, the simpler the task he can solve. The ability to manage complex abstractions leads to a tremendous effect. For such a person, the programming language, tools, approaches, algorithms cease to be important. Any, even the most complicated system, will not pose any difficulty for him, because he can look at the root, not at the tops. Usually, such people become software architects, develop specifications, and engage in analytics.
There are two types of workers: “tired” and “aggressive”. “Tired” workers strive to do as little as possible and receive as much money as possible. They are not interested in developing or learning something new. Their fatigue is not due to the fact that they have been burdened with a lot of work, or they have not efficiently distributed their time, and they have had to recycle. Their weariness from loss of interest or motivation in work.
“Aggressive”, on the contrary, try as quickly as possible to go through the path of learning, development, becoming, in order to gain access to even more resources in order to develop, develop, develop. They eagerly absorb knowledge, learn, try, make mistakes, and over them you do not need to build a pyramid of managers to spur to work. "Tired" trying to find work in large companies, where the effect of their work is not visible at all. “Aggressive” find themselves in startups, small companies, because there it’s easier to get everything they need.
Because at least they provided for the scalability of the code, implemented the code itself at a qualitative level, using understandable constructions and variable names, can quickly read “someone else's” code, created a predictable and understandable architecture, in which debugging is easy to do. Such a simple characteristic can tell about the code much more than the number of lines per unit of time.
These are not all assessment methods, but these are the ones I use for personnel selection and for evaluating the effectiveness of a company. I hope that you will come in handy.
UPD: Moved the article to a more appropriate section. Thank you andreycha
Let's see what's what. Suppose we have an abstract IT worker who looks a lot like a programmer who will create at least an abstract product in a company of such abstract workers. The first thing that an appraiser of the mid-19th century would have done was to produce quite clear labor indicators. And it would be the time and amount of code. The more code an employee creates, with minimal time costs, the more efficient the employee . All this is good, but it does not work.
')
And this does not work because the complexity of the tasks is different. One problem can be solved two weeks, the second 15 minutes. Yeah, so we need to change the pricing formula. Let's take a certain coefficient of complexity of the problem and multiply the amount of code by it. The more complex code in a shorter period of time an employee makes, the more effective it is. The formulation is excellent, only for a longer period of time an employee can perform two light tasks, two hard, one medium difficulty. This seriously reduces its effectiveness, judging by the wording.
No matter how we try to beat around the bush, the sense of these calculations will be zero. The problem lies in the indicators. If time can still be used, then the amount of code is not. This is not a performance indicator at all.
Many companies, at the dawn of the IT industry, tried to pay for the number of lines that the programmer wrote. Someone realized that you can write a working crap with a terrible amount of excess code. Money is paid for the number of characters, not for the quality or efficiency of the code.
New look at things
For me personally, employee performance indicators are completely different. Some of them are subjective, and I do not deny it.
Fewer mistakes - more efficient worker
The fewer mistakes a worker makes in work, the better his work. The quality of the code easily turns into the pleasure of users who can choose your product exactly for this indicator. The second plus of quality code is to minimize the cost of support, testing, and more. Yes, a person is not perfect, but if he didn’t test the results of his work on his own, but had already reported on the completion of work, then his laziness would lead to a whole chain of ineffective gestures in the company. For the mistakes of employees, the company pays out of its own pocket, and this then reflects on the well-being of the workers themselves.
The more effective the employee, the more he spreads useful information in the team
In the development team, there should always be an information exchange. Employees must share useful information about convenient code designs or techniques, about the successful implementation of some functionality, about technologies, about the results of their research, about problems and their solutions ... If a person does not generate information, he ceases to be an effective employee. how his knowledge does not help others. This does not apply to newcomers to the team, but even newcomers can create a positive information background.
Idea generators are many times more efficient than consumers of ideas.
Employees who can independently generate ideas are, in my opinion, the most valuable employees. They do not need to write detailed TZs, they do not need to scrupulously explain the difference of one approach from another, and why it is worth choosing a different path, rather than the one that they have read somewhere. These workers will come up with 10 ways to solve non-trivial tasks, and will find 10 reasons why each of them will not work. They drag the whole team with them and are not afraid of difficulties. Because they are interested in reinventing bicycles, and in no case should this opportunity be taken away from them.
The more abstract thinking, the more effective the employee
The more simple abstractions a person operates, the simpler the task he can solve. The ability to manage complex abstractions leads to a tremendous effect. For such a person, the programming language, tools, approaches, algorithms cease to be important. Any, even the most complicated system, will not pose any difficulty for him, because he can look at the root, not at the tops. Usually, such people become software architects, develop specifications, and engage in analytics.
The effectiveness of the employee is directly proportional to his self-motivation.
There are two types of workers: “tired” and “aggressive”. “Tired” workers strive to do as little as possible and receive as much money as possible. They are not interested in developing or learning something new. Their fatigue is not due to the fact that they have been burdened with a lot of work, or they have not efficiently distributed their time, and they have had to recycle. Their weariness from loss of interest or motivation in work.
“Aggressive”, on the contrary, try as quickly as possible to go through the path of learning, development, becoming, in order to gain access to even more resources in order to develop, develop, develop. They eagerly absorb knowledge, learn, try, make mistakes, and over them you do not need to build a pyramid of managers to spur to work. "Tired" trying to find work in large companies, where the effect of their work is not visible at all. “Aggressive” find themselves in startups, small companies, because there it’s easier to get everything they need.
The faster employees perform code refinement, the more effective they are.
Because at least they provided for the scalability of the code, implemented the code itself at a qualitative level, using understandable constructions and variable names, can quickly read “someone else's” code, created a predictable and understandable architecture, in which debugging is easy to do. Such a simple characteristic can tell about the code much more than the number of lines per unit of time.
These are not all assessment methods, but these are the ones I use for personnel selection and for evaluating the effectiveness of a company. I hope that you will come in handy.
UPD: Moved the article to a more appropriate section. Thank you andreycha
Source: https://habr.com/ru/post/101906/
All Articles