Management of a team of programmers: how and how to motivate them correctly? Part one

    Epigraph:
    Husband, looking at the grimy children, says to his wife: well, what, we wash these or new ones?


    Under the cut of our team leader’s discussion, as well as Igor Marnat, director of RAS product development, about the features of programmer motivation.

    image
    The secret to success in creating cool software products is well known - take a team of cool programmers, give the team a cool idea and don’t interfere with the team working. Cool developers are rare and sought after guys. Some recruiters even say that they get the impression that giving birth to a cool programmer is easier than hiring him from the market. In addition to difficulties with hiring, as such, the experience of each specific developer, his knowledge of an existing product and the history of its development are often irreplaceable or are replenished hard and long. Therefore, if you are lucky and you already have a cool team of programmers, it is important to work on their motivation. Hiring, training new developers, making a team out of them is almost as difficult and long as giving birth and raising children.

    Consider the main factors motivating programmers (teams of programmers), using the Maslow pyramid for clarity and structuring of the presentation. If suddenly you have not heard about the Maslow pyramid, this is not an indisputable, but very popular and visual theory of the American psychologist Abraham Harold Maslow, who proposed a theory of personality motivation based on a hierarchy of human needs (see picture below).

    Maslow arranged the needs of the individual in a hierarchical order, from physiological needs to the need for unlocking potential and self-actualization. A key assumption in Maslow’s theory is: “A person cannot experience the needs of a higher level until his needs of a lower level are satisfied.” For example, a person cannot be driven by the need for knowledge or aesthetic needs, if this person did not sleep or eat for three days.

    image

    Before delving into the details, let us dwell on the obvious fact - the team consists of people, all people are different, each has its own structure of motivation. In addition to the fact that each person is driven by different interests, each person is also in different living conditions. Someone is at the beginning of a career and is thinking about how to build it, someone is going to get married, and someone wants to learn a new subject area. What is important for one is completely unimportant for the other, and tomorrow everything will change again. In order to correctly understand this context, there is a simple means - you need to think about it and you need to work with it. The most important thing is communication.
    Be sure to talk with your team about something other than work, build an informal relationship.

    So, now let's go through the Maslow pyramid and consider its levels as applied to managing a team of programmers.

    I: Physiological, biological needs:

    Speaking of motivation, many, in the first place, often think about wages. In this case, I mean by salary the constant part of the compensation package, which does not depend on the results. This does not apply to bonuses, bonuses and promotions of the company. I would attribute the salary to the level of “physiological needs” in our case. Bonuses, bonuses according to the results of work, options and shares of the company - all this I would refer to other levels.

    In my opinion, oddly enough it may sound, the salary is more likely to be demotivatingfactor than motivating. The peculiarity of working with programmers is that they are all people, firstly, very smart (a feature of the profession), and secondly, deeply and / or widely educated. Typically, programmers, in addition to their profession, are deeply versed in one or more of the subject areas for which they create products. In addition, good programmers are interested and well aware of the history of programming, algorithms, standards, etc. The same applies to their subject area. For people of this level, salary is usually not the main motivating factor.

    At the same time, the lack of a fair salary for programmers in their understanding demotivates, and demotivates strongly. Having a fair salary is the norm. Salary is much higher than the norm (market) - also, oddly enough, the factor is rather demotivating. One colleague once told me about a team of programmers in one of the large animated American companies, which, for several reasons, received salaries at the level of two to three times the market. As he said, he had never seen more fed up, lazy and demotivated programmers in his life. The fact that a salary increase can motivate short-term, but after a few months, a new salary becomes the norm and ceases to motivate. In general, I would say that for programmers at the beginning of a career, the salary factor is more important, as they grow professionally and develop - its importance decreases,

    The second important point is the presence of a fair balance in the level of salaries in the team. If the team feels that the contribution of one of the participants is noticeably lower, but the compensation level is not different, this will demotivate the whole team. Sometimes managers are tempted to flood the fire with money - to keep a burned out or demotivated person, raising his salary above the norm. This usually only creates problems in the long run - the motivation of the person himself will not especially grow, or grow by a couple of months, but the motivation of the rest of the team will drop. In such situations, it is worth looking for other approaches, unless, of course, this is a unique specialist who needs to be kept at all costs, even for a short time.

    II. The need for security, comfort, constancy of living conditions:

    70 years ago, the presence of a stove in a car could be a motivating factor when choosing a car, then it was above the norm, it was a sign of luxury. Now even the absence of an air conditioner is nonsense, and its presence will not be a motivating factor when choosing a car. So 10-15 years ago, a convenient office, good iron, delicious coffee, fitness, a flexible schedule, etc. could be good motivating factors, but now it’s rather the norm for a good programmer to work. At the same time, their absence, again, will demotivate.

    An important demotivating factor is the lack of ability to concentrate, a noisy working environment. The work of a programmer requires silence and concentration. If the office space does not provide an opportunity to provide developers with a secluded workplace, it is necessary to at least ensure comfortable collaboration between colleagues who do not interfere with each other. It is better to unite energetic and loud comrades with each other, making it possible for those who need it to concentrate.

    The cost of the programmer’s time is now noticeably higher than the cost of the iron on which he works. Two or three monitors, powerful computers, a convenient workplace for each developer - should be the norm in any company. This topic is well disclosed in one of Joel Spolsky’s articles “ The Joel Test: 12 steps to better code”.

    The physical component of comfort is the most basic and simple, now let's talk about the rest.

    In many companies, the norm for programmers to work is a flexible work schedule and lack of dress code. This is good and correct if the features of the team allow (for example, there are no meetings with customers, politicians or bankers).

    An important point is the presence of a specific time window, when the whole team works together locally, so that people can communicate and resolve issues in person. The programmer, in fact, does not leave work even after work. Typically, working moments scroll in his mind, regardless of his presence in the office, and good decisions often come outside of him. Given the need to be good (which we dwell on below), petty control is harmful. Not only does it demotivate, it also reduces performance. As practice shows, in the absence of control, a motivated team is likely to work longer than necessary. With control, developers can sit at the keyboard from nine to six, but the result, I think, will be worse. As they say, one person can bring a horse to a watering place, but even a hundred will not make him drink if he does not want to.

    In the description of this level of needs, freedom from anxiety and fear, the absence of chaos, the need for structure and order are also mentioned. These are also extremely important points that greatly affect the atmosphere in the team.

    Firstly, the absence of chaos, structure and order - the team must understand who is responsible for what, how the roles are allocated, what to do, who, when, what requirements are at the heart of the product, what are the expectations of the bosses and the customer ... Most of this should be formally described, everything should be periodically discussed. Without discussion and periodic use, descriptions do not work. It’s good practice to periodically review and update them after postmortem analysis after release.

    Secondly, a calm and friendly atmosphere. We all spend most of our time at work, and we want to do it without stress, conflict, or fear. The development team already usually works under pressure from the schedule and customers. No one needs additional stress from colleagues and superiors. The atmosphere in the team, in general, the fact that a development group can be called and be a “team” is the direct and important responsibility of the manager, one of the most important medium and long-term tasks. Therefore, it is important for the manager to work, in particular, with conflicts in the team, not to let their development drift. Conflict management is a separate topic that deserves a separate study.

    There are two main ways to influence the emotional state of a team, the behavior of colleagues (if someone adds in the comments, it will be fine). The first is their own behavior. A personal example is super important for the manager and team. As they say, what is pop, such is the parish. Behave as you expect your colleagues to behave. The second is the promotion of correct behavior, and, so to speak, the de-promotion of wrong. Communicate with people, give them feedback, there are many ways to do this. In general, feedback is a topic for another discussion, it is a large and important part of working with motivation.

    Another remark about the atmosphere, which may seem unusual, but in practice it is important. More often than not, there are fewer girls in the development team than men. Often teams are completely male. In such conditions, also under load, sometimes obscene vocabulary begins to be used in the team. Practice shows that this affects the atmosphere negatively, communication gradually becomes rude. You should avoid using it yourself and not encourage its use in a team.

    Development teams are often called R&D (research and development), and research is a significant part of the work. This is the part that is usually difficult to program and plan, otherwise it would not be research. It is important that the team has the right to make a mistake, to take the initiative, to try out different options that may end in success, or may not end. Mistakes are a normal part of the work, they cannot be avoided, but you can study, analyze, learn from them for the future and move on. Principle 5 why's, which originated in Toyota, helps to get to the root cause of the problem. Punishing mistakes is a great way to create an atmosphere of fear and insecurity. The only exception is when, according to the results of the analysis, it turns out that the error is caused by an unprofessional attitude to work, in this case, perhaps

    The atmosphere in the team is very influenced by your expectations, the emotional state before the conversation begins. Before starting a difficult discussion, some sort of debriefing, or just an emotional conversation, your attitude, attitude to the person with whom you are going to talk, is important. I always think by default and act on the basis of what a person sincerely tried to do the best. If you see that this is not the case, you need to calmly and thoroughly find out the context and understand what he did right, why he thought it was right, and where our expectations diverge. Usually it turns out that they don’t really diverge, just his vision of the context is more complete or fresh, and you didn’t know something. Or, on the contrary, he did not know something. This is especially important in a distributed team, when people are less likely to communicate in person, use mail and instant messengers. This is even more critical in a team consisting of programmers from different countries and distributed between different time zones. Here, cultural differences begin to play a large role.

    In a difficult situation, moving on the fly is simple, very simple, but then it’s hard to pull back and the sediment remains for a long time. I will give a simple example from recent experience. One of the team managers urgently needed comments about a customer’s problem from a manager from an adjacent team from another country. He pinged a colleague in the messenger, waited 15 minutes, pinged again, then 15 minutes later went into a big chat in which there were other managers, and lightly ran into a colleague, with the wording like: “since you do not deign to answer me, maybe , and the question is not so urgent? ”. As a result, it turned out that our corporate messenger was a little dull, and the colleague did not see the question at all. I had to apologize. In general, it is better to start from the good. It’s always possible to make a mistake in the bad direction and run over later, There are no problems with this (although you should not do this). In general, for more than 20 years of work in our industry, I met a really malicious colleague only one (!) Time. Fortunately, we broke up pretty quickly. The assumption that colleagues want the best, to the best of their vision of the context, is correct in the vast majority of cases.

    Your task as a manager is to ensure synchronization of contexts, a common understanding of the expectations, requirements, and deadlines adopted by the team of standards. It may seem like trifles, but the atmosphere in the team is built precisely from such trifles. From the point of view of a distributed team, one of the important tasks is to ensure periodic personal communication of team members. I have often heard from programmers that after, for example, the engineers of the support team came to them and worked together in person, they happily stayed at work to help in a difficult case personally to Pasha, who recently visited them, although earlier Pasha was just an icon in the messenger, and no one would linger for the sake of the icon.

    By the way, I talked about the support team and remembered a canonical example for me. Somehow, one of the customers in America had a problem with the product, one of the support team engineers who worked on his implementation (sent from Russia) remained after work to help, but the problem was not solved and was not solved. In general, he lingered and sat there almost until the morning. At this time, customer managers escalated the problem, identified its criticality for them, and left work in the evening. The escalation process was gaining momentum already in another time zone, support managers in Russia began to try to help, due to certain difficulties in communicating with the customer’s office (VPN, communication problems, difficulties with calls between countries, ...) they did not know that the guy was already sitting in the office and solves the issue, and tried to find him. Found only in the morning (American), when the issue was already practically resolved by him, and the product earned. They began to run into the quarry, what the hell, the customer has such an escalation, nothing works, where he bears you, we cannot find you, etc. Needless to say, as a result of such behavior, the guy was very demotivated. Organizing a distributed team is a separate big topic, but there are two things to keep in mind. First of all, communication, atmosphere is very important, the success of work depends on it. Secondly, this does not work on its own, it must be dealt with separately and in depth. that as a result of such behavior, the guy was very demotivated. Organizing a distributed team is a separate big topic, but there are two things to keep in mind. First of all, communication, atmosphere is very important, the success of work depends on it. Secondly, this does not work on its own, it must be dealt with separately and in depth. that as a result of such behavior, the guy was very demotivated. Organizing a distributed team is a separate big topic, but there are two things to keep in mind. First of all, communication, atmosphere is very important, the success of work depends on it. Secondly, this does not work on its own, it must be dealt with separately and in depth.

    Another important point related to this level of needs is salary again. Not the size of the salary, as such, but the existence of a certain order of its change. The company should have an approach to determining the requirements for positions at different levels. Each developer should be able to discuss expectations for his work with the company, to understand how he and when his efforts can affect his salary. Periodic meetings with the manager, semi-annual or annual certifications serve this purpose. This, again, is one of those moments whose presence does not explicitly motivate, but their absence strongly motivates.

    From the need for order and the availability of rules, it follows the need to comply with these rules, to follow the rules adopted by the team, both formal and informal. Generally, I would call her the need to "be good." The presence of this need confirms that micromanagement is not needed, rather harmful. It is enough to provide a person with everything necessary for work, give him knowledge of the context, priorities, and provide freedom of action and decision-making at his level. In such circumstances, he will feel confidence, the ability to make his own decisions, bear responsibility for them and be able to reach his potential.

    Another important point that should be attributed to the need for order and lack of chaos is the ability to concentrate on the task, the absence of frequent context switches. The work of a programmer requires time and focus. Programmers really do not like to urgently drop one task and switch to another. The necessary part of the programmer’s work is usually not only the development of the code itself, but also a bug fixing and help with processing requests from customers. It is worth planning such things in advance, in such a way as to enable the programmer to calmly and completely complete work on one task before switching to another. The best option is to give you the opportunity to plan your work yourself, identifying priorities and upcoming tasks in advance, allocating a long, long time to work on one type of task.Google - Site Reliability Engineering ”, which describes well the approaches to planning the work of teams that ensure the operation and development of large, highly loaded fault-tolerant systems, as well as engineers who, by their nature, combine software development and its support.

    To be continued...

    Also popular now: