March 28, 2018 at 21:33When it's hard to be a “bad guy”
Almost any company is faced with the problem of personnel assessment. Scales are always a little loose - the quality of the work performed or the number of completed tasks? And for the IT department, this issue is acute and each company decides 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 are we doing this?
In 2017, Alfa Leasing (a subsidiary of Alfa Bank) has grown significantly: the size of the business has increased 5.5 times, the total number of employees more than 2 times, 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 come up with ourselves or they will be imposed on us from the 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, 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 responsibility is always on the side of the "neighbors", then simply refusing to understand each other. Therefore, the first thing that needed 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 a server in St. Petersburg, and another who was responsible for a server in Moscow. It took some time, but in general the idea that we were in the same boat was accepted by the team calmly. Then, for the tasks of supporting the business, we established a kanban, and for the tasks of developing products, we launched SCRUM teams. And if we removed the regional separation, then a command arose.
Of course, the SCRUM teams had their own retro, but in order to constantly change the interaction processes in development, we made a retro for the entire development team through video communication. Once a month, all developers and analysts (by the way, we don’t have a special role for the 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 a rating system. Regularly the question arose about retro quality of the code. If there is no system, but there are separate “good” guys who are fighting for the quality of the code, then their initiative to send colleagues examples of “kakah” laid out in the repository caused irritation or ridicule.
STEP 1 - Public code review
To finally understand 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 approximately the same qualifications, they themselves can 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 verification by two specialists - from Moscow and from St. Petersburg. Thus, it turned out that in order to release the task “into battle”, it must first pass a double check. We classified the code comments. In total, we have 7 classifiers. If there are comments on the code, then they are recorded in our tracker, and the task is left to the developer to correct the comments.
The first code review took place publicly. Everything is like at school: I wrote a code - brought it to the big screen, and everyone checks it. Frankly, in order to decide on this, you need enough courage and confidence in your work. But somehow we managed to carry them out, albeit with emotions and extra “steam”, but this was the first big stone in the foundation of the future system.
It helped: as a result of public code review, we managed to develop “Standards for a good code”, which everyone agreed. They change slightly over time, which is absolutely normal. The main goal is to make the audit transparent, quick 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
Pure code is great, but you won’t go 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 how to prove that we are good workers. 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 an immeasurable thing; there is no “dissatisfaction meter”. We decided to find out exactly what the customer thinks about each specific task performed by the developer.
How this happens with an example: a task is pulled onto a board. We discuss it briefly and, if the statement of the problem raises even the slightest doubts or questions, she 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 analytics stage itself has not been completed. Not. The developer conducts the analytics on such tasks independently. The analyst, in turn, either decrypts the complex task, or decomposes it, or simply removes it from the board if it suddenly lost its relevance.
If the task went into the status of "Completed", we decided to ask the customer how he was to work with a specific developer. There are only 9.5 questions in the questionnaire, which allow us to evaluate ourselves not only as professionals, but also as good employees and a department where it’s nice to contact. If the analyst also took part in the task, then we asked the analyst how he worked.
It helped : now the developer has absolutely no way to be a “bad guy” - we do a double code review, analyze tasks to discard the impossible, and interview 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 there and we could collect feedback from all participants in the chain, namely:
As a result, we got a lot of information that needed to be used immediately and we began to digitize the results of these profiles. So that the whole idea does not lose its meaning, the feedback results have become part of the KPI of analysts and developers. In other words, part of their bonus depends on what kind of feedback they receive and how clean the code delivered 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 developer to his KPI, so we decided that we would collect the invoice and conduct the results at the end of the year. 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.
It helped: this step allowed us to restore a balance between all participants in the process. The role of the “bad guy” has become as difficult as possible.
STEP 4 - How do you feel?
Now we have the perfect “system”, which proves in figures and facts that we understand the tasks correctly, write good code and can communicate with other departments. It's time to sort ourselves out to make sure we're happy. There are no global statistics on how happy people are or not in their organizations. A very frequent situation is 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. The usual feedback system. Communication is based on 7 questions, 6 of which are digitized. We ask each employee to evaluate on a 10-point scale the following parameters of his self-awareness 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 the graph, you get such a 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, together with the employee, work on this very fall.
We can build a diagram in any section (department, city, team ... etc.). The graph shows the changes of each employee and the department as a whole.
It helped:Thus, we tried to rationalize the most unsuitable part of life for this - sensations. Now we better understand how work is changing and our attitude towards it, we can try to predict the burnout of employees and react quickly enough to it, see imperfections in the system for evaluating and distributing tasks, and make appropriate changes and much more.
Many companies try to collect feedback, but not everyone knows how to work with it and change their 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, the IT department does not directly make a 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 come across some kind of difficulty, we evaluate - will the company bring or save money? It would seem: if the answer is yes, we are doing everything right, if not, you need to let go and not regret the time spent. But not everything is so one-sided. There are tasks that can’t bring direct and direct profit right now, but in the future they can have a dramatic effect on the development of the company.
Our next big step will be the development and implementation of a material assessment of each task that enters IT. We want to accustom ourselves and others to think in income and expenses, but this will take some time.
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, 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 responsibility is always on the side of the "neighbors", then simply refusing to understand each other. Therefore, the first thing that needed 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 a server in St. Petersburg, and another who was responsible for a server in Moscow. It took some time, but in general the idea that we were in the same boat was accepted by the team calmly. Then, for the tasks of supporting the business, we established a kanban, and for the tasks of developing products, we launched SCRUM teams. And if we removed the regional separation, then a command arose.
Of course, the SCRUM teams had their own retro, but in order to constantly change the interaction processes in development, we made a retro for the entire development team through video communication. Once a month, all developers and analysts (by the way, we don’t have a special role for the 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 a rating system. Regularly the question arose about retro quality of the code. If there is no system, but there are separate “good” guys who are fighting for the quality of the code, then their initiative to send colleagues examples of “kakah” laid out in the repository caused irritation or ridicule.
What did you do?
STEP 1 - Public code review
To finally understand 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 approximately the same qualifications, they themselves can 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 verification by two specialists - from Moscow and from St. Petersburg. Thus, it turned out that in order to release the task “into battle”, it must first pass a double check. We classified the code comments. In total, we have 7 classifiers. If there are comments on the code, then they are recorded in our tracker, and the task is left to the developer to correct the comments.
The first code review took place publicly. Everything is like at school: I wrote a code - brought it to the big screen, and everyone checks it. Frankly, in order to decide on this, you need enough courage and confidence in your work. But somehow we managed to carry them out, albeit with emotions and extra “steam”, but this was the first big stone in the foundation of the future system.
It helped: as a result of public code review, we managed to develop “Standards for a good code”, which everyone agreed. They change slightly over time, which is absolutely normal. The main goal is to make the audit transparent, quick 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
Pure code is great, but you won’t go 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 how to prove that we are good workers. 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 an immeasurable thing; there is no “dissatisfaction meter”. We decided to find out exactly what the customer thinks about each specific task performed by the developer.
How this happens with an example: a task is pulled onto a board. We discuss it briefly and, if the statement of the problem raises even the slightest doubts or questions, she 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 analytics stage itself has not been completed. Not. The developer conducts the analytics on such tasks independently. The analyst, in turn, either decrypts the complex task, or decomposes it, or simply removes it from the board if it suddenly lost its relevance.
If the task went into the status of "Completed", we decided to ask the customer how he was to work with a specific developer. There are only 9.5 questions in the questionnaire, which allow us to evaluate ourselves not only as professionals, but also as good employees and a department where it’s nice to contact. If the analyst also took part in the task, then we asked the analyst how he worked.
It helped : now the developer has absolutely no way to be a “bad guy” - we do a double code review, analyze tasks to discard the impossible, and interview 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 there and we could collect feedback from all participants in the chain, namely:
- After the task, the developer fills out a questionnaire for Analytics and the Customer.
- Customer for Analytics and Developer.
- Analyst for Developer and Customer.
As a result, we got a lot of information that needed to be used immediately and we began to digitize the results of these profiles. So that the whole idea does not lose its meaning, the feedback results have become part of the KPI of analysts and developers. In other words, part of their bonus depends on what kind of feedback they receive and how clean the code delivered 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 developer to his KPI, so we decided that we would collect the invoice and conduct the results at the end of the year. 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.
It helped: this step allowed us to restore a balance between all participants in the process. The role of the “bad guy” has become as difficult as possible.
STEP 4 - How do you feel?
Now we have the perfect “system”, which proves in figures and facts that we understand the tasks correctly, write good code and can communicate with other departments. It's time to sort ourselves out to make sure we're happy. There are no global statistics on how happy people are or not in their organizations. A very frequent situation is 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. The usual feedback system. Communication is based on 7 questions, 6 of which are digitized. We ask each employee to evaluate on a 10-point scale the following parameters of his self-awareness 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 you do?
- How difficult are the tasks?
- Do you have enough feedback from the head?
- Rate your satisfaction in zp.
- Assess the relationship in the team.
- Assess your understanding of the impact of your daily work on the success of the company.
If you digitize the data and put it on the graph, you get such a 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, together with the employee, work on this very fall.
We can build a diagram in any section (department, city, team ... etc.). The graph shows the changes of each employee and the department as a whole.
It helped:Thus, we tried to rationalize the most unsuitable part of life for this - sensations. Now we better understand how work is changing and our attitude towards it, we can try to predict the burnout of employees and react quickly enough to it, see imperfections in the system for evaluating and distributing tasks, and make appropriate changes and much more.
Conclusion
Many companies try to collect feedback, but not everyone knows how to work with it and change their 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, the IT department does not directly make a 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 come across some kind of difficulty, we evaluate - will the company bring or save money? It would seem: if the answer is yes, we are doing everything right, if not, you need to let go and not regret the time spent. But not everything is so one-sided. There are tasks that can’t bring direct and direct profit right now, but in the future they can have a dramatic effect on the development of the company.
Our next big step will be the development and implementation of a material assessment of each task that enters IT. We want to accustom ourselves and others to think in income and expenses, but this will take some time.
