When it's hard to be a “bad guy”
Almost any company is faced with the problem of personnel evaluation. Scales always stagger a little - the quality of the work done or the number of completed tasks? And for the IT department, this issue is acute and is solved by each company a little differently. Today we want to describe our experience in building a rating system for developers, analysts and customers, on which we continue to experiment.
Why do we do this?
')
Alfa-Leasing (a subsidiary of Alfa-Bank) has grown dramatically in 2017: the size of the business has increased 5.5 times, the total number of employees has more than doubled, and the IT department has grown from 10 to 50 people. At the same time, we understood that in a large company, everyone needs transparent and understandable KPIs, which we either invent ourselves or impose on us from outside.
In order not to adapt to someone else's system or adapt some theoretical formula, I had to create my own.
Given
What we had at the very beginning: historically, it turned out that the IT team was divided into two offices - St. Petersburg and Moscow. On the one hand, they need to regularly interact with each other, but on the other, any incomprehensible situation divides the team into two if not warring camps, where the responsibility is always on the side of the "neighbors", then they simply refuse to understand each other. Therefore, the first thing that had to be done to bring this equation to a common denominator was to remove the boundaries of responsibility and make it common to all.
So we began to change the organizational structure, expanding the area of responsibility of employees. There was no longer one specialist who was responsible, for example, for the server in St. Petersburg, and another who was responsible for the server in Moscow. It took some time, but in general the idea that we were in the same boat, the team began calmly. Then, for business support tasks, we established kanban, and for product development tasks we launched SCRUM teams. And if we have removed the regional separation, a command one has arisen.
Of course, the SCRUM teams had their own retro, but in order to constantly change the processes of interaction in the development, we did a retro to the whole development team through video communication. Once a month, all developers and analysts (by the way, we don’t have a special role as a tester) get together and discuss their problems together, but most importantly, they also decide together by common vote.
These meetings soon became the impetus for creating an assessment system. Regularly on the retro there was a question about the quality of the code. If the system is not there, but there are some “good” guys who are fighting for the quality of the code, then their initiative to send the examples of “kakahs” laid out in the repository to their colleagues caused irritation or ridicule.
STEP 1 - Public code review
To finally deal with the quality of the code within the company, we decided to do a double check for each task. Due to the fact that all developers have about the same qualifications, they can themselves become both the creators of the code and its verifiers. In order to strengthen the interaction between the offices, they decided to carry out the inspection by the forces of two specialists - from Moscow and from St. Petersburg. In this way, it turned out that in order to release the “into battle” task, it must first undergo a double check. We have classified comments on the code. In total, we have 7 classifiers. If there are comments to the code, then they are fixed in our tracker, and the task goes to the developer to correct the comments.
The first code review took place in public. Just like in school: I wrote the code - I brought it to the big screen, and everyone checks it. To be honest, in order to decide on this, you need enough courage and confidence in your work. But somehow we managed to hold them, albeit with emotions and superfluous “steam”, but this was the first big stone in the foundation of the future system.
It helped: as a result of the public code review, we managed to develop “Standards of good code”, with which everyone agreed. They change a little over time, which is absolutely normal. The main goal is to make the check transparent, fast and objective.
As a bonus, we give a link to a brilliant video about a clean code that strongly motivated and amused our team:
STEP 2 - New Roles and Feedback Form
Clean code is great, but you won’t get too far: it’s just one of the facets of the work. After we decided on the rules of “calligraphy” and grades, we had to go to the next level and learn to prove that we are good workers too. The situation in almost every company is the same - one of the customers is always dissatisfied with the IT department: business, marketing, lawyers. Dissatisfaction is immeasurable, there is no “discontent meter”. We decided to find out exactly what the customer thinks about each specific task performed by the developer.
As it happens by example: the task is drawn to the board. We briefly discuss it and, if the statement of the problem raises even the slightest doubt or questions, it first goes to the analyst. If the task is very simple, then the analyst is not involved in it. But this does not mean that the stage of analytics itself is not executed. Not. The developer of such tasks analytics conducts independently. The analyst, in turn, either deciphers a complex task, or decomposes it, or simply removes it from the board if it suddenly lost its relevance.
If the task was transferred to the “Completed” status, we decided to ask the customer how he was to work with a specific developer. There are only 9.5 questions in the questionnaire that allow us to evaluate ourselves not only as professionals, but also as good employees and a department where it is pleasant to apply. If the analyst also took part in the task, then we asked the analyst how he worked.
It helped : now the developer has no opportunity to be a “bad guy” - we do a double code review, analyze tasks in order to discard impossible ones, and poll specific customers and analysts who worked with him. The success of this system is that it was not imposed from the outside, but created together in a general vote. Therefore, no one is against such a comprehensive assessment.
STEP 3 - Do not stop
At some point we thought that we should not stop at what has been accomplished and we can collect feedback from all participants in the chain, namely:
As a result, we got a lot of information that had to be used immediately and we began to digitize the results of these forms. So that the whole undertaking does not lose its meaning, the feedback results have become a part of KPI analysts and developers. In other words, a part of their premium depends on the feedback they receive and how clean the code delivered from the first time will be.
The only one who flies out of this chain is the customer. It was not possible to add feedback from the analyst and the developer to his KPI, so we decided that we would collect the invoice and at the end of the year we will conduct the results. In any case, we will have a reason to start a conversation and arguments in favor of changing the situation for the better. This is often not enough for effective communication.
Helped: this step allowed us to restore the balance between all participants in the process. The role of the “bad guy” has become as difficult as possible.
STEP 4 - What do you feel?
Now we have an ideal “system”, which proves in numbers and facts that we understand tasks correctly, write good code and know how to communicate with other departments. The time has come to understand ourselves, to make sure that we are happy. There is no global statistics on how happy or not people are in their organizations. It is often the case that a person, feeling that something is wrong, does not try to analyze it, accumulates discontent, and then simply leaves.
To avoid this situation, we communicate with people. Normal feedback system. At the heart of communication are 7 questions, 6 of which are digitized. We ask each employee to evaluate on a 10-point scale the following parameters of his sense of self in the organization. Moreover, we give definitions only for 0 and 10. What is 5 or 7, we do not describe.
Namely:
If you digitize the data and put it on a graph, then you get this hexagon.
The larger the area of the hexagon, the more comfortable the IT specialist with us. If there are falls somewhere, then this is a signal to pay attention and work with this employee along with this fall.
We can build a diagram in any section (department, city, team ..., etc.). The graph shows the changes of each employee and department as a whole.
It helped: in this way we tried to rationalize the most unsuitable part of our life - sensations. Now we better understand how the work and our attitude towards it changes, we can try to predict the burnout of our employees and react to it quickly enough, see the imperfections of the system of assessment and distribution of tasks and make the appropriate changes and much more.
Many companies try to collect feedback, but not everyone is able to work with it and change its work depending on its results. The main guideline that helps us not to go astray and not waste time is common sense, which stands firmly on the understanding that we are a commercial company and our main goal is to make money. Yes, IT does not directly bring profit, but the final result depends on the quality and speed of our work.
Therefore, every time we try to improve ourselves or the world around us and stumble upon some kind of difficulty, do we evaluate whether the company will bring or save it? It would seem: if the answer is positive, we are doing everything right, if not - we need to let go and not regret the time spent. But not everything is so one-sided. There are tasks that costly and direct profits right now will not bring, but in the future may have a dramatic impact on the development of the company.
Our next big step will be the development and implementation of a material assessment of each task that goes to IT. We want to accustom ourselves and others to think in income and expenses, but it will take some time.
Why do we do this?
')
Alfa-Leasing (a subsidiary of Alfa-Bank) has grown dramatically in 2017: the size of the business has increased 5.5 times, the total number of employees has more than doubled, and the IT department has grown from 10 to 50 people. At the same time, we understood that in a large company, everyone needs transparent and understandable KPIs, which we either invent ourselves or impose on us from outside.
In order not to adapt to someone else's system or adapt some theoretical formula, I had to create my own.
Given
What we had at the very beginning: historically, it turned out that the IT team was divided into two offices - St. Petersburg and Moscow. On the one hand, they need to regularly interact with each other, but on the other, any incomprehensible situation divides the team into two if not warring camps, where the responsibility is always on the side of the "neighbors", then they simply refuse to understand each other. Therefore, the first thing that had to be done to bring this equation to a common denominator was to remove the boundaries of responsibility and make it common to all.
So we began to change the organizational structure, expanding the area of responsibility of employees. There was no longer one specialist who was responsible, for example, for the server in St. Petersburg, and another who was responsible for the server in Moscow. It took some time, but in general the idea that we were in the same boat, the team began calmly. Then, for business support tasks, we established kanban, and for product development tasks we launched SCRUM teams. And if we have removed the regional separation, a command one has arisen.
Of course, the SCRUM teams had their own retro, but in order to constantly change the processes of interaction in the development, we did a retro to the whole development team through video communication. Once a month, all developers and analysts (by the way, we don’t have a special role as a tester) get together and discuss their problems together, but most importantly, they also decide together by common vote.
These meetings soon became the impetus for creating an assessment system. Regularly on the retro there was a question about the quality of the code. If the system is not there, but there are some “good” guys who are fighting for the quality of the code, then their initiative to send the examples of “kakahs” laid out in the repository to their colleagues caused irritation or ridicule.
What did you do?
STEP 1 - Public code review
To finally deal with the quality of the code within the company, we decided to do a double check for each task. Due to the fact that all developers have about the same qualifications, they can themselves become both the creators of the code and its verifiers. In order to strengthen the interaction between the offices, they decided to carry out the inspection by the forces of two specialists - from Moscow and from St. Petersburg. In this way, it turned out that in order to release the “into battle” task, it must first undergo a double check. We have classified comments on the code. In total, we have 7 classifiers. If there are comments to the code, then they are fixed in our tracker, and the task goes to the developer to correct the comments.
The first code review took place in public. Just like in school: I wrote the code - I brought it to the big screen, and everyone checks it. To be honest, in order to decide on this, you need enough courage and confidence in your work. But somehow we managed to hold them, albeit with emotions and superfluous “steam”, but this was the first big stone in the foundation of the future system.
It helped: as a result of the public code review, we managed to develop “Standards of good code”, with which everyone agreed. They change a little over time, which is absolutely normal. The main goal is to make the check transparent, fast and objective.
As a bonus, we give a link to a brilliant video about a clean code that strongly motivated and amused our team:
STEP 2 - New Roles and Feedback Form
Clean code is great, but you won’t get too far: it’s just one of the facets of the work. After we decided on the rules of “calligraphy” and grades, we had to go to the next level and learn to prove that we are good workers too. The situation in almost every company is the same - one of the customers is always dissatisfied with the IT department: business, marketing, lawyers. Dissatisfaction is immeasurable, there is no “discontent meter”. We decided to find out exactly what the customer thinks about each specific task performed by the developer.
As it happens by example: the task is drawn to the board. We briefly discuss it and, if the statement of the problem raises even the slightest doubt or questions, it first goes to the analyst. If the task is very simple, then the analyst is not involved in it. But this does not mean that the stage of analytics itself is not executed. Not. The developer of such tasks analytics conducts independently. The analyst, in turn, either deciphers a complex task, or decomposes it, or simply removes it from the board if it suddenly lost its relevance.
If the task was transferred to the “Completed” status, we decided to ask the customer how he was to work with a specific developer. There are only 9.5 questions in the questionnaire that allow us to evaluate ourselves not only as professionals, but also as good employees and a department where it is pleasant to apply. If the analyst also took part in the task, then we asked the analyst how he worked.
It helped : now the developer has no opportunity to be a “bad guy” - we do a double code review, analyze tasks in order to discard impossible ones, and poll specific customers and analysts who worked with him. The success of this system is that it was not imposed from the outside, but created together in a general vote. Therefore, no one is against such a comprehensive assessment.
STEP 3 - Do not stop
At some point we thought that we should not stop at what has been accomplished and we can collect feedback from all participants in the chain, namely:
- The developer, after the assignment, fills out a questionnaire for Analytics and the Customer.
- Customer on Analytics and Developer.
- Analyst for Developer and Customer.
As a result, we got a lot of information that had to be used immediately and we began to digitize the results of these forms. So that the whole undertaking does not lose its meaning, the feedback results have become a part of KPI analysts and developers. In other words, a part of their premium depends on the feedback they receive and how clean the code delivered from the first time will be.
The only one who flies out of this chain is the customer. It was not possible to add feedback from the analyst and the developer to his KPI, so we decided that we would collect the invoice and at the end of the year we will conduct the results. In any case, we will have a reason to start a conversation and arguments in favor of changing the situation for the better. This is often not enough for effective communication.
Helped: this step allowed us to restore the balance between all participants in the process. The role of the “bad guy” has become as difficult as possible.
STEP 4 - What do you feel?
Now we have an ideal “system”, which proves in numbers and facts that we understand tasks correctly, write good code and know how to communicate with other departments. The time has come to understand ourselves, to make sure that we are happy. There is no global statistics on how happy or not people are in their organizations. It is often the case that a person, feeling that something is wrong, does not try to analyze it, accumulates discontent, and then simply leaves.
To avoid this situation, we communicate with people. Normal feedback system. At the heart of communication are 7 questions, 6 of which are digitized. We ask each employee to evaluate on a 10-point scale the following parameters of his sense of self in the organization. Moreover, we give definitions only for 0 and 10. What is 5 or 7, we do not describe.
Namely:
- How interesting are the tasks that you do?
- How difficult is the task?
- Do you have enough feedback from the manager?
- Rate your satisfaction in sn.
- Rate relationship in a team.
- Evaluate your understanding of the impact of your daily work on the success of the company.
If you digitize the data and put it on a graph, then you get this hexagon.
The larger the area of the hexagon, the more comfortable the IT specialist with us. If there are falls somewhere, then this is a signal to pay attention and work with this employee along with this fall.
We can build a diagram in any section (department, city, team ..., etc.). The graph shows the changes of each employee and department as a whole.
It helped: in this way we tried to rationalize the most unsuitable part of our life - sensations. Now we better understand how the work and our attitude towards it changes, we can try to predict the burnout of our employees and react to it quickly enough, see the imperfections of the system of assessment and distribution of tasks and make the appropriate changes and much more.
Conclusion
Many companies try to collect feedback, but not everyone is able to work with it and change its work depending on its results. The main guideline that helps us not to go astray and not waste time is common sense, which stands firmly on the understanding that we are a commercial company and our main goal is to make money. Yes, IT does not directly bring profit, but the final result depends on the quality and speed of our work.
Therefore, every time we try to improve ourselves or the world around us and stumble upon some kind of difficulty, do we evaluate whether the company will bring or save it? It would seem: if the answer is positive, we are doing everything right, if not - we need to let go and not regret the time spent. But not everything is so one-sided. There are tasks that costly and direct profits right now will not bring, but in the future may have a dramatic impact on the development of the company.
Our next big step will be the development and implementation of a material assessment of each task that goes to IT. We want to accustom ourselves and others to think in income and expenses, but it will take some time.
Source: https://habr.com/ru/post/352234/
All Articles