Motto:
The husband, looking at the grimy children, says to his wife: well, shall we wash these or give birth to new ones?
Under the cut, the second part of the article by our team leader, as well as RAS product development director - Igor Marnat, about the features of programmer motivation. The first part of the article can be found here -
In the first part of the article, I touched on the two lower levels of Maslow's pyramid: physiological needs, needs for security, comfort and constancy and move on to the next, third level, namely:
III - Need for belonging and love
I knew that the Italian mafia was called “Cosa Nostra”, but I was very impressed when I learned how “Cosa Nostra” is translated. “Cosa Nostra” in Italian means “Our business”. A very good choice of name for motivation (we leave aside the 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 attached to satisfying the need for belonging and love in the army, in the navy, in any large paramilitary 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, are brought together by conscription (not voluntarily), have different levels of education, different personal values, literally devote their lives, at 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 belonging to something more, to know that you are part of a family, a country, a team. In the army, uniforms, various rituals, parades, marches, banners, and so on serve these purposes. Roughly the same factors are important for any team. Symbols, corporate brand and corporate colors, paraphernalia and souvenirs are important.
It is important that significant events have their own visible embodiment with which they could be associated. Now for a company to have its own merchandise, jackets, T-shirts, etc. is rather the norm. But it is also important to highlight the team within the company. We often release t-shirts based on the results of the release, which are given to all those who are involved in this release. Some events, joint celebrations or activities by the whole team are another important motivation factor.
In addition to external attributes, there are several other things that affect the feeling of belonging to a team.
First, the presence of a common goal that everyone understands, shares an assessment of its importance. Programmers usually want to understand that they are doing a cool thing, and they are doing this cool thing together, as a team.
Secondly, the team must have a space for communication, in which the whole team has, and which belongs only to it (for example, a chat in the messenger, periodic team syncaps). In addition to work issues, informal communication, sometimes discussion of external events, light offtopic - all this forms a sense of community and team.
Thirdly, I would highlight the introduction of good engineering practices within the team, the desire to raise standards compared to those accepted in the company. Implementing the best practices 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 way, it leads, this creates a sense of belonging to a cool team.
The sense of belonging is also affected by team participation in planning and management. When team members are involved in discussing the project goals, work plan, team standards and engineering practices, interviewing new employees, they have a sense of participation, joint ownership, influence on the work. People are much more willing to implement decisions made and voiced by themselves than 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 sense of belonging 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 that this motivates me so much 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 demotivates rather than its presence motivates. Agree, it can be quite disappointing if linkedin reminded you in the morning and congratulated you on your 10th anniversary at your place of work, but not a single colleague from the company congratulated or remembered.
Of course, a significant moment 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 new achievements. But if one day you see a new person next to you, or you don’t see an old one, it can come as a surprise, and if you leave, it can be downright unpleasant. People shouldn't disappear quietly. Especially in a distributed team. Especially if your work depends on a colleague from another office, who suddenly took it and suddenly disappeared. Such moments definitely deserve separate information within the team in advance.
An important factor, which in English is called ownership (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, that feeling when you emotionally associate yourself with the product and the product with yourself. This roughly corresponds to the Marine's prayer in the movie Full Metal Jacket: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 her just as I own my life. Without me, my rifle is useless. I am useless without my rifle. I have to shoot my rifle accurately. I must shoot more accurately than the enemy who is trying to kill me. I have to shoot him before he shoots me. Let it be so… ".
When a person works on a product for a long time, 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 the same project are usually more motivated and cohesive than teams that are assembled for a short time and work in assembly line mode, switching from one project to another, without having full responsibility for the entire product, from start to finish.
IV. Need for recognition
A kind word and a cat is pleased. Everyone is motivated by the recognition of the importance of the work done by him, its positive assessment. Talk to 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 work together locally, this opportunity is usually provided without special calendar meetings (although periodic one to one is all still needed, you can just spend it less often). This topic is well covered in the podcasts for managers at manager-tools.com.
At the same time, cultural differences should be kept in mind. Some approaches familiar to American colleagues will not always work with Russian ones. The level of courtesy adopted in daily communication in teams in Western countries at first seems redundant to 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.
Feature demos, where programmers demonstrate features developed during the sprint, are a good practice to fulfill this need. In addition to the fact that this is a great opportunity to clear communication channels between teams, introduce product managers and testers to new features, it is also a good opportunity for developers to show the results of their work, to indicate their authorship. Well, to polish the skills of public speaking, of course, which is always not harmful.
It would be a good idea to celebrate the significant contribution of particularly distinguished colleagues with certificates, commemorative signs (at least with a kind word) at joint team parties. People usually appreciate such certificates and commemorative signs, carry them with them when moving, and generally cherish them in every possible way.
To celebrate a more significant, long-term contribution to the work of the team, accumulated experience and expertise, a grading system is often used (again, you can draw an analogue with the military rank system in the army, which, in addition to ensuring subordination, also serves this purpose). Often, young developers work hard to get new stars for shoulder straps (ie move from junior developer to full-time developer, etc.).
It is essential to know the expectations of your people. Someone is more likely to be motivated by a high grade, the opportunity to be called, say, an architect, while someone, on the contrary, is indifferent to grades and titles and will consider a salary increase as a sign of recognition from the company. Communicate with people to understand what they want, what their expectations are.
A demonstration of recognition, a manifestation of a higher level of trust on the part of the team, may be the provision of 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 new areas that may not be directly related to development - test automation, implementation of best engineering practices, help with release management, 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 do machine learning, develop new data models, while reading a lot of scientific literature for work, creating something new from scratch. Another is closer to debugging and maintaining an existing application, in which you need to dig deep into the existing code, study logs, stack traces and network captchas for days and weeks, and almost never write new code.
Both processes require great intellectual effort, but their practical output is different. It is believed that programmers are reluctant to maintain existing solutions, they are rather motivated to develop new ones. There is a healthy grain in this. On the other hand, the most motivated and cohesive team that I have ever worked with was engaged in the support of an existing product, finding and fixing bugs after a call from the support team. The guys literally lived this work, were ready to go out on Saturdays and Sundays. We once willingly dealt with another urgent and complex problem either on the evening of December 31, or on the afternoon of January 1.
Several factors contributed to this high motivation. First, it was a company with a big name in the industry, the team associated itself with it (see “The Need for Belonging”). Secondly, they were the last frontier, there was no one behind them, the product team was no longer there at that time. There were two levels of support between them and the customers, but if the problem reached them, there was nowhere to retreat, no one was behind, the whole corporation was 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 the support of the previous levels. Fourthly, the motivation of the team was greatly influenced by the professional level of the support team they interacted with (there were very experienced and technically cool engineers), and we were always confident in the quality of the data they prepared, the analysis they carried out, etc. Fifth, and I think this is the most important point - the team was very young, all the guys were at the beginning of their careers. They were interested in studying a large and complex product, solving serious problems that were new to them in a new environment for them, they sought to professionally correspond to the level of surrounding teams, problems, and customers. The project turned out to be a great 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, and all of them still remember this project with warmth .
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 must know the expectations of your programmers, understand which of them would like to expand or change the field of activity, and take these expectations into account.
Beyond Maslow's Pyramid: Visibility, Gamification and Competitiveness, No Bullshit
There are three other important points about the motivation of programmers that should definitely be mentioned, but drawing them into the Maslow model of needs would be too artificial.
The first is the visibility and proximity of the result.
Software development is usually a marathon. The results of R&D efforts 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 away, not clear and not visible, “the night is dark and full of horrors.” It is better to break the road to it into parts, make a path to the nearest tree that is visible, achievable, the outlines are 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, work should be broken down into small parts (agile sprints serve this purpose well). We have done part of the work - fixed it, exhaled it, discussed it, punished the guilty, rewarded the uninvolved - you can start the next cycle.
This motivation is to some extent similar to what players experience when playing computer games: they periodically receive medals, points, bonuses when passing each level, this can be called “dopamine motivation”.
At the same time, the visibility of the result is literally important. A closed feature in the list should turn green. If the code is written, tested, merged, but there is no visible change in the visual status for the programmer - he will feel incomplete, there will be no sense of completeness. 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 code review, the patch was merged. Each stage was visually marked with a green tick or a red cross. Once one of the developers complained that the review code takes too long, colleagues need to speed up, patches hang for several days. I asked what this, in essence, changes for him? After all, when the code is written, the build has assembled and the tests have passed, he does not need to pay attention to the sent patch if there are no comments. Colleagues themselves will make a review and kill (if, again, there are no comments). He replied - "Igor, I want to get my three green ticks as soon as possible."
The second point is gamification and competition.
When developing one of the products, our engineering team had a goal to take a prominent position in the community of one of the open source products, to enter the 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 claim (and periodically stated) that it was the number one contributor, but there was no real way to compare the contribution of participants among themselves, to evaluate its dynamics in time. Accordingly, there was no way to set a goal for the team that could be measured in some parrots, assess the degree to which it was achieved, and so on. To solve this problem, our team has developed a tool to measure and visualize the contribution of companies and individual contributors. . 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 started their day with stackalytics. Everything became very transparent and visual, everyone could carefully track their progress, compare it with colleagues, etc. It has become convenient and easy to set goals for engineers, managers and teams.
An important point that arises when implementing any system of quantitative metrics is that once you have implemented them, the system automatically tends to prioritize the achievement of these quantitative metrics, to the detriment of qualitative ones. For example, one of the metrics is the number of completed code reviews. Obviously, the code review can be done in different ways, you can spend several hours on a thorough review and checking a complex patch with checking tests, running it on your bench, checking with the documentation, and get plus one review in karma, or blindly click a couple of dozens in a couple of minutes patches, put each +1 and get karma plus twenty. There have been comical cases where engineers have clicked on patches so fast that they have given +1 to 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 dots to commas and thus pumped karma for themselves. It is quite simple to deal with this: we turn on 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 modules and the entire product, the results of scale and performance testing, the number of engineers who received core reviewer shoulder straps, the fact that projects were accepted into the core projects community, compliance with the criteria for different stages of the engineering process - all these and many other factors are to be assessed along with simple quantitative metrics.
And finally, the third point - 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 they see vulnerabilities in them on the fly. When doing something, they, like everyone else, want to understand why they are doing it, what will change for the better. It is mega important that the goals you set for the team are honest and realistic. Trying to sell a bad idea to a programming team is a bad idea. The 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 once implemented a motivation system in a company, one of the elements of which was an electronic system for providing feedback. We invested a lot of money, took people to trainings in America, in general, invested in full. Once, in a conversation after the training, one of the managers said to his subordinates: “The idea is not bad, it seems to work. I myself will not give you electronic feedback, but you give your people, and demand from them. Everything, it was possible to implement nothing further. The idea, of course, ended in nothing.
Source: habr.com