How to measure the effectiveness and solve the problems of developers, if you have one hundred
The question of how to evaluate the effectiveness of the development process exists as much as the development itself. Often developers can adhere to the idea that you just need to write quality code, but all these optimizations, rallies, activity tracking, and so on are managerial whim. The leaders, in turn, believe that above all else is a product and we actually have a business here, not a club of interests: so it's impossible to do without metrics. But how important are metrics at all?
In early September, we held a meeting for development managers and talked about it with people from Plesk, Avito, Dodo Pizza, Tinkov, Agima, CIAN, Yandex.Verticals, DocDoc - well, we did not forget about ourselves. Below is a squeeze from what our guests talked about.
When you manage a team of five to ten people, you become a coordinated military unit, a collective in which everyone knows everyone. Developers spend time together, work shoulder to shoulder, and often communicate outside of work. It is not difficult to join this STO team: the leader becomes a full-fledged member of the team and has the opportunity to communicate directly with each person. All conflicts, problems or difficulties that a team may encounter are clearly visible, and there is practically no administrative barrier between the service station and its subordinates.
Managing compact teams in terms of evaluating its effectiveness is much simpler: since there are not too many participants in the workflow, any ineffective solutions or methods are immediately visible. And developers easily make contact with their senior, because they communicate with him daily.
As soon as the size of the team increases several times and is not 5-10, but 50-100 people, the situation changes dramatically. Now the leader cannot personally communicate with everyone, and we need clear and effective metrics.
The first and most obvious solution is task managers and an analysis of the number of closed tasks. JIRA and similar tools can provide a specific array of useful data. For example, an analysis of closed tasks will reveal the presence of some problems without personal communication with developers.
For example, when metrics were formed in DocDoc, then initially we stopped at as many as seven indicators, but in the end there were only three:
The first metric is subjective and signaled the situation in the team and the microclimate as a whole. The second and third - related directly to the development and reflected the parameters that were important at that time: many teams had problems with meeting deadlines.
Another channel for obtaining information is questionnaires, which also should not be shy. For example, the entire Skyeng development team consists of distributed employees, and because of the difference in time zones, it is difficult to talk to each other personally physically. For us, periodic polls in the online format have become an outlet. They do not take much time, an employee can go through them when it is convenient for him, and for this you do not need to reserve slots on the calendar or a meeting room in the Moscow office.
The problem is that developers do not always talk about what worries them in time. This information can be obtained only through personal communication, so that a good CTO should have an “opening hours”, or even a conversation should be planned with all team leaders and developers in submission. Any developer should have the right to make an appointment to a higher manager, bypassing their own team lead . Otherwise, you will face the conservation of problems and their silence.
It doesn’t matter if you work in a grocery or outsourcing company. Any development always has a customer: internal or external. In some companies, it is expressed explicitly, in some - not, but there is always a customer.
Customer feedback is quite important information, as it can reveal problems that are not visible from the inside and look at the development process from the outside. If the client is completely satisfied and cannot make any comments on his interaction with the developers, then on this front everything is going more or less successfully and internal problems do not spill over from the collective.
On the other hand, a scenario is possible where, it seems, the development is moving, but according to the client’s recall it is more like a mess than a product: failure to meet deadlines, communication problems, incorrect interpretation of TK. Any of these comments is a serious reason to delve into the processes of the team and find out whether everything is really so. If the customer’s words are confirmed, then you need to look for what caused the problems.
Test results may be unexpected. So, for example, some of the questions arise due to insufficient motivation of employees: it is hard for any person to give all his best every day and at the same time not receive any incentives for their work. And in this case, do not confuse “encouragement” with “compensation” (the second is salary). In this case, both tangible and intangible stimulation is suitable: bonuses, bonuses, some corporate events and chips for employees. Even replacing equipment or fulfilling “optional” requests from subordinates can show developers that their work is valuable and is heeded. And this, in turn, will raise “morale” and productivity.
Particularly careful in this situation is to treat “support” employees who, due to their own insane efforts, close the fakaps of other team members. Such people exist in any team, and even if the team as a whole is doing well, you should not forget about the contribution of such employees. Because if they “burn out”, then everything will fly into the abyss.
The main idea of all the speeches on the topic of metrics: the truth can be achieved only in direct conversation. Metrics allow you to identify some problems at the statistical level, but it is important to remember that they show only the consequences.
Metrics can only show the fact of a problem.
But what is its essence - you need to understand on the ground. Understand through conversations, meetings, polls, that is, through direct interaction with living people. And the metrics will show you where, when and with whom you need to talk, but nothing more.
ps At the mitap, they shared their views:
* Sergey Lystsev (Plesk);
* Egor Tolstoy (Avito);
* Alexander Andronov (Dodo Pizza);
* Andrey Shelyokhin (Tinkov);
* Alexey Parshukov (Skyeng, ex-DocDoc);
* Andrey Ryzhkin (Agima);
* Alexey Chekanov (TsIAN);
* Danila Shtan (Yandex.Vertical, ex-Tochka)
Thank you very much!
pps If you are interested in listening / watching the full version of the mitap (it also includes questions of financial motivation, hiring, the level of CTO's immersion in technology, etc.) - write in a personal. The record turned out to be not very high-quality, so we did not start putting it into public: but we are always ready to share it with those who really need it.
In early September, we held a meeting for development managers and talked about it with people from Plesk, Avito, Dodo Pizza, Tinkov, Agima, CIAN, Yandex.Verticals, DocDoc - well, we did not forget about ourselves. Below is a squeeze from what our guests talked about.
In a small team, metrics are not that important
When you manage a team of five to ten people, you become a coordinated military unit, a collective in which everyone knows everyone. Developers spend time together, work shoulder to shoulder, and often communicate outside of work. It is not difficult to join this STO team: the leader becomes a full-fledged member of the team and has the opportunity to communicate directly with each person. All conflicts, problems or difficulties that a team may encounter are clearly visible, and there is practically no administrative barrier between the service station and its subordinates.
Managing compact teams in terms of evaluating its effectiveness is much simpler: since there are not too many participants in the workflow, any ineffective solutions or methods are immediately visible. And developers easily make contact with their senior, because they communicate with him daily.
With a hundred developers, things are much more complicated
As soon as the size of the team increases several times and is not 5-10, but 50-100 people, the situation changes dramatically. Now the leader cannot personally communicate with everyone, and we need clear and effective metrics.
The first and most obvious solution is task managers and an analysis of the number of closed tasks. JIRA and similar tools can provide a specific array of useful data. For example, an analysis of closed tasks will reveal the presence of some problems without personal communication with developers.
For example, when metrics were formed in DocDoc, then initially we stopped at as many as seven indicators, but in the end there were only three:
- convenience / pleasure from work ;
- the ratio of the promised and the time spent on the task;
- task life cycle time.
The first metric is subjective and signaled the situation in the team and the microclimate as a whole. The second and third - related directly to the development and reflected the parameters that were important at that time: many teams had problems with meeting deadlines.
Another channel for obtaining information is questionnaires, which also should not be shy. For example, the entire Skyeng development team consists of distributed employees, and because of the difference in time zones, it is difficult to talk to each other personally physically. For us, periodic polls in the online format have become an outlet. They do not take much time, an employee can go through them when it is convenient for him, and for this you do not need to reserve slots on the calendar or a meeting room in the Moscow office.
The problem is that developers do not always talk about what worries them in time. This information can be obtained only through personal communication, so that a good CTO should have an “opening hours”, or even a conversation should be planned with all team leaders and developers in submission. Any developer should have the right to make an appointment to a higher manager, bypassing their own team lead . Otherwise, you will face the conservation of problems and their silence.
Communication with the customer
It doesn’t matter if you work in a grocery or outsourcing company. Any development always has a customer: internal or external. In some companies, it is expressed explicitly, in some - not, but there is always a customer.
Customer feedback is quite important information, as it can reveal problems that are not visible from the inside and look at the development process from the outside. If the client is completely satisfied and cannot make any comments on his interaction with the developers, then on this front everything is going more or less successfully and internal problems do not spill over from the collective.
On the other hand, a scenario is possible where, it seems, the development is moving, but according to the client’s recall it is more like a mess than a product: failure to meet deadlines, communication problems, incorrect interpretation of TK. Any of these comments is a serious reason to delve into the processes of the team and find out whether everything is really so. If the customer’s words are confirmed, then you need to look for what caused the problems.
Test results may be unexpected. So, for example, some of the questions arise due to insufficient motivation of employees: it is hard for any person to give all his best every day and at the same time not receive any incentives for their work. And in this case, do not confuse “encouragement” with “compensation” (the second is salary). In this case, both tangible and intangible stimulation is suitable: bonuses, bonuses, some corporate events and chips for employees. Even replacing equipment or fulfilling “optional” requests from subordinates can show developers that their work is valuable and is heeded. And this, in turn, will raise “morale” and productivity.
Particularly careful in this situation is to treat “support” employees who, due to their own insane efforts, close the fakaps of other team members. Such people exist in any team, and even if the team as a whole is doing well, you should not forget about the contribution of such employees. Because if they “burn out”, then everything will fly into the abyss.
Bottom line: metrics are useless without talking to people
The main idea of all the speeches on the topic of metrics: the truth can be achieved only in direct conversation. Metrics allow you to identify some problems at the statistical level, but it is important to remember that they show only the consequences.
- The metrics will not tell you that a troll has started up in the team that poisons the situation in the team, or that they put the green guy on the team, who imagined himself to be the best team leader ever living on this planet.
- Metrics will not tell you that a recently introduced tool not only hurts all developers, but after the last update, it’s also a piece of someone’s bydlock code that is ineffective in every sense.
- Metrics will not tell you that at the stage of communication with the client and discussion of TK, such a mess is created that the team instead of the conditional “tram” started creating a “trolley bus from a loaf of bread”.
Metrics can only show the fact of a problem.
But what is its essence - you need to understand on the ground. Understand through conversations, meetings, polls, that is, through direct interaction with living people. And the metrics will show you where, when and with whom you need to talk, but nothing more.
ps At the mitap, they shared their views:
* Sergey Lystsev (Plesk);
* Egor Tolstoy (Avito);
* Alexander Andronov (Dodo Pizza);
* Andrey Shelyokhin (Tinkov);
* Alexey Parshukov (Skyeng, ex-DocDoc);
* Andrey Ryzhkin (Agima);
* Alexey Chekanov (TsIAN);
* Danila Shtan (Yandex.Vertical, ex-Tochka)
Thank you very much!
pps If you are interested in listening / watching the full version of the mitap (it also includes questions of financial motivation, hiring, the level of CTO's immersion in technology, etc.) - write in a personal. The record turned out to be not very high-quality, so we did not start putting it into public: but we are always ready to share it with those who really need it.
All Articles