Competition within the team kills the team spirit
In modern economics, it is generally accepted that competition has an extremely beneficial effect on the market. It does not allow a monopoly to be created, does not allow prices for a product or service to exceed certain reasonable limits, forces the manufacturer to constantly improve the product, not to stop at what has been achieved so as not to lag behind competitors.
But is competition always and everywhere good? What will happen if, on a model of competition, to build management not only of products, but also of people? Unfortunately, many “effective managers” do not realize that market practices are not always applicable when it comes to the interaction of members of one team or teams within one company.
Sample number of times. One very well-known western brand made a real competition among the departments of the Russian representative office selling children's clothing and clothing for teenagers. Realistically and purposefully, departments collide with their heads, among them fierce rivalries are fostered (for example, the fulfillment of the plan is considered to be the best department, and the worst receives fines). The company's management believes that with such pressure, employees work faster and more productively, trying to overtake the "competitors".
')
It is clear that the employees of these departments hate each other with fierce hatred (skillfully heated by the leadership) and perceive each other as enemies.
On the other hand, sooner or later, the child grows out of clothes for children, and he needs clothes for teenagers. A logical strategy would be to smoothly “transfer” customers from one unit to another, arrange joint actions, etc. Do you think the two teams are interested in such cooperation? Are such actions really held? As a result, the company misses a bunch of opportunities to expand its customer base and develop relationships with customers.
Another example, already from IT. One top manager of a very large company once came up with measuring employees by rank. You work better than others - you get a bonus. You work worse than others - scolding from the bosses and other disfavor.
At first glance, it seems logical. The best get the most, the worst go away and replaced by those who will work more efficiently. People do not relax and work on the limits of their strength in order to surpass the others and produce a result that is better than that of their colleagues. Sounds rosy!
In fact, there is one key problem: people are not interested in working together. Instead of achieving common results by joint efforts, they concentrate on being better than others, not letting others get ahead of themselves in rank.
By the way, some consider this approach to be one of the main reasons for the failure of the described company.
Planting such competition within a team forces employees to work in a win-lose style - a model in which winning one side necessarily entails losing the second (and vice versa). If I win, then you lose. If you win, then I lose. Why is he so bad?
In the course of any project, inevitably there are questions that need to be addressed jointly, incomprehensible points that need to be clarified, tasks that require the help of other participants.
If we imagine that all team members work “every man for himself”, then helping a colleague is not only unprofitable, but also harmful: as a result, he will be more efficient and get buns for you. In addition, the more problems a colleague has, the greater the chance that you will be higher than him at the next certification.
This approach is even more pronounced when communicating with people from other teams on whom the success of your project depends.
I think each of us at least once heard something like this:
All of this is the lack of a command culture, the approach of a spaghetti-western single cowboy. Such approaches contribute to a heap of problems on the project, which we will now discuss.
Imagine that you have a problem that you cannot solve on your own. For example, in order to add a new function to the client part of the application, you need to transfer an additional parameter from the server.
The server part is developed by programmer Vasya, who participates in the same internal ranking as you. You come to Vasya and ask to add a new parameter. Obviously, Vasya also has his own tasks, which he currently performs. Even if this parameter blocks all your work, and Vasya’s current task is absolutely not important, he is unlikely to help you. He knows that by doing so he will delay (even if only slightly) his work, and at the same time you will do your part quickly and efficiently. Accordingly, he risks being behind you in the race for ranks.
Most likely, tasks of this type will be agreed between you, Vasya, the project manager, etc. quite a long time. In this case, Vasya with all his strength will resist attempts to set this task to him. And it is possible that he will succeed.
As a result, both you and Vasya and your general manager will spend a lot of effort, time and nerves on agreeing and arguing instead of quickly solving a minor task and moving on.
The goal of the majority of team members in which a competitive “motivation” system is adopted is to be better than others. They are not interested in how convenient and comfortable to work with their neighbors on a team. They do not care.
At the same time, problems often arise, which can be easily avoided if employees think about their colleagues. For example, a programmer can, without consulting, make changes to the code of a large number of files, knowing that several people are currently working on them. At the same time, it’s quite realistic to hear something like the author of the commit: “they need - let them merzhat (jarg. - they compare versions and correct conflicts). I do my job. ”
Another example: “Although Vasya knows how to do such tasks, I will not go to him, but I will understand myself. And then the management will decide that I am worse than Vasya. ” This is also a vivid manifestation of rivalry between team members, which creates a problem from scratch.
Well and, probably, the most striking example is the invention (and subsequent support) of five different solutions of the same task by five programmers. Nobody just wanted to share their work with the whole team, and there was no desire to ask colleagues (after all, helping a friend, everyone makes himself worse).
Hidden sabotage is probably the most destructive manifestation of internal competition. It is a deliberate complication of the work of other team members. A good example of such sabotage is the well-known C ++ code line: “ #define TRUE FALSE // happy debugging, c * ki ... ”
It is clear that only asocial unicums will be openly doing so, but hidden provocations of colleagues to show their superiority, unfortunately, can greatly reduce the team's performance.
By the way, there are much more sophisticated ways to sabotage. For example, indicate a critical vulnerability in the system at a presentation to its CEO instead of reporting about it in advance and giving the team time to fix it before an important meeting.
Another option for sabotage is the “Italian strike”, i.e. work in strict accordance with the instructions. For example, instead of finding out the incomprehensible moment in the TK, the programmer intentionally makes the system not work, but at the same time it is 100% compliant.
"What do you want from me? I just write code, everything else doesn’t concern me. ” Such a statement is quite understandable. The salary, career and recognition of an employee depends not on how successful the project is, not on the result of his work - something important and necessary for people, but only on how fast he writes his piece of code.
Two people in a team have two separate goals. They both want to be better than their colleagues. None of them have a need to make a good product and rather bring it to the market. Of course, the overall quality of the product, as well as the overall performance of the team, suffers.
If the other problems described above can still be somehow dealt with (for example, by administrative methods), then the problem of the lack of common goals in a system where competition within a team is preached is hardly cured. People cannot have common goals if the success of one team member means the failure of another. Sooner or later the team will end.
How to motivate people to do a common thing?
Experience shows that effective cooperation and mutual assistance in a team allows you to achieve amazing results. A team that feels like one, in which there is a spirit of mutual assistance and responsibility for a common cause, can work wonders.
Each of its members, instead of pulling the blanket over itself, not only responds to requests for help, but also constantly thinks about how it is possible to make the work of others more comfortable, efficient, and more quickly achieve a common goal.
It’s enough for the success of each team member to win the rest. Work in the model Win-Win. This model is very well described in the magnificent book of Stephen Covey (if you suddenly did not read it - run to the store!).
For example, if one team member has achieved some results, then the whole team receives buns. A very good practice is to mark the end of any more or less large project with joint activities (for example, going to a cafe).
In addition, it makes sense to actively encourage assistance to colleagues, as well as general activities - brainstorming, discussion of architecture, exchange of experience, etc.
And, most importantly, it is necessary to clearly and clearly convey to everyone the thought: “we all have one goal, we all do one thing in common” and not violate this approach either with our own words or deeds.
People need to understand: they can do something meaningful only together, only by joining forces. Each team member is not a hindrance in career growth, but a friend who will give you a hand (or push you up) when you climb the next step on this ladder.
Only in this case, the team will have a chance to do something important and meaningful, and not just wipe the keyboard of computers, releasing the clones of the useless crafts over and over again.
Good luck in your development, and may cooperation prevail in your team (such as ours :)!
By the way, there are several situations in which competition between teams is useful. But that's another story ...
But is competition always and everywhere good? What will happen if, on a model of competition, to build management not only of products, but also of people? Unfortunately, many “effective managers” do not realize that market practices are not always applicable when it comes to the interaction of members of one team or teams within one company.
Life examples
Sample number of times. One very well-known western brand made a real competition among the departments of the Russian representative office selling children's clothing and clothing for teenagers. Realistically and purposefully, departments collide with their heads, among them fierce rivalries are fostered (for example, the fulfillment of the plan is considered to be the best department, and the worst receives fines). The company's management believes that with such pressure, employees work faster and more productively, trying to overtake the "competitors".')
It is clear that the employees of these departments hate each other with fierce hatred (skillfully heated by the leadership) and perceive each other as enemies.
On the other hand, sooner or later, the child grows out of clothes for children, and he needs clothes for teenagers. A logical strategy would be to smoothly “transfer” customers from one unit to another, arrange joint actions, etc. Do you think the two teams are interested in such cooperation? Are such actions really held? As a result, the company misses a bunch of opportunities to expand its customer base and develop relationships with customers.
Another example, already from IT. One top manager of a very large company once came up with measuring employees by rank. You work better than others - you get a bonus. You work worse than others - scolding from the bosses and other disfavor.
At first glance, it seems logical. The best get the most, the worst go away and replaced by those who will work more efficiently. People do not relax and work on the limits of their strength in order to surpass the others and produce a result that is better than that of their colleagues. Sounds rosy!
In fact, there is one key problem: people are not interested in working together. Instead of achieving common results by joint efforts, they concentrate on being better than others, not letting others get ahead of themselves in rank.
By the way, some consider this approach to be one of the main reasons for the failure of the described company.
Planting such competition within a team forces employees to work in a win-lose style - a model in which winning one side necessarily entails losing the second (and vice versa). If I win, then you lose. If you win, then I lose. Why is he so bad?
Win-lose
In the course of any project, inevitably there are questions that need to be addressed jointly, incomprehensible points that need to be clarified, tasks that require the help of other participants.
If we imagine that all team members work “every man for himself”, then helping a colleague is not only unprofitable, but also harmful: as a result, he will be more efficient and get buns for you. In addition, the more problems a colleague has, the greater the chance that you will be higher than him at the next certification.
This approach is even more pronounced when communicating with people from other teams on whom the success of your project depends.
I think each of us at least once heard something like this:
- Vasya, if you don’t have a module, these are your problems, I’ve already done my part of the work and I’m not going to waste time on your jambs.
- I can not give you a man, because they are needed on my project. Come when the project is over. I don't care if your project is in critical condition. This is your project, not mine.
- The projects of your department always have a lower priority over the projects of our department. Our programmers are not going to waste time on them.
- I don't care what these sellers have promised to the customer there. If we do not have time - it’s worse for them, as a developer, this does not concern me.
All of this is the lack of a command culture, the approach of a spaghetti-western single cowboy. Such approaches contribute to a heap of problems on the project, which we will now discuss.
Tasks are solved for a very long time or not at all.
Imagine that you have a problem that you cannot solve on your own. For example, in order to add a new function to the client part of the application, you need to transfer an additional parameter from the server.
The server part is developed by programmer Vasya, who participates in the same internal ranking as you. You come to Vasya and ask to add a new parameter. Obviously, Vasya also has his own tasks, which he currently performs. Even if this parameter blocks all your work, and Vasya’s current task is absolutely not important, he is unlikely to help you. He knows that by doing so he will delay (even if only slightly) his work, and at the same time you will do your part quickly and efficiently. Accordingly, he risks being behind you in the race for ranks.
Most likely, tasks of this type will be agreed between you, Vasya, the project manager, etc. quite a long time. In this case, Vasya with all his strength will resist attempts to set this task to him. And it is possible that he will succeed.
As a result, both you and Vasya and your general manager will spend a lot of effort, time and nerves on agreeing and arguing instead of quickly solving a minor task and moving on.
Problems appear from scratch
The goal of the majority of team members in which a competitive “motivation” system is adopted is to be better than others. They are not interested in how convenient and comfortable to work with their neighbors on a team. They do not care.
At the same time, problems often arise, which can be easily avoided if employees think about their colleagues. For example, a programmer can, without consulting, make changes to the code of a large number of files, knowing that several people are currently working on them. At the same time, it’s quite realistic to hear something like the author of the commit: “they need - let them merzhat (jarg. - they compare versions and correct conflicts). I do my job. ”
Another example: “Although Vasya knows how to do such tasks, I will not go to him, but I will understand myself. And then the management will decide that I am worse than Vasya. ” This is also a vivid manifestation of rivalry between team members, which creates a problem from scratch.
Well and, probably, the most striking example is the invention (and subsequent support) of five different solutions of the same task by five programmers. Nobody just wanted to share their work with the whole team, and there was no desire to ask colleagues (after all, helping a friend, everyone makes himself worse).
Hidden sabotage
Hidden sabotage is probably the most destructive manifestation of internal competition. It is a deliberate complication of the work of other team members. A good example of such sabotage is the well-known C ++ code line: “ #define TRUE FALSE // happy debugging, c * ki ... ”
It is clear that only asocial unicums will be openly doing so, but hidden provocations of colleagues to show their superiority, unfortunately, can greatly reduce the team's performance.
By the way, there are much more sophisticated ways to sabotage. For example, indicate a critical vulnerability in the system at a presentation to its CEO instead of reporting about it in advance and giving the team time to fix it before an important meeting.
Another option for sabotage is the “Italian strike”, i.e. work in strict accordance with the instructions. For example, instead of finding out the incomprehensible moment in the TK, the programmer intentionally makes the system not work, but at the same time it is 100% compliant.
Indifference and lack of common goals
"What do you want from me? I just write code, everything else doesn’t concern me. ” Such a statement is quite understandable. The salary, career and recognition of an employee depends not on how successful the project is, not on the result of his work - something important and necessary for people, but only on how fast he writes his piece of code.
Two people in a team have two separate goals. They both want to be better than their colleagues. None of them have a need to make a good product and rather bring it to the market. Of course, the overall quality of the product, as well as the overall performance of the team, suffers.
If the other problems described above can still be somehow dealt with (for example, by administrative methods), then the problem of the lack of common goals in a system where competition within a team is preached is hardly cured. People cannot have common goals if the success of one team member means the failure of another. Sooner or later the team will end.
How to motivate people to do a common thing?
Win-win
Experience shows that effective cooperation and mutual assistance in a team allows you to achieve amazing results. A team that feels like one, in which there is a spirit of mutual assistance and responsibility for a common cause, can work wonders.
Each of its members, instead of pulling the blanket over itself, not only responds to requests for help, but also constantly thinks about how it is possible to make the work of others more comfortable, efficient, and more quickly achieve a common goal.
It’s enough for the success of each team member to win the rest. Work in the model Win-Win. This model is very well described in the magnificent book of Stephen Covey (if you suddenly did not read it - run to the store!).
For example, if one team member has achieved some results, then the whole team receives buns. A very good practice is to mark the end of any more or less large project with joint activities (for example, going to a cafe).
In addition, it makes sense to actively encourage assistance to colleagues, as well as general activities - brainstorming, discussion of architecture, exchange of experience, etc.
And, most importantly, it is necessary to clearly and clearly convey to everyone the thought: “we all have one goal, we all do one thing in common” and not violate this approach either with our own words or deeds.
People need to understand: they can do something meaningful only together, only by joining forces. Each team member is not a hindrance in career growth, but a friend who will give you a hand (or push you up) when you climb the next step on this ladder.
Only in this case, the team will have a chance to do something important and meaningful, and not just wipe the keyboard of computers, releasing the clones of the useless crafts over and over again.
Good luck in your development, and may cooperation prevail in your team (such as ours :)!
By the way, there are several situations in which competition between teams is useful. But that's another story ...
Source: https://habr.com/ru/post/193466/
All Articles