Management of a team of programmers: how and how to motivate them correctly? Part two
Epigraph:
Husband, looking at the grimy children, says to his wife: well, what, we wash these or new ones?
Under the cut, the second part of the article of our team leader, as well as the director of RAS product development - Igor Marnat about the features of programmer motivation. The first part of the article can be found here - habr.com/en/company/parallels/blog/452598
In the first part of the article, I touched on the two lower levels of the Maslow pyramid: physiological needs, security needs, comfort and permanence and move on to the next, third level, namely:
III - The need for belonging and love
I knew that the Italian mafia is called “Cosa Nostra”, but I was very impressed when I learned how to translate “Cosa Nostra”. “Cosa Nostra” in translation from Italian - “Our business”. The choice of name is very successful for motivation (let us leave aside occupation, in this case we are only interested in motivation). A person usually wants to be part of a team, to do some big, common, our business.
Great importance is given to meeting the need for belonging and love in the army, in the navy, in any large militarized formations. And, as we see, in the mafia. This is understandable, because you need to force people who have little in common, who initially do not make up a team of like-minded people, gathered together on appeal (not voluntarily), have different levels of education, different personal values, literally devote their lives, with mortal risk, to some common cause , entrust life to a comrade in arms.
This is a very strong motivation, for most people it is extremely important to feel like belonging to something more, to know that you are part of a family, country, team. In the army, these goals are the form, various rituals, parades, marches, banners, and so on. About the same factors are important for any team. Symbols, a corporate brand and corporate colors, attributes and souvenirs are important.
It is important that significant events have a visible embodiment with which they could be associated. Now for the company to have their own attributes, jackets, t-shirts, etc. - rather the norm. But it is also important to highlight a team within the company. We often issue T-shirts based on the release results, which are issued to all those involved in this release. Any events, joint celebrations or events by the whole team is another important motivation factor.
In addition to external attributes, a few more factors influence the feeling of belonging to a team.
First, the existence of a common goal that everyone understands is shared by an assessment of its importance. Programmers usually want to understand what they do a cool thing, and they do this cool thing together, as a team.
Secondly, a team should have a communication space in which there is an entire team, and which belongs only to it (for example, a chat in the messenger, periodic team syncaps). In addition to working issues, informal communication, sometimes discussing external events, a light offtop - all this forms a sense of community and team.
Thirdly, I would single out the introduction of good engineering practices within the team, the desire to raise standards compared to those adopted by the company. Implementation of the best approaches adopted in the industry, first in the team, and then in the company as a whole, gives the team the opportunity to feel that it is ahead of others in some ways, goes at the head, this creates a feeling of belonging to a cool team.
Team ownership in planning and management also affects the sense of ownership. When team members are involved in discussing project goals, the work plan, standards and engineering practices of the team, interviewing new employees, they have a feeling of participation, joint ownership, influence on the work. People are much more willing to carry out decisions made and voiced by themselves than those proposed by others, even if they are practically consonant.
Birthdays, anniversaries, significant events in the life of colleagues - a joint pizza, a small gift from the team give a warm feeling of involvement and appreciation. In some companies, it is customary to give small commemorative signs for 5, 10, 15 years of work in the company. On the one hand, I don’t think it is so motivating for new achievements. But, obviously, almost anyone will be pleased that they have not forgotten about him. This is one of those cases where the absence of a fact rather motivates than its presence motivates. Agree, it can be rather a shame if in the morning the linkedin reminded and congratulated you on your 10th anniversary at the place of work, and not a single colleague from the company congratulated or remembered.
Of course, a significant point is the change in the composition of the team. It is clear that even if the arrival or departure of someone from the team is announced in advance (for example, in a mailing list for a company or team, or at a team meeting), this does not particularly motivate anyone to make new achievements. But if one day you see a new person next to you, or you don’t see an old one, this may come as a surprise, and if you leave, it’s really unpleasant. People should not disappear quietly. Especially in a distributed team. Especially if your work depends on a colleague from another office who suddenly picked up and suddenly disappeared. Such moments are clearly worth a separate communication within the team in advance.
An important factor in English called ownership(the literal translation “possession” does not fully reflect its meaning). This is not a feeling of ownership, but rather a sense of responsibility for your project, a feeling when you emotionally associate yourself with the product and the product with yourself. This roughly corresponds to the prayer of the Marine from the film “Full Metal Shell”: “ This is my rifle. There are many such rifles, but this one is mine. My rifle is my best friend. She is my life. I must learn to own it the way I own my life. My rifle is useless without me. I am useless without my rifle. I have to shoot my rifle aptly. I have to shoot more accurately than the enemy who is trying to kill me. I have to shoot him before he shoots me. So be it ... ".
When a person works on a product for a long time, he has the opportunity to bear full responsibility for its creation and development, to see how a working thing arises from “nothing”, how people use it, this powerful feeling arises. Product teams that work together for a long time on one project are usually more motivated and united than teams assembled for a short time and working in assembly-line mode with switching from one project to another without full responsibility for the entire product, from start to finish.
IV. Recognition need
Good word and nice to the cat. Everyone is motivated by the recognition of the importance of his work, its positive assessment. Talk with programmers, give them periodic feedback, mark a job well done. If you have a large and distributed team, periodic meetings (what is called one to one) are great for this, if the team is very small and works together locally, this feature is usually provided without special meetings on the calendar (although periodic one to one is all equally needed, you can just spend it less often). This topic is well covered in manager podcasts on manager-tools.com.
At the same time, it is worth keeping in mind cultural differences. Some approaches familiar to American colleagues will not always work with Russian ones. The level of politeness accepted in daily communication in teams in Western countries at first seems to be excessive for programmers from Russia. Some straightforwardness characteristic of Russian colleagues can be perceived as rudeness by their colleagues from other countries. This is very important in communication in an international team, a lot has been written on this topic, the manager of such a team must definitely remember this.
Demonstration of features on which programmers show features developed for sprinting is good practice for realizing this need. Besides the fact that this is a great opportunity to clear communication channels between teams, to introduce product managers and testers with new features, this is also a good opportunity for developers to show the results of their work, to indicate their authorship. Well, and polish the skills of public speaking, of course, which is always not harmful.
It would be a good idea to note the noticeable contribution of particularly distinguished colleagues with letters, memorabilia (at least with a kind word) at the team's joint parties. People usually appreciate such letters and commemorative signs, carry with them when moving, and generally take care of them in every possible way.
To mark a more significant, long-term contribution to the work of the team, accumulated experience and expertise, they often use a grade system (again, you can draw an analogy with the military rank system in the army, which, in addition to ensuring subordination, also serves for this purpose). Often young developers inject with a vengeance to get new stars on the shoulder straps (i.e. go from the junior developer to the full-time developer, etc.).
It is imperative to know your people's expectations. Someone is rather motivated by a high grade, the ability to be called, say, an architect, while someone, on the contrary, is indifferent to grades and titles and will consider an increase in salary a sign of recognition by the company. Communicate with people to understand what they want, what are their expectations.
A demonstration of recognition, a manifestation of a higher level of trust on the part of the team can serve to provide greater freedom of action or involvement in new areas of work. For example, with the accumulation of certain experience, the achievement of certain results, the programmer, in addition to implementing his features in accordance with the specification, can work on the architecture of new things. Or get involved in work on new areas that may not be directly related to development - test automation, implementation of best engineering practices, assistance in managing releases, speaking at conferences, etc.
V. The need for knowledge and self-actualization.
Many programmers are oriented at different stages of their lives to different types of activities in programming. Someone likes to engage in machine learning, develop new data models, while reading a lot of scientific literature for work, creating new ones from scratch. Debugging and support of an existing application is closer to another, in which you need to dig deep into existing code, study logs, stack tracks and network captchas for days and weeks, and hardly write new code.
Both processes require great intellectual efforts, but the practical way out is different. It is believed that programmers are reluctant to support existing solutions, they are more likely to be motivated to develop new ones. There is a healthy grain in it. On the other hand, the most motivated and close-knit team I have ever worked with was specifically supporting the existing product, finding and fixing bugs after contacting the support team. The guys literally lived this work, were ready to go on Saturdays and Sundays. We once willingly dealt with another urgent and complex problem, either in the evening of December 31, or in the afternoon of January 1.
This high motivation was influenced by several factors. Firstly, it was a company with a big name in the industry, the team associated itself with it (see “Need for Affiliation”). Secondly, they were the last frontier, there was nobody behind them, the product team was already gone at that time. Between them and the customers there were two levels of support, but if the problem reached them there is nowhere to retreat, behind no one, the whole corporation is on them (four young programmers). Thirdly, this large company had very large customers (national governments, automobile and aviation concerns, etc.) and very large-scale installations in several countries. As a result, always complex and interesting problems, simple problems were solved by supporting the previous levels. Fourth, The motivation of the team was very much influenced by the professional level of the support team with whom they interacted (there were very experienced and technically cool engineers), and we were always confident in the quality of the data they prepared, the analysis performed, etc. Fifth, and I think this is the most important moment - the team was very young, all the guys were at the beginning of their career. It was interesting for them to study a large and complex product, to solve serious new problems for them in a new environment for them, they sought to professionally meet the level of the surrounding teams, problems, and customers. The project turned out to be an excellent school, everyone then made a good career in the company and became technical leaders and senior managers, one of the guys is now a technical manager at Amazon Web Services, the other eventually moved to Google,
If this team consisted of programmers with 15-20 years of experience behind them, the motivation would be different. Age and experience are not, of course, 100% determining factors, it all depends on the structure of motivation. In this particular case, the desire for knowledge and growth of young programmers gave an excellent result.
In general, as we have repeatedly mentioned, you should know the expectations of your programmers, understand which of them would like to expand or change the scope of activities and take into account these expectations.
Outside of the Maslow pyramid: visibility of the result, gamification and competition, no bullshit
There are three more important points regarding the motivation of programmers that should be mentioned, but it would be too artificial to draw them to the model of Maslow's needs.
The first is the visibility and proximity of the result.
Software development is usually a marathon. The results of efforts in R&D become visible after months, sometimes years. It is difficult to go to a goal that is far beyond the horizon, the amount of work is terrifying, the goal is far, not clear and not visible, "the night is dark and full of horrors." It is better to split the road to it into parts, pave the way to the nearest tree, which is visible, achievable, the shape is clear, and it is not far from us - and go to this close goal. We want to make an effort of a few days or weeks, get and evaluate the result, then move on. Therefore, the work should be divided into small parts (sprints in agile serve this purpose well). They did part of the work - recorded, exhaled, discussed, punished the guilty, awarded the uninvited - you can begin the next cycle.
This motivation is to some extent similar to that experienced by players when playing computer games: they periodically receive medals, points, bonuses when passing each level, this can be called "dopamine motivation."
Moreover, the visibility of the result is literally important. A closed feature in the list should turn green. If the code is written, tested, contaminated, but there is no change in the visual status visible to the programmer, he will feel incompleteness, there will be no sense of completion. In one of the teams in our version control system, each patch went through three successive stages - the build was assembled and the tests passed, the patch passed the review code, and the patch was depleted. Each stage was visually marked with a green tick or red cross. Once, one of the developers complained that the review code lasts too long, colleagues need to speed up, patches hang for several days. I asked what, in essence, is changing for him? After all, when the code is written, the build is assembled and the tests have passed, it does not need to pay attention to the sent patch if there are no comments. Colleagues will do the review themselves and keep them down (if, again, there are no comments). He answered - “Igor, I want to get my three green checkmarks as soon as possible.”
The second point is gamification and competition.
When developing one of the products, our engineering team had the goal of taking a prominent position in the community of one of the open source products, entering top-3. At that time, there was no objective way to evaluate someone’s visibility in the community, each of the large participating companies could declare (and periodically stated) that it was number one contributor, but there was no real way to compare the contribution of the participants to each other, to evaluate its dynamics in time. Accordingly, there was no way to set a goal for the team, which could be measured in some parrots, assess the degree of achievement, etc. To solve this problem, our team has developed a tool for measuring and visualizing the contribution of companies and individual contributorswww.stackalytics.com . In terms of motivation, it turned out to be just a bomb. Not only engineers and teams constantly monitored their progress and the progress of colleagues and competitors. The top management of our company and all major competitors also began their day with stackalytics. Everything became very transparent and clear, everyone could carefully monitor their progress, compare with colleagues, etc. It has become convenient and easy to set goals for engineers, managers and teams.
An important point that arises when introducing any system of quantitative metrics is that as soon as you have implemented them, the system automatically seeks to prioritize the achievement of these quantitative metrics, to the detriment of the qualitative ones. For example, the number of code reviews performed is used as one of the metrics. Obviously, the review code can be done in different ways, you can spend several hours carefully reviewing and checking a complex patch with checking the tests, running it on your stand, checking with the documentation, and get plus one review in karma, or blindly click a couple of dozen patches, put each +1 and get in karma plus twenty. There were comical cases where engineers called patches so quickly that they set +1 automatic patches from the CI system. As we later joked, “go, go, jenkins”. In the case of commits, there were also many figures who went through the code with code formatting tools, edited comments, changed points to semicolons, and thus pumped themselves karma. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. which went through the code with code formatting tools, edited comments, changed points to semicolons, and thus pumped karma for yourself. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. which went through the code with code formatting tools, edited comments, changed points to semicolons, and thus pumped karma for yourself. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics.
And finally, the third point is No bullshit.
Developers are very smart people, and by the nature of their activity they are extremely logical. They build long and complex logical chains for 8-10 hours a day, so on the fly they see vulnerabilities in them. Doing something, they, like everyone else, want to understand why they are doing this, which will change for the better. It is important that the goals you set for the team are honest and real. Trying to sell a bad idea to a team of programmers is a bad idea. An idea is bad if you do not believe in it yourself, or, in extreme cases, you do not have an internal state of disagree and commit (I do not agree, but I will). We somehow introduced a motivation system in a company, one of the elements of which was an electronic system for providing feedback. They invested a lot of money, brought people to trainings in America, in general, they invested in full. Once, in a conversation after the training, one of the managers told his subordinates: “The idea is not bad, it seems to work. I myself will not give you electronic feedback, but give it to your people, and demand from them. ” Everything, further it was possible not to implement anything. The idea, of course, ended in nothing.
Husband, looking at the grimy children, says to his wife: well, what, we wash these or new ones?
Under the cut, the second part of the article of our team leader, as well as the director of RAS product development - Igor Marnat about the features of programmer motivation. The first part of the article can be found here - habr.com/en/company/parallels/blog/452598
In the first part of the article, I touched on the two lower levels of the Maslow pyramid: physiological needs, security needs, comfort and permanence and move on to the next, third level, namely:
III - The need for belonging and love
I knew that the Italian mafia is called “Cosa Nostra”, but I was very impressed when I learned how to translate “Cosa Nostra”. “Cosa Nostra” in translation from Italian - “Our business”. The choice of name is very successful for motivation (let us leave aside occupation, in this case we are only interested in motivation). A person usually wants to be part of a team, to do some big, common, our business.
Great importance is given to meeting the need for belonging and love in the army, in the navy, in any large militarized formations. And, as we see, in the mafia. This is understandable, because you need to force people who have little in common, who initially do not make up a team of like-minded people, gathered together on appeal (not voluntarily), have different levels of education, different personal values, literally devote their lives, with mortal risk, to some common cause , entrust life to a comrade in arms.
This is a very strong motivation, for most people it is extremely important to feel like belonging to something more, to know that you are part of a family, country, team. In the army, these goals are the form, various rituals, parades, marches, banners, and so on. About the same factors are important for any team. Symbols, a corporate brand and corporate colors, attributes and souvenirs are important.
It is important that significant events have a visible embodiment with which they could be associated. Now for the company to have their own attributes, jackets, t-shirts, etc. - rather the norm. But it is also important to highlight a team within the company. We often issue T-shirts based on the release results, which are issued to all those involved in this release. Any events, joint celebrations or events by the whole team is another important motivation factor.
In addition to external attributes, a few more factors influence the feeling of belonging to a team.
First, the existence of a common goal that everyone understands is shared by an assessment of its importance. Programmers usually want to understand what they do a cool thing, and they do this cool thing together, as a team.
Secondly, a team should have a communication space in which there is an entire team, and which belongs only to it (for example, a chat in the messenger, periodic team syncaps). In addition to working issues, informal communication, sometimes discussing external events, a light offtop - all this forms a sense of community and team.
Thirdly, I would single out the introduction of good engineering practices within the team, the desire to raise standards compared to those adopted by the company. Implementation of the best approaches adopted in the industry, first in the team, and then in the company as a whole, gives the team the opportunity to feel that it is ahead of others in some ways, goes at the head, this creates a feeling of belonging to a cool team.
Team ownership in planning and management also affects the sense of ownership. When team members are involved in discussing project goals, the work plan, standards and engineering practices of the team, interviewing new employees, they have a feeling of participation, joint ownership, influence on the work. People are much more willing to carry out decisions made and voiced by themselves than those proposed by others, even if they are practically consonant.
Birthdays, anniversaries, significant events in the life of colleagues - a joint pizza, a small gift from the team give a warm feeling of involvement and appreciation. In some companies, it is customary to give small commemorative signs for 5, 10, 15 years of work in the company. On the one hand, I don’t think it is so motivating for new achievements. But, obviously, almost anyone will be pleased that they have not forgotten about him. This is one of those cases where the absence of a fact rather motivates than its presence motivates. Agree, it can be rather a shame if in the morning the linkedin reminded and congratulated you on your 10th anniversary at the place of work, and not a single colleague from the company congratulated or remembered.
Of course, a significant point is the change in the composition of the team. It is clear that even if the arrival or departure of someone from the team is announced in advance (for example, in a mailing list for a company or team, or at a team meeting), this does not particularly motivate anyone to make new achievements. But if one day you see a new person next to you, or you don’t see an old one, this may come as a surprise, and if you leave, it’s really unpleasant. People should not disappear quietly. Especially in a distributed team. Especially if your work depends on a colleague from another office who suddenly picked up and suddenly disappeared. Such moments are clearly worth a separate communication within the team in advance.
An important factor in English called ownership(the literal translation “possession” does not fully reflect its meaning). This is not a feeling of ownership, but rather a sense of responsibility for your project, a feeling when you emotionally associate yourself with the product and the product with yourself. This roughly corresponds to the prayer of the Marine from the film “Full Metal Shell”: “ This is my rifle. There are many such rifles, but this one is mine. My rifle is my best friend. She is my life. I must learn to own it the way I own my life. My rifle is useless without me. I am useless without my rifle. I have to shoot my rifle aptly. I have to shoot more accurately than the enemy who is trying to kill me. I have to shoot him before he shoots me. So be it ... ".
When a person works on a product for a long time, he has the opportunity to bear full responsibility for its creation and development, to see how a working thing arises from “nothing”, how people use it, this powerful feeling arises. Product teams that work together for a long time on one project are usually more motivated and united than teams assembled for a short time and working in assembly-line mode with switching from one project to another without full responsibility for the entire product, from start to finish.
IV. Recognition need
Good word and nice to the cat. Everyone is motivated by the recognition of the importance of his work, its positive assessment. Talk with programmers, give them periodic feedback, mark a job well done. If you have a large and distributed team, periodic meetings (what is called one to one) are great for this, if the team is very small and works together locally, this feature is usually provided without special meetings on the calendar (although periodic one to one is all equally needed, you can just spend it less often). This topic is well covered in manager podcasts on manager-tools.com.
At the same time, it is worth keeping in mind cultural differences. Some approaches familiar to American colleagues will not always work with Russian ones. The level of politeness accepted in daily communication in teams in Western countries at first seems to be excessive for programmers from Russia. Some straightforwardness characteristic of Russian colleagues can be perceived as rudeness by their colleagues from other countries. This is very important in communication in an international team, a lot has been written on this topic, the manager of such a team must definitely remember this.
Demonstration of features on which programmers show features developed for sprinting is good practice for realizing this need. Besides the fact that this is a great opportunity to clear communication channels between teams, to introduce product managers and testers with new features, this is also a good opportunity for developers to show the results of their work, to indicate their authorship. Well, and polish the skills of public speaking, of course, which is always not harmful.
It would be a good idea to note the noticeable contribution of particularly distinguished colleagues with letters, memorabilia (at least with a kind word) at the team's joint parties. People usually appreciate such letters and commemorative signs, carry with them when moving, and generally take care of them in every possible way.
To mark a more significant, long-term contribution to the work of the team, accumulated experience and expertise, they often use a grade system (again, you can draw an analogy with the military rank system in the army, which, in addition to ensuring subordination, also serves for this purpose). Often young developers inject with a vengeance to get new stars on the shoulder straps (i.e. go from the junior developer to the full-time developer, etc.).
It is imperative to know your people's expectations. Someone is rather motivated by a high grade, the ability to be called, say, an architect, while someone, on the contrary, is indifferent to grades and titles and will consider an increase in salary a sign of recognition by the company. Communicate with people to understand what they want, what are their expectations.
A demonstration of recognition, a manifestation of a higher level of trust on the part of the team can serve to provide greater freedom of action or involvement in new areas of work. For example, with the accumulation of certain experience, the achievement of certain results, the programmer, in addition to implementing his features in accordance with the specification, can work on the architecture of new things. Or get involved in work on new areas that may not be directly related to development - test automation, implementation of best engineering practices, assistance in managing releases, speaking at conferences, etc.
V. The need for knowledge and self-actualization.
Many programmers are oriented at different stages of their lives to different types of activities in programming. Someone likes to engage in machine learning, develop new data models, while reading a lot of scientific literature for work, creating new ones from scratch. Debugging and support of an existing application is closer to another, in which you need to dig deep into existing code, study logs, stack tracks and network captchas for days and weeks, and hardly write new code.
Both processes require great intellectual efforts, but the practical way out is different. It is believed that programmers are reluctant to support existing solutions, they are more likely to be motivated to develop new ones. There is a healthy grain in it. On the other hand, the most motivated and close-knit team I have ever worked with was specifically supporting the existing product, finding and fixing bugs after contacting the support team. The guys literally lived this work, were ready to go on Saturdays and Sundays. We once willingly dealt with another urgent and complex problem, either in the evening of December 31, or in the afternoon of January 1.
This high motivation was influenced by several factors. Firstly, it was a company with a big name in the industry, the team associated itself with it (see “Need for Affiliation”). Secondly, they were the last frontier, there was nobody behind them, the product team was already gone at that time. Between them and the customers there were two levels of support, but if the problem reached them there is nowhere to retreat, behind no one, the whole corporation is on them (four young programmers). Thirdly, this large company had very large customers (national governments, automobile and aviation concerns, etc.) and very large-scale installations in several countries. As a result, always complex and interesting problems, simple problems were solved by supporting the previous levels. Fourth, The motivation of the team was very much influenced by the professional level of the support team with whom they interacted (there were very experienced and technically cool engineers), and we were always confident in the quality of the data they prepared, the analysis performed, etc. Fifth, and I think this is the most important moment - the team was very young, all the guys were at the beginning of their career. It was interesting for them to study a large and complex product, to solve serious new problems for them in a new environment for them, they sought to professionally meet the level of the surrounding teams, problems, and customers. The project turned out to be an excellent school, everyone then made a good career in the company and became technical leaders and senior managers, one of the guys is now a technical manager at Amazon Web Services, the other eventually moved to Google,
If this team consisted of programmers with 15-20 years of experience behind them, the motivation would be different. Age and experience are not, of course, 100% determining factors, it all depends on the structure of motivation. In this particular case, the desire for knowledge and growth of young programmers gave an excellent result.
In general, as we have repeatedly mentioned, you should know the expectations of your programmers, understand which of them would like to expand or change the scope of activities and take into account these expectations.
Outside of the Maslow pyramid: visibility of the result, gamification and competition, no bullshit
There are three more important points regarding the motivation of programmers that should be mentioned, but it would be too artificial to draw them to the model of Maslow's needs.
The first is the visibility and proximity of the result.
Software development is usually a marathon. The results of efforts in R&D become visible after months, sometimes years. It is difficult to go to a goal that is far beyond the horizon, the amount of work is terrifying, the goal is far, not clear and not visible, "the night is dark and full of horrors." It is better to split the road to it into parts, pave the way to the nearest tree, which is visible, achievable, the shape is clear, and it is not far from us - and go to this close goal. We want to make an effort of a few days or weeks, get and evaluate the result, then move on. Therefore, the work should be divided into small parts (sprints in agile serve this purpose well). They did part of the work - recorded, exhaled, discussed, punished the guilty, awarded the uninvited - you can begin the next cycle.
This motivation is to some extent similar to that experienced by players when playing computer games: they periodically receive medals, points, bonuses when passing each level, this can be called "dopamine motivation."
Moreover, the visibility of the result is literally important. A closed feature in the list should turn green. If the code is written, tested, contaminated, but there is no change in the visual status visible to the programmer, he will feel incompleteness, there will be no sense of completion. In one of the teams in our version control system, each patch went through three successive stages - the build was assembled and the tests passed, the patch passed the review code, and the patch was depleted. Each stage was visually marked with a green tick or red cross. Once, one of the developers complained that the review code lasts too long, colleagues need to speed up, patches hang for several days. I asked what, in essence, is changing for him? After all, when the code is written, the build is assembled and the tests have passed, it does not need to pay attention to the sent patch if there are no comments. Colleagues will do the review themselves and keep them down (if, again, there are no comments). He answered - “Igor, I want to get my three green checkmarks as soon as possible.”
The second point is gamification and competition.
When developing one of the products, our engineering team had the goal of taking a prominent position in the community of one of the open source products, entering top-3. At that time, there was no objective way to evaluate someone’s visibility in the community, each of the large participating companies could declare (and periodically stated) that it was number one contributor, but there was no real way to compare the contribution of the participants to each other, to evaluate its dynamics in time. Accordingly, there was no way to set a goal for the team, which could be measured in some parrots, assess the degree of achievement, etc. To solve this problem, our team has developed a tool for measuring and visualizing the contribution of companies and individual contributorswww.stackalytics.com . In terms of motivation, it turned out to be just a bomb. Not only engineers and teams constantly monitored their progress and the progress of colleagues and competitors. The top management of our company and all major competitors also began their day with stackalytics. Everything became very transparent and clear, everyone could carefully monitor their progress, compare with colleagues, etc. It has become convenient and easy to set goals for engineers, managers and teams.
An important point that arises when introducing any system of quantitative metrics is that as soon as you have implemented them, the system automatically seeks to prioritize the achievement of these quantitative metrics, to the detriment of the qualitative ones. For example, the number of code reviews performed is used as one of the metrics. Obviously, the review code can be done in different ways, you can spend several hours carefully reviewing and checking a complex patch with checking the tests, running it on your stand, checking with the documentation, and get plus one review in karma, or blindly click a couple of dozen patches, put each +1 and get in karma plus twenty. There were comical cases where engineers called patches so quickly that they set +1 automatic patches from the CI system. As we later joked, “go, go, jenkins”. In the case of commits, there were also many figures who went through the code with code formatting tools, edited comments, changed points to semicolons, and thus pumped themselves karma. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. which went through the code with code formatting tools, edited comments, changed points to semicolons, and thus pumped karma for yourself. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. which went through the code with code formatting tools, edited comments, changed points to semicolons, and thus pumped karma for yourself. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics. To deal with this is quite simple: we include common sense and, in addition to quantitative metrics, we also use essential, qualitative ones. The degree of use of the results of the team’s work, the number of external contributors, the level of test coverage, the stability of the modules and the whole product, the results of scale and performance testing, the number of engineers who received the core reviewer epaulets, the fact that projects were accepted as part of the core projects of the community, compliance with the criteria of different stages of the engineering process - all of these and many other factors are subject to assessment along with simple quantitative metrics.
And finally, the third point is No bullshit.
Developers are very smart people, and by the nature of their activity they are extremely logical. They build long and complex logical chains for 8-10 hours a day, so on the fly they see vulnerabilities in them. Doing something, they, like everyone else, want to understand why they are doing this, which will change for the better. It is important that the goals you set for the team are honest and real. Trying to sell a bad idea to a team of programmers is a bad idea. An idea is bad if you do not believe in it yourself, or, in extreme cases, you do not have an internal state of disagree and commit (I do not agree, but I will). We somehow introduced a motivation system in a company, one of the elements of which was an electronic system for providing feedback. They invested a lot of money, brought people to trainings in America, in general, they invested in full. Once, in a conversation after the training, one of the managers told his subordinates: “The idea is not bad, it seems to work. I myself will not give you electronic feedback, but give it to your people, and demand from them. ” Everything, further it was possible not to implement anything. The idea, of course, ended in nothing.