November 19, 2018 at 15:37How to understand that you are not welcome or discuss methods of squeezing workers out of the company
The developer is an average enthusiastic person; there is little point in arguing with this. Objectively, due to the fact that learning programming from a youth takes a lot of time and effort, many developers become a little bit like bears. And now I will explain why.
A bear is generally a unique animal. Winter hibernation alone is a matter of respect. Add to this the size, omnivorousness and habitat and we get the highest predator that has no natural enemies. Any zoologist will tell you that the bear is a lone beast. And just in the lifestyle as loners lies the main problem of interaction with the bear: it has practically no mimic signaling system. Only another bear can cause harm to a bear in nature, but they simply diverge in different directions, preferring tactical retreat to a bloody battle. That is, the level of emotionality of this beast can be compared with the emotionality of Chuck Norris, see for yourself:
Among the developers there are many such straightforward “bears”. The problem is that with such straightforwardness, the “bear” loses any chance of recognizing hints and midtones, at least without extensive sad experience. So in this publication we will talk about several basic "methods" that bad people use to squeeze an employee who is objectionable to them from the company.
The first way to put pressure on a person is to revise the metrics of his effectiveness in the direction of complication and increase in their number. As one saying goes: “No matter how they vote. The main thing is what they think. ” In fact, the work may even become larger, it will simply be considered differently. The more metrics and the more confusing they are, the more likely it is that the specialist will make a mistake somewhere and misunderstand the requirements of the management.
These errors untie the opponent’s hands and the developer begins to put pressure on him. It can be of any nature: from public dragging at morning rallies / coffee breaks to depremization. The essence of the complication of metrics is one: to bring a person out of a state of professional equilibrium.
At the same time, the rear areas are reliably covered. The ill-wisher can prepare an extensive database in the form of a prescribed workflow, carry out tedious correspondence by mail and involve other tricks of “dirty clerical work and crocheting” in order to complicate a person’s life. Most often, victims of such fraud are people who enjoy the authority of the team, but at the same time they can, in the future, apply for a leadership position. In fact, this is the elimination of competitors in the style of the showdown of the 90s.
How to deal with this? First of all, absolutely all metrics cannot be unambiguous. If the manager says that interaction by mail should be allocated 10% of the working time, and you spent 12% or 15%, since you had to contact, for example, with the frontend, this can not be a reason for the proceedings. Besides,All metrics exposed must be the responsibility of the immediate supervisor . In Crossover, in case of severe discrepancy between the metrics set by the management, the results of developers are equally asked from the management. If the work has been done and the work process is going in the right direction, then, therefore, the manager made a mistake who exposed unrealistic or incorrect metrics.
Unfortunately, in most companies, the principle of bilateral responsibility for the implementation of metrics is not respected and the developer does not have the opportunity to start the process of evaluating their adequacy, which frees up the hands of management and allows him to engage in such “assault”. Most often, inadequate metrics are local in nature; if you are faced with the descent of the “impossible” from the very top, then these are global structural problems, which we spoke about in the text about “effective” managers .
A lot of copies have already been broken about the topic of collective responsibility. Typically, this tool is practiced for the so-called building trust relationships within the team. The light message is: “help each other, correct and explain mistakes to your colleagues and you will become a great team.”
In adequate execution, this approach allows you to quickly “pull up” newcomers, eliminates the need to appoint mentors “from under the stick” and all other coercive mechanisms.
In fact, collective responsibility often turns into a repressive tool to exert pressure on the team and its individual members. The postulate of collective bonuses for successful work is omitted and any labor exploits of the team are devalued with the wording “you must work 100% anyway”. On the other hand, any mistakes that are objectionable to the leadership of a person lead to collective sanctions against the whole team.
As a result, the "culprit" of the sanctions is squeezed out of the team: who is pleased to lose bonuses and bonuses due to the mistakes of another person? If the department does not have sufficient unity, very quickly an objectionable employee becomes an outcast, after which he begins to change his job.
Another technique that can try to survive a person from his place of work is expressed in putting pressure on the professional self-esteem of the employee. What could be more important than professional self-esteem? For many IT workers, the level of personal self-esteem directly correlates with the level of professional. Achievements in the professional field give us strength for personal development and growth, show that we are able to be better than we could count on.
In short, professional self-esteem is a very, very sensitive point that you should not put pressure on. But how exactly is it affected? There are a few simple ways: setting vague tasks and public doubt of competence. Typically, these "tricks" are used in conjunction.
The specialist whom they want to squeeze out of the company is given as vague tasks as possible, mainly orally, so as not to leave any traces. If the rules of the company require you to correspond and set detailed tasks - do not hesitate, to understand what you have written, you will have to resurrect Turing and the whole team that worked with the decryption of Enigma messages. If the developer did not come for explanations - well, okay, that means he will certainly understand everything wrong and he will be able to arrange a drag, at least for his initiative and the wrong order of decision-making.
If the developer considers that they are playing some games with him and adopts the principle of “the effectiveness and quality of the work done depends on the clarity of the task” and goes on to clarify the task, he gets into the next trap in this chain.
The main thing is that at the time of posing the question “What kind of garbage is this in my task?” There should be as many loyal spectators as possible. So, when the question is voiced, the eyes are rounded and the counter question in the style of the Promised Land is asked as loudly as possible: “Well, how can such an experienced and skillful developer not deal with the simplest task for the green June ?!”. Well, the wording of the call can be anything, the point is to publicly humiliate a person.
The developer’s problem is that he perceives such things as “God, why do I have to work with idiots”, that is, often, for granted. In fact, he falls into a trap, the purpose of which is to humiliate him as a professional in the eyes of his colleagues and strike a blow at his own self-esteem. Because if these situations are repeated systematically, even the “strongest” person will begin to think at least about a job change, and at the very least lose interest in the project, that is, he will have real rather than far-fetched problems with productivity. What our opponents only need.
The goal of all manipulations of this kind is the same - to loosen the team and knock out potentially dangerous and / or powerful people out of it. But it happens when you just "do not like the face." Why we do this, we omit, because this is already a question for an article on corporate ethics and it directly intersects with the theme of “effective” management. In fact, we mentioned only a few of the most striking examples of exerting pressure on developers whose purpose is to force them to leave. In fact, there are many more "dirty" tricks, ranging from gossip in the office kitchen and ending with direct sabotage of work.
The first way to protect against such actions is to cooperate in case of contentious situations with the leadership of a step higher. In adequate companies, an employee can always turn to the "boss of his boss" directly. But there are two big BUTs. First: if all this happens with the sanction of higher managers, then getting rid of the pressure will not work. Second: the leader must be ready to act as an arbiter, which does not always happen.
The second way is through a clear fixation of each step and tasks of the task manager, in order to avoid any formal complaints and drag the conflict into a practical plane, where developers have an advantage. This is a positional war - who will survive and who will break. The problem with this method of counteraction is that mistakes cannot be made here and the defending side is in a knowingly losing position, since the “rules of war,” that is, the tasks, are often determined by the attacker.
There is still a mythical third way, when a team unites around a victim of pressure and does not allow a person to survive from his workplace. In this case, the conflict goes into a protracted phase of the confrontation and, most likely, will lead to a change of leadership (because it is easier to cheaper than dropping the whole team and recruiting a new one). The main condition is efficiency in the work plan.
But this is almost a fantastic scenario, because it was not for nothing that I mentioned the “bearish” emotional nature of IT people. When we notice that a colleague needs our help, he has most often already signed documents on his own dismissal and invites you to a farewell get-together in a nearby bar.
A bear is generally a unique animal. Winter hibernation alone is a matter of respect. Add to this the size, omnivorousness and habitat and we get the highest predator that has no natural enemies. Any zoologist will tell you that the bear is a lone beast. And just in the lifestyle as loners lies the main problem of interaction with the bear: it has practically no mimic signaling system. Only another bear can cause harm to a bear in nature, but they simply diverge in different directions, preferring tactical retreat to a bloody battle. That is, the level of emotionality of this beast can be compared with the emotionality of Chuck Norris, see for yourself:
Among the developers there are many such straightforward “bears”. The problem is that with such straightforwardness, the “bear” loses any chance of recognizing hints and midtones, at least without extensive sad experience. So in this publication we will talk about several basic "methods" that bad people use to squeeze an employee who is objectionable to them from the company.
Metrics. Many and different
The first way to put pressure on a person is to revise the metrics of his effectiveness in the direction of complication and increase in their number. As one saying goes: “No matter how they vote. The main thing is what they think. ” In fact, the work may even become larger, it will simply be considered differently. The more metrics and the more confusing they are, the more likely it is that the specialist will make a mistake somewhere and misunderstand the requirements of the management.
These errors untie the opponent’s hands and the developer begins to put pressure on him. It can be of any nature: from public dragging at morning rallies / coffee breaks to depremization. The essence of the complication of metrics is one: to bring a person out of a state of professional equilibrium.
At the same time, the rear areas are reliably covered. The ill-wisher can prepare an extensive database in the form of a prescribed workflow, carry out tedious correspondence by mail and involve other tricks of “dirty clerical work and crocheting” in order to complicate a person’s life. Most often, victims of such fraud are people who enjoy the authority of the team, but at the same time they can, in the future, apply for a leadership position. In fact, this is the elimination of competitors in the style of the showdown of the 90s.
How to deal with this? First of all, absolutely all metrics cannot be unambiguous. If the manager says that interaction by mail should be allocated 10% of the working time, and you spent 12% or 15%, since you had to contact, for example, with the frontend, this can not be a reason for the proceedings. Besides,All metrics exposed must be the responsibility of the immediate supervisor . In Crossover, in case of severe discrepancy between the metrics set by the management, the results of developers are equally asked from the management. If the work has been done and the work process is going in the right direction, then, therefore, the manager made a mistake who exposed unrealistic or incorrect metrics.
Unfortunately, in most companies, the principle of bilateral responsibility for the implementation of metrics is not respected and the developer does not have the opportunity to start the process of evaluating their adequacy, which frees up the hands of management and allows him to engage in such “assault”. Most often, inadequate metrics are local in nature; if you are faced with the descent of the “impossible” from the very top, then these are global structural problems, which we spoke about in the text about “effective” managers .
The introduction of collective responsibility for punishment
A lot of copies have already been broken about the topic of collective responsibility. Typically, this tool is practiced for the so-called building trust relationships within the team. The light message is: “help each other, correct and explain mistakes to your colleagues and you will become a great team.”
In adequate execution, this approach allows you to quickly “pull up” newcomers, eliminates the need to appoint mentors “from under the stick” and all other coercive mechanisms.
In fact, collective responsibility often turns into a repressive tool to exert pressure on the team and its individual members. The postulate of collective bonuses for successful work is omitted and any labor exploits of the team are devalued with the wording “you must work 100% anyway”. On the other hand, any mistakes that are objectionable to the leadership of a person lead to collective sanctions against the whole team.
As a result, the "culprit" of the sanctions is squeezed out of the team: who is pleased to lose bonuses and bonuses due to the mistakes of another person? If the department does not have sufficient unity, very quickly an objectionable employee becomes an outcast, after which he begins to change his job.
Pressure on professional self-esteem
Another technique that can try to survive a person from his place of work is expressed in putting pressure on the professional self-esteem of the employee. What could be more important than professional self-esteem? For many IT workers, the level of personal self-esteem directly correlates with the level of professional. Achievements in the professional field give us strength for personal development and growth, show that we are able to be better than we could count on.
In short, professional self-esteem is a very, very sensitive point that you should not put pressure on. But how exactly is it affected? There are a few simple ways: setting vague tasks and public doubt of competence. Typically, these "tricks" are used in conjunction.
The specialist whom they want to squeeze out of the company is given as vague tasks as possible, mainly orally, so as not to leave any traces. If the rules of the company require you to correspond and set detailed tasks - do not hesitate, to understand what you have written, you will have to resurrect Turing and the whole team that worked with the decryption of Enigma messages. If the developer did not come for explanations - well, okay, that means he will certainly understand everything wrong and he will be able to arrange a drag, at least for his initiative and the wrong order of decision-making.
If the developer considers that they are playing some games with him and adopts the principle of “the effectiveness and quality of the work done depends on the clarity of the task” and goes on to clarify the task, he gets into the next trap in this chain.
The main thing is that at the time of posing the question “What kind of garbage is this in my task?” There should be as many loyal spectators as possible. So, when the question is voiced, the eyes are rounded and the counter question in the style of the Promised Land is asked as loudly as possible: “Well, how can such an experienced and skillful developer not deal with the simplest task for the green June ?!”. Well, the wording of the call can be anything, the point is to publicly humiliate a person.
The developer’s problem is that he perceives such things as “God, why do I have to work with idiots”, that is, often, for granted. In fact, he falls into a trap, the purpose of which is to humiliate him as a professional in the eyes of his colleagues and strike a blow at his own self-esteem. Because if these situations are repeated systematically, even the “strongest” person will begin to think at least about a job change, and at the very least lose interest in the project, that is, he will have real rather than far-fetched problems with productivity. What our opponents only need.
How to deal with such terror
The goal of all manipulations of this kind is the same - to loosen the team and knock out potentially dangerous and / or powerful people out of it. But it happens when you just "do not like the face." Why we do this, we omit, because this is already a question for an article on corporate ethics and it directly intersects with the theme of “effective” management. In fact, we mentioned only a few of the most striking examples of exerting pressure on developers whose purpose is to force them to leave. In fact, there are many more "dirty" tricks, ranging from gossip in the office kitchen and ending with direct sabotage of work.
The first way to protect against such actions is to cooperate in case of contentious situations with the leadership of a step higher. In adequate companies, an employee can always turn to the "boss of his boss" directly. But there are two big BUTs. First: if all this happens with the sanction of higher managers, then getting rid of the pressure will not work. Second: the leader must be ready to act as an arbiter, which does not always happen.
The second way is through a clear fixation of each step and tasks of the task manager, in order to avoid any formal complaints and drag the conflict into a practical plane, where developers have an advantage. This is a positional war - who will survive and who will break. The problem with this method of counteraction is that mistakes cannot be made here and the defending side is in a knowingly losing position, since the “rules of war,” that is, the tasks, are often determined by the attacker.
There is still a mythical third way, when a team unites around a victim of pressure and does not allow a person to survive from his workplace. In this case, the conflict goes into a protracted phase of the confrontation and, most likely, will lead to a change of leadership (because it is easier to cheaper than dropping the whole team and recruiting a new one). The main condition is efficiency in the work plan.
But this is almost a fantastic scenario, because it was not for nothing that I mentioned the “bearish” emotional nature of IT people. When we notice that a colleague needs our help, he has most often already signed documents on his own dismissal and invites you to a farewell get-together in a nearby bar.