How we built a training and motivation system in the studio
There are 15 people in my studio, half of whom are programmers. The studio specializes in developing online stores, so programmers are our main resource.
Three things are always required from programmers
But for various reasons, they are not always ready for this. How we motivated programmers to improve in all three areas, what difficulties they encountered and what came of it, I will tell in the article.
Weāll immediately talk about why this is important: if a programmer submits a project faster, the company earns more money on startup and, ultimately, the programmer also earns faster. Since he quickly proceeds to the next project, and the previous one goes to support and promotion. It would seem that everything is obvious, nevertheless we saw that programmers do not complete tasks and deliver projects as fast as they could, and decided to help them accelerate
The first option was to make the programmerās salary half of the salary and half of the bonuses for the project. As a result, the company and the developer will be āin the same boatā, and the success of one will directly affect the success of the second. It would seem that everything is logical, it remains only to accelerate.
What is needed to complete a project faster?
Obviously, you need to program faster. How to do it? Less distractions and everything is good to do immediately, so that you do not have to redo it.
But here we ran into another problem: programmers are not always distracted through their own fault or at will. For example, a manager can transfer a programmer to solving problems of supporting his earlier projects.
In addition, between the development and delivery of the project there is a long and problematic integration process. So the programmer received bonuses for the development of a project not yet delivered. It seemed not very logical, so we continued to look for options.
The second decision was to pay bonuses upon delivery of the project, and not upon the completion of the project.
Now, programmers have become even worse: not only related tasks influenced their receiving bonuses, but also, for example, the speed of providing customer access to integrate with payment and delivery (and sometimes it is several months), and the speed of his 1C specialists (for integration with 1C )
Also, at the programming stage, all errors of the previous steps are revealed: planning, designing, design. And the programmer has to correct them virtually for a bare salary (and he was very small in the framework of this system).
It turns out that the programmer remains without bonuses (and they are significant) through no fault of their own.
This alignment was unacceptable and the experiment with bonuses for projects had to be curtailed.
Here it is time to apologize to the development team for such experiments. I am still amazed how they all did not run away then.
The result of the experiment was the understanding that programmers are quite motivated to do the task quickly and well, if they do not interfere. And they do not need additional incentives.
I need it. A small bonus upon the completion of the project motivates the programmer not to āwork betterā (for this, in our experience, he does not need an incentive), but to delve into related fields. For example, a programmer, together with a project manager, studies design layouts before showing them to a client, looking for inconsistencies and problem areas in them. As a result, projects are much easier to program and deliver to the customer.
The ratio of salary and bonus at the same time at the level of 80/20%.
If it is impossible to deliver projects faster due to the material motivation of developers, then maybe it is worth motivating programmers to fit into their own estimates of the deadlines for tasks?
What is it about: based on estimates of the complexity of the tasks, it is planned for programmers to work ā tasks are set for the short-term (week) and long-term (1-2 months) perspective. Accordingly, if the programmer does not meet the deadline, then the whole schedule of work will fall, deadlines will move on projects dependent on him, and so on.
It is possible to reward if you have met the mark. You can be deprived, if not met.
However, both the first and second decisions suggest that the point here is solely in motivation, and not in external causes. We have already found out that programmers, if not disturbed, work as well as possible.
We began to conduct retrospectives to find out why a particular task took longer than planned in order to find ābottlenecksā either in the task itself, or in the context of its execution, or in the knowledge of the programmer.
This helped, tasks began to be done more often in the allotted time. It became obvious that you need to find out about protracted tasks before they drop out of the deadline.
For this, we came up with "preliminary retrospectives." When more than half of the time allotted for the task has passed, and the task is still not close to half, the programmer informs the manager about this, and together they look for the reasons.
The task was initially incorrectly evaluated.
Either the complexity was incorrectly assessed, or the solution chosen during the evaluation did not fit in the end. This means that the programmer has a knowledge gap in a particular area. Important! This information is used for training and not for punishing the programmer.
The task is overgrown with details along the way.
If the details came from the customer and at the start they were not obvious, then the programmer corrects the assessment, and the manager sells the missing hours and shifts the deadline.
If the details were obvious, but the manager missed them
That already speaks about the gaps in the knowledge of the manager. We understand that the manager must study so that similar problems no longer arise.
I need it. We consider the prize for the number of hours sold to the customer and worked out by the programmer. The goal remains the same: being motivated to give an accurate assessment, the programmer delves deeper into the task, sometimes directing it to clarification, sometimes offering its own versions.
At the retrospective stage, we find gaps in the knowledge of programmers. But how to get them to study and close these gaps?
We are located in Krasnodar, and here in general there is one ecommerce studio (in fact, we). This means that there is nowhere to take ready-made personnel from. And everyone needs to either grow from scratch, or "grow" from the level that they had in other studios.
Thus, we have 5 areas of competence. Each of them has a certain set of skills from which a programmerās competency map is formed. It determines the division of developers into levels (Trainee, Junior, Middle, Senior).
As the level rises, salary increases.
The first idea was to give developers a map of competencies and methodological materials and offer ourselves to develop on it.
At Bitrix24, we started automatic tasks in which everyone had to report on progress in training.
And then I ran into the first problem. For some reason, programmers did not want to study and did not want to grow on the competency map.
After a couple of months of futile attempts, I guessed to ask them: what is wrong?
It turned out that there is too much difference in competencies between different levels. And she does not motivate to study.
Then I decided to break down the levels into several levels (as a percentage of the studied competency map). And for each level to give a small increase in salary.
It got a little better. Programmers reached out to study and take exams. But still too slow.
The following problem became clear: there is neither time nor energy to study materials at home, and at work, programmers are loaded with tasks. So those who have half a day of free self-education advanced on the competency map, and those who do not have remained at the same level, which coolly demotivated them.
Give out free time. Between tasks, programmers began to leave several hours a week for training.
And this one worked. Programmers began to engage in self-development, take tests and grow in salaries.
Those who are not ready to study under the allotted time and growth prospects should simply be left alone. There are people who are comfortable at their level and if they can close some tasks, then why not?
In our experience, programmers have enough internal motivation, and if they are not disturbed, they work as well as possible.
The awards serve as an additional motivator not so much for the quality of work as for immersion in the work of related specialists (search for problem areas in design and TK before it is finally agreed).
All learning tools are meaningless unless there are two important things. Feelings of progress (including achievable rewards) and the time allotted for this. Believe me, when a programmer, having barely managed to close the task in a day, gets to his home from work an hour, then after that he is absolutely not up to your ādevelopment planā. And Iām reasoning that āyouāll learn now and you will have free timeā will give rise to only one silent reaction: āI donāt believeā.
Three things are always required from programmers
- Faster to hand over projects.
- Stay in your own assessment of labor costs.
- Grow and develop
But for various reasons, they are not always ready for this. How we motivated programmers to improve in all three areas, what difficulties they encountered and what came of it, I will tell in the article.
How do we start to submit projects faster
Weāll immediately talk about why this is important: if a programmer submits a project faster, the company earns more money on startup and, ultimately, the programmer also earns faster. Since he quickly proceeds to the next project, and the previous one goes to support and promotion. It would seem that everything is obvious, nevertheless we saw that programmers do not complete tasks and deliver projects as fast as they could, and decided to help them accelerate
How motivated
First stage
The first option was to make the programmerās salary half of the salary and half of the bonuses for the project. As a result, the company and the developer will be āin the same boatā, and the success of one will directly affect the success of the second. It would seem that everything is logical, it remains only to accelerate.
What is needed to complete a project faster?
Obviously, you need to program faster. How to do it? Less distractions and everything is good to do immediately, so that you do not have to redo it.
But here we ran into another problem: programmers are not always distracted through their own fault or at will. For example, a manager can transfer a programmer to solving problems of supporting his earlier projects.
In addition, between the development and delivery of the project there is a long and problematic integration process. So the programmer received bonuses for the development of a project not yet delivered. It seemed not very logical, so we continued to look for options.
Second phase
The second decision was to pay bonuses upon delivery of the project, and not upon the completion of the project.
Now, programmers have become even worse: not only related tasks influenced their receiving bonuses, but also, for example, the speed of providing customer access to integrate with payment and delivery (and sometimes it is several months), and the speed of his 1C specialists (for integration with 1C )
Also, at the programming stage, all errors of the previous steps are revealed: planning, designing, design. And the programmer has to correct them virtually for a bare salary (and he was very small in the framework of this system).
It turns out that the programmer remains without bonuses (and they are significant) through no fault of their own.
This alignment was unacceptable and the experiment with bonuses for projects had to be curtailed.
Here it is time to apologize to the development team for such experiments. I am still amazed how they all did not run away then.
The result of the experiment was the understanding that programmers are quite motivated to do the task quickly and well, if they do not interfere. And they do not need additional incentives.
So is material motivation necessary in this case?
I need it. A small bonus upon the completion of the project motivates the programmer not to āwork betterā (for this, in our experience, he does not need an incentive), but to delve into related fields. For example, a programmer, together with a project manager, studies design layouts before showing them to a client, looking for inconsistencies and problem areas in them. As a result, projects are much easier to program and deliver to the customer.
The ratio of salary and bonus at the same time at the level of 80/20%.
We motivate to fit into your assessment of labor costs
If it is impossible to deliver projects faster due to the material motivation of developers, then maybe it is worth motivating programmers to fit into their own estimates of the deadlines for tasks?
What is it about: based on estimates of the complexity of the tasks, it is planned for programmers to work ā tasks are set for the short-term (week) and long-term (1-2 months) perspective. Accordingly, if the programmer does not meet the deadline, then the whole schedule of work will fall, deadlines will move on projects dependent on him, and so on.
How to help the programmer keep within the planned time frame?
It is possible to reward if you have met the mark. You can be deprived, if not met.
However, both the first and second decisions suggest that the point here is solely in motivation, and not in external causes. We have already found out that programmers, if not disturbed, work as well as possible.
We began to conduct retrospectives to find out why a particular task took longer than planned in order to find ābottlenecksā either in the task itself, or in the context of its execution, or in the knowledge of the programmer.
This helped, tasks began to be done more often in the allotted time. It became obvious that you need to find out about protracted tasks before they drop out of the deadline.
For this, we came up with "preliminary retrospectives." When more than half of the time allotted for the task has passed, and the task is still not close to half, the programmer informs the manager about this, and together they look for the reasons.
So, because of what you can not meet the deadline for the task
The task was initially incorrectly evaluated.
Either the complexity was incorrectly assessed, or the solution chosen during the evaluation did not fit in the end. This means that the programmer has a knowledge gap in a particular area. Important! This information is used for training and not for punishing the programmer.
The task is overgrown with details along the way.
If the details came from the customer and at the start they were not obvious, then the programmer corrects the assessment, and the manager sells the missing hours and shifts the deadline.
If the details were obvious, but the manager missed them
That already speaks about the gaps in the knowledge of the manager. We understand that the manager must study so that similar problems no longer arise.
But do you need financial motivation here
I need it. We consider the prize for the number of hours sold to the customer and worked out by the programmer. The goal remains the same: being motivated to give an accurate assessment, the programmer delves deeper into the task, sometimes directing it to clarification, sometimes offering its own versions.
Training of programmers and motivation for development
At the retrospective stage, we find gaps in the knowledge of programmers. But how to get them to study and close these gaps?
We are located in Krasnodar, and here in general there is one ecommerce studio (in fact, we). This means that there is nowhere to take ready-made personnel from. And everyone needs to either grow from scratch, or "grow" from the level that they had in other studios.
What a programmer should know
- Frontend
- Backend
- Engine
- Integration (1C and so on)
- Linux, Nginx, Apache
Thus, we have 5 areas of competence. Each of them has a certain set of skills from which a programmerās competency map is formed. It determines the division of developers into levels (Trainee, Junior, Middle, Senior).
As the level rises, salary increases.
How we raised developers
Hypothesis 1
The first idea was to give developers a map of competencies and methodological materials and offer ourselves to develop on it.
At Bitrix24, we started automatic tasks in which everyone had to report on progress in training.
And then I ran into the first problem. For some reason, programmers did not want to study and did not want to grow on the competency map.
After a couple of months of futile attempts, I guessed to ask them: what is wrong?
It turned out that there is too much difference in competencies between different levels. And she does not motivate to study.
Hypothesis 2
Then I decided to break down the levels into several levels (as a percentage of the studied competency map). And for each level to give a small increase in salary.
It got a little better. Programmers reached out to study and take exams. But still too slow.
The following problem became clear: there is neither time nor energy to study materials at home, and at work, programmers are loaded with tasks. So those who have half a day of free self-education advanced on the competency map, and those who do not have remained at the same level, which coolly demotivated them.
Hypothesis 3
Give out free time. Between tasks, programmers began to leave several hours a week for training.
And this one worked. Programmers began to engage in self-development, take tests and grow in salaries.
Those who are not ready to study under the allotted time and growth prospects should simply be left alone. There are people who are comfortable at their level and if they can close some tasks, then why not?
findings
In our experience, programmers have enough internal motivation, and if they are not disturbed, they work as well as possible.
The awards serve as an additional motivator not so much for the quality of work as for immersion in the work of related specialists (search for problem areas in design and TK before it is finally agreed).
All learning tools are meaningless unless there are two important things. Feelings of progress (including achievable rewards) and the time allotted for this. Believe me, when a programmer, having barely managed to close the task in a day, gets to his home from work an hour, then after that he is absolutely not up to your ādevelopment planā. And Iām reasoning that āyouāll learn now and you will have free timeā will give rise to only one silent reaction: āI donāt believeā.
All Articles