How to understand that you are not happy or are discussing methods of extruding workers from the company
The developer is, on average, a passionate person; there is little point in arguing with this. Objectively, because programming training takes a lot of time and effort from youth itself, many developers become a bit like bears. And now I will explain why.
A bear is generally a unique animal. The hibernation system alone is a matter of respect. Add to this the size, omnivorousness and habitat, and we get a top predator who has no natural enemies. Any zoologist will tell you that a bear is a lonely beast. And just in the way of life as a loner lies the main problem of interaction with the bear: it has practically no mimic signaling system . Harm to a bear in nature can only be caused by another bear, but they simply diverge in different directions, preferring a tactical retreat to bloody combat. That is, the level of emotionality of this animal can be compared with the emotionality of Chuck Norris, see for yourself:
')
There are a lot of straightforward "bears" among developers. The problem is that with such a straightforwardness the “bear” loses any chance of recognizing hints and half tones, at least without an extensive sad experience in the background. So in this publication we will talk about a few basic “methods” used by bad people in order to squeeze an objectionable employee from the company.
The first way to put pressure on a person is to revise the metrics of its effectiveness in the direction of increasing complexity and increasing their number. As they say in one proverb: “It doesn’t matter how they vote. The main thing - as they say. In fact, there may be more work, it will just be considered differently. The more metrics and the more confusing they are, the more likely it is that a specialist will make a mistake somewhere and misunderstand the requirements of management.
These mistakes unleash the developer’s hand and he begins to put pressure on him. It can be of any nature: from public dressing at morning meetings / coffee breaks to depremiration. The essence of the complexity of metrics is the same: take a person out of a state of professional balance.
At the same time the rear is securely covered. An adversary can prepare an extensive base in the form of a prescribed workflow, carry out tedious correspondence by mail and involve other methods of "dirty clerical and chichenka" in order to complicate a person’s life. Most often, the victims of such frauds are people who enjoy authority with the team, but can, in the long run, qualify for a leadership position. In fact, this is the elimination of competitors in the style of showdown 90s.
How to deal with this? First of all, absolutely all metrics cannot be unambiguous. If the manager says that 10% of the working time should be allocated for interaction by mail, and you spent 12% or 15%, since you had to contact, for example, with the front-end, this cannot be a reason for the proceedings. In addition, for all metrics should be responsible immediate supervisor . In Crossover, when there is a hard mismatch between the metrics set by the management and the results of the developers, they are equally asked about the management. If the work was done and the workflow goes in the right direction, then, therefore, the error was made by the manager, who set up unrealistic or incorrect metrics.
Unfortunately, in most companies, the principle of two-sided responsibility for metrics is not observed and the developer does not have the opportunity to start the process of assessing their adequacy, which unleashes the management and allows them to do this kind of "beatings". Inadequate metrics are most often local; If you are faced with the descent of the "impracticable" from the very top, then these are already global structural problems that we talked about in the text about "effective" managers .
On the topic of collective responsibility, many copies have already been broken. Usually this tool is practiced for the so-called building of trust relationships within the team. A bright message sounds like this: “help each other, correct and explain mistakes to your colleagues and you will become an excellent team.”
In an adequate implementation, this approach allows you to quickly "pull up" newcomers, eliminates the need to appoint mentors "under the lash" 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 team feats of labor depreciate with the phrase “you must work 100% anyway”. On the other hand, any mistakes made by a person disliked by the leadership lead to collective sanctions against the whole team.
As a result, the “culprit” of the sanctions turns out to be squeezed out of the team: who likes to lose bonuses and bonuses due to the mistakes of another person? If there is not enough unity in the department, very quickly the objectionable employee becomes an outcast, after which he begins to change his place of work.
Another method by which a person can try to survive from his place of work is expressed in putting pressure on an employee’s professional self-esteem. 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.
In short, professional self-esteem is a very, very sensitive point that you should not push for nothing. But how exactly is it affected? There are several simple ways: setting vague tasks and public doubt of competence. Usually these "techniques" are used in conjunction.
The specialist who wants to be squeezed out of the company is given as vague tasks as possible, mostly verbally, so as not to leave traces. If the company's regulations oblige to keep correspondence and put deployed tasks - no doubt, to understand what has been 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, it means he will understand everything incorrectly and he will be able to give a dressing out, at least for initiative and the wrong decision-making procedure.
If the developer considers that some games are played with him and adopts the principle “the effectiveness and quality of the work done depends directly on the clarity of the set TK” and goes to clarify the problem, he will fall into the next trap in this chain.
The main thing is that at the time of asking the question “What is this figoomen in my task?” There were as many loyal spectators as possible around. So, when the question is voiced, the eyes are rounded and the counter-question in the style of the Promised Land is set as loud as possible: “So how can such an experienced and skillful developer deal with the simplest task for the green juna ?!”. Well, the formulation of the exclamation can be any, the meaning is to publicly humiliate a person.
The developer’s problem is that he perceives such things as “God, why I have to work with idiots,” that is, often, for granted. In essence, he falls into a trap, the purpose of which is to humiliate him as a professional in the eyes of colleagues and strike at his own self-esteem. Because if these situations are repeated systematically, even the “strongest” person will at least begin to think about changing jobs, and as a maximum - will lose interest in the project, that is, they will have real, rather than artificial, performance problems. What our opponents only need.
The goal of all the manipulations of this kind is the same - to loosen the collective and knock out potentially dangerous and / or powerful people out of it. But it happens when just "the person does not like it." Why do they do this, we will omit it, because this is already a question for an article on corporate ethics and it directly overlaps with the topic of “effective” management. In fact, we have mentioned only a few of the most vivid examples of exerting pressure on developers whose goal is to force them to leave. In fact, there are still many "dirty" receptions, ranging from gossip in the office kitchen and ending with direct sabotage work.
The first way to protect against such actions is interaction in case of disputable situations with the leadership of a step higher. In adequate companies, the employee can always refer to the “boss of his boss” directly. But there are two big "BUT". First: if all this happens with the sanction of higher-level leaders, then it will not work to get rid of the pressure. Second, the manager must be ready to act as an arbitrator, 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 claims and drag the conflict into a practical plane, where the 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 there should be no mistakes and the defending side is in a deliberately 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 enters a protracted phase of confrontation and, most likely, will lead to a change of leadership (because it is simpler cheaper than expelling the whole team and recruiting a new one). The main condition is efficiency in the work plan.
But this is practically a fantastic scenario, because I did not in vain mention the “bearish” emotional nature of IT people. When we notice that a colleague needs our help, he has, most often, signed the documents for dismissal “on his own” and invites you to a farewell meeting in the nearest bar.
A bear is generally a unique animal. The hibernation system alone is a matter of respect. Add to this the size, omnivorousness and habitat, and we get a top predator who has no natural enemies. Any zoologist will tell you that a bear is a lonely beast. And just in the way of life as a loner lies the main problem of interaction with the bear: it has practically no mimic signaling system . Harm to a bear in nature can only be caused by another bear, but they simply diverge in different directions, preferring a tactical retreat to bloody combat. That is, the level of emotionality of this animal can be compared with the emotionality of Chuck Norris, see for yourself:
')
There are a lot of straightforward "bears" among developers. The problem is that with such a straightforwardness the “bear” loses any chance of recognizing hints and half tones, at least without an extensive sad experience in the background. So in this publication we will talk about a few basic “methods” used by bad people in order to squeeze an objectionable employee from the company.
Metrics. Many and different
The first way to put pressure on a person is to revise the metrics of its effectiveness in the direction of increasing complexity and increasing their number. As they say in one proverb: “It doesn’t matter how they vote. The main thing - as they say. In fact, there may be more work, it will just be considered differently. The more metrics and the more confusing they are, the more likely it is that a specialist will make a mistake somewhere and misunderstand the requirements of management.
These mistakes unleash the developer’s hand and he begins to put pressure on him. It can be of any nature: from public dressing at morning meetings / coffee breaks to depremiration. The essence of the complexity of metrics is the same: take a person out of a state of professional balance.
At the same time the rear is securely covered. An adversary can prepare an extensive base in the form of a prescribed workflow, carry out tedious correspondence by mail and involve other methods of "dirty clerical and chichenka" in order to complicate a person’s life. Most often, the victims of such frauds are people who enjoy authority with the team, but can, in the long run, qualify for a leadership position. In fact, this is the elimination of competitors in the style of showdown 90s.
How to deal with this? First of all, absolutely all metrics cannot be unambiguous. If the manager says that 10% of the working time should be allocated for interaction by mail, and you spent 12% or 15%, since you had to contact, for example, with the front-end, this cannot be a reason for the proceedings. In addition, for all metrics should be responsible immediate supervisor . In Crossover, when there is a hard mismatch between the metrics set by the management and the results of the developers, they are equally asked about the management. If the work was done and the workflow goes in the right direction, then, therefore, the error was made by the manager, who set up unrealistic or incorrect metrics.
Unfortunately, in most companies, the principle of two-sided responsibility for metrics is not observed and the developer does not have the opportunity to start the process of assessing their adequacy, which unleashes the management and allows them to do this kind of "beatings". Inadequate metrics are most often local; If you are faced with the descent of the "impracticable" from the very top, then these are already global structural problems that we talked about in the text about "effective" managers .
Introduction of collective responsibility for punishments
On the topic of collective responsibility, many copies have already been broken. Usually this tool is practiced for the so-called building of trust relationships within the team. A bright message sounds like this: “help each other, correct and explain mistakes to your colleagues and you will become an excellent team.”
In an adequate implementation, this approach allows you to quickly "pull up" newcomers, eliminates the need to appoint mentors "under the lash" 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 team feats of labor depreciate with the phrase “you must work 100% anyway”. On the other hand, any mistakes made by a person disliked by the leadership lead to collective sanctions against the whole team.
As a result, the “culprit” of the sanctions turns out to be squeezed out of the team: who likes to lose bonuses and bonuses due to the mistakes of another person? If there is not enough unity in the department, very quickly the objectionable employee becomes an outcast, after which he begins to change his place of work.
Pressure on professional self-esteem
Another method by which a person can try to survive from his place of work is expressed in putting pressure on an employee’s professional self-esteem. 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.
In short, professional self-esteem is a very, very sensitive point that you should not push for nothing. But how exactly is it affected? There are several simple ways: setting vague tasks and public doubt of competence. Usually these "techniques" are used in conjunction.
The specialist who wants to be squeezed out of the company is given as vague tasks as possible, mostly verbally, so as not to leave traces. If the company's regulations oblige to keep correspondence and put deployed tasks - no doubt, to understand what has been 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, it means he will understand everything incorrectly and he will be able to give a dressing out, at least for initiative and the wrong decision-making procedure.
If the developer considers that some games are played with him and adopts the principle “the effectiveness and quality of the work done depends directly on the clarity of the set TK” and goes to clarify the problem, he will fall into the next trap in this chain.
The main thing is that at the time of asking the question “What is this figoomen in my task?” There were as many loyal spectators as possible around. So, when the question is voiced, the eyes are rounded and the counter-question in the style of the Promised Land is set as loud as possible: “So how can such an experienced and skillful developer deal with the simplest task for the green juna ?!”. Well, the formulation of the exclamation can be any, the meaning is to publicly humiliate a person.
The developer’s problem is that he perceives such things as “God, why I have to work with idiots,” that is, often, for granted. In essence, he falls into a trap, the purpose of which is to humiliate him as a professional in the eyes of colleagues and strike at his own self-esteem. Because if these situations are repeated systematically, even the “strongest” person will at least begin to think about changing jobs, and as a maximum - will lose interest in the project, that is, they will have real, rather than artificial, performance problems. What our opponents only need.
How to deal with such terror
The goal of all the manipulations of this kind is the same - to loosen the collective and knock out potentially dangerous and / or powerful people out of it. But it happens when just "the person does not like it." Why do they do this, we will omit it, because this is already a question for an article on corporate ethics and it directly overlaps with the topic of “effective” management. In fact, we have mentioned only a few of the most vivid examples of exerting pressure on developers whose goal is to force them to leave. In fact, there are still many "dirty" receptions, ranging from gossip in the office kitchen and ending with direct sabotage work.
The first way to protect against such actions is interaction in case of disputable situations with the leadership of a step higher. In adequate companies, the employee can always refer to the “boss of his boss” directly. But there are two big "BUT". First: if all this happens with the sanction of higher-level leaders, then it will not work to get rid of the pressure. Second, the manager must be ready to act as an arbitrator, 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 claims and drag the conflict into a practical plane, where the 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 there should be no mistakes and the defending side is in a deliberately 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 enters a protracted phase of confrontation and, most likely, will lead to a change of leadership (because it is simpler cheaper than expelling the whole team and recruiting a new one). The main condition is efficiency in the work plan.
But this is practically a fantastic scenario, because I did not in vain mention the “bearish” emotional nature of IT people. When we notice that a colleague needs our help, he has, most often, signed the documents for dismissal “on his own” and invites you to a farewell meeting in the nearest bar.
Source: https://habr.com/ru/post/430398/
All Articles