Field beds on time, or 5 signs of hidden problems in the team
There are a lot of problems in communications and their solution is always very specific for each case. The difficulty with some problems lies in the fact that they are hidden and make themselves clearly visible when it is too difficult, or later, to fix something. I remembered five cases that I personally encountered. Not everything worked out to solve, not everything decided consciously. Under the cut, you will find five stories illustrating the five signs of problems. I supplemented each story with a very dry hint about the correction, because the real solution is very subjective.
The beginning of February is a good time to think about spring, soon summer, summer cottage, garden beds, large long garden beds ... It's good that until February, and therefore let's talk about teamwork. How is it with Tolstoy in the book "Anna Karenina"? "All happy families are alike, each unhappy family is unhappy in its own way." Everyone has their own understanding of good and bad. In my opinion, every team or company has certain features of the attitude within the team and the leadership towards its employees, which are the result of the characteristics of unconscious behavior of people. It is the factor of unawareness that makes these problems hidden, because often if a person does not see the problem, then the problem, as it were, and no. In reality, it turns out that the behavior is different from what is declared by the team or the company, but implicitly. You can notice them only after several months of work in the company. Recalling similar problems in different IT companies, I made a list of such features that could quickly figure out the nature of the existing problems and the way to find their solutions.
Problem Type: Company vs. employee
One manager told me: “I report to the CEO and the stakeholders. And you're just a developer. " It was meant that he had a big responsibility, but I, as a developer, had no such responsibility. Later it turned out that he did not have his own opinion about the people who were subordinate to him and he simply transmitted the ideas of his boss. And his boss was not very closely with the developers. As a result, management was minimal and only reporting was in priority. Because of this, the attitude towards people was as if they were cogs in the mechanism. No one could say it right because of the accepted norms, but things spoke for themselves. No one will tell you that your goals are not important, because they lose face. But at the same time, no one will take into account your interests, because Your manager knows exactly what you should do, how to think and what to feel. When you discuss perspectives, you can say nice things that you want to hear. But real action does not follow this, and there is always a reason why something else is more important. And if you start to disagree, you will be accused of not listening, not communicative, or, even worse, contributing big risks to the project. Obviously, your boss refuses to find a solution that would be beneficial to both. The easiest solution for him is you, doing only what you said. In the company, this attitude towards employees was maintained at a high level. As a result, increased staff turnover. And a number of key people ( developers and product managers (eng .: product owner) ) left the company.
')
It is normal that people have their own personal goals, and the company has its own. Privately, they do not coincide, but it is important to understand how strongly a person and a company diverge in order. Finding synergy with employees, you multiply the winnings compared to the case when people just do what they are told.
Problem Type: Manager vs. employee
It is normal when people at work try to help teammates by openly and respectfully discussing problems. This atmosphere of support breaks down if it is misused by management roles (team leaders or managers). The situation may develop unintentionally and most strongly may be noticeable with the participation of the manager, rather than the team leader. For example, a manager asks you what would you like to improve in a team. You, out of good intentions, tell, in a heap with the rest, that it would be good if Vasya wrote more unit tests. The manager, meeting Vasya, tells him, as if making a reproach that he does not write unit tests. This clause may be a clause on, say, a performance review. Vasya, seeing the claims of the manager, will try to find out from his colleagues what is wrong, but everyone says that everything is fine. Because for colleagues, the problem of unit tests, as such, is not. But at this moment trust begins to deteriorate. For Vasya, everything looks as if someone behind his back is blackening in the eyes of the manager, but does not speak to him. The situation is bad because no one deliberately blackens him. Then it gets worse, because if the manager cannot solve this problem, then in such an atmosphere the insecurity of people in the team increases and makes them constantly prove something to others.
Here it should be tense manager. First, not every complaint is really a problem. Secondly, you should listen to the employee, because he may give hints of such a situation. And thirdly, the manager should encourage people to talk about problems only in the presence of another person. The causes and facts of both parties must be taken into account.
Problem type: team vs. employee
While error analysis is the norm, a constant reminder of past errors is not normal. Failure may occur due to lack of requirements or lack of knowledge, or due to successive failures at different stages of development, such as review code, QA, UAT. In this case, prolonged attention to the one person who made the mistake of teasing him will have a bad effect. If this behavior is the norm in the team, then outcasts in the team can appear. This behavior is usually supported by one of the leading roles. The rest of the people in the team simply adapt and follow the leader’s style. In the absence of support "from above", this behavior will not be long and will end quickly. Of course, the person who made a mistake should know about it and understand how it could have been avoided in order not to step on the rake again. But do not cling to it labels.
The failure discussion should end immediately after all the conclusions have been made. Teammates should feel supported in this situation.
Problem type: team vs. customer
The planning phase is important, and no one will tell you that you should not do it. At the same time, the team may experience a lack of authority, or lack of support from management, to push tasks that do not have a description. Management may say that they are very sorry and admit mistakes in planning that made them accept agreements that cannot be postponed. In such circumstances, developers are the ones who pay the final price. The manual will repeat the same mistakes again and again, because the developers simply do what they have been told. At the same time, everyone retains a face, because there is a formal recognition of the problem and a promise to fix it ... someday. In the course of work, developers are constantly faced with a situation when something is not described in the tasks. They begin to fall behind schedule, hurry and feel constant pressure from management. As a result, developers are always extreme.
Timlid, or the manager, should take the responsibility to protect the team from other managers and customers, resist their onslaught, and keep responsibility up to the level of the team. Definition of Ready for tasks should help managers prepare tasks well enough. In this case, it should be a strict rule.
Problem Type: Processes vs. employees
In a bright form, I met this feature in a young company, where the processes were developing at a very fast pace. In a personal conversation, the boss told me: "We have a process, but you need to understand when it is worth getting around in order to complete the task faster." This is true: sometimes bypassing a process helps you achieve goals faster, and it is even necessary. But when it is necessary to bypass the process in 50% of cases, the process itself begins to be perceived as a kind of formality. In this case, it is obvious that the process is more of an obstacle. On the other hand, without a process, management feels insecure due to weak control and lack of trust in the developers. As a result, everyone understands the problem, but changing the process is difficult because of bureaucracy (everyone’s consent is required, this is a bunch of meetings, and so on and so forth). Therefore, some managers may suggest that developers bypass the process based on the best motives. But by offering this, they put developers in a vulnerable position, when any such step can be viewed differently depending on the people and cases.
You may not need a process or rules. Instead, you may need only recommendations on how to do something with the possibility of different implementation. Well, or you can think about the official process of bypassing the standard process, for some cases. But in this case, do you need a process that is slower?
Saw something similar? Add your cases to the comments.
The beginning of February is a good time to think about spring, soon summer, summer cottage, garden beds, large long garden beds ... It's good that until February, and therefore let's talk about teamwork. How is it with Tolstoy in the book "Anna Karenina"? "All happy families are alike, each unhappy family is unhappy in its own way." Everyone has their own understanding of good and bad. In my opinion, every team or company has certain features of the attitude within the team and the leadership towards its employees, which are the result of the characteristics of unconscious behavior of people. It is the factor of unawareness that makes these problems hidden, because often if a person does not see the problem, then the problem, as it were, and no. In reality, it turns out that the behavior is different from what is declared by the team or the company, but implicitly. You can notice them only after several months of work in the company. Recalling similar problems in different IT companies, I made a list of such features that could quickly figure out the nature of the existing problems and the way to find their solutions.
1. Developers are just another resource.
Problem Type: Company vs. employee
One manager told me: “I report to the CEO and the stakeholders. And you're just a developer. " It was meant that he had a big responsibility, but I, as a developer, had no such responsibility. Later it turned out that he did not have his own opinion about the people who were subordinate to him and he simply transmitted the ideas of his boss. And his boss was not very closely with the developers. As a result, management was minimal and only reporting was in priority. Because of this, the attitude towards people was as if they were cogs in the mechanism. No one could say it right because of the accepted norms, but things spoke for themselves. No one will tell you that your goals are not important, because they lose face. But at the same time, no one will take into account your interests, because Your manager knows exactly what you should do, how to think and what to feel. When you discuss perspectives, you can say nice things that you want to hear. But real action does not follow this, and there is always a reason why something else is more important. And if you start to disagree, you will be accused of not listening, not communicative, or, even worse, contributing big risks to the project. Obviously, your boss refuses to find a solution that would be beneficial to both. The easiest solution for him is you, doing only what you said. In the company, this attitude towards employees was maintained at a high level. As a result, increased staff turnover. And a number of key people ( developers and product managers (eng .: product owner) ) left the company.
')
Hint: look for synergy
It is normal that people have their own personal goals, and the company has its own. Privately, they do not coincide, but it is important to understand how strongly a person and a company diverge in order. Finding synergy with employees, you multiply the winnings compared to the case when people just do what they are told.
2. Someone is constantly monitoring your mistakes.
Problem Type: Manager vs. employee
It is normal when people at work try to help teammates by openly and respectfully discussing problems. This atmosphere of support breaks down if it is misused by management roles (team leaders or managers). The situation may develop unintentionally and most strongly may be noticeable with the participation of the manager, rather than the team leader. For example, a manager asks you what would you like to improve in a team. You, out of good intentions, tell, in a heap with the rest, that it would be good if Vasya wrote more unit tests. The manager, meeting Vasya, tells him, as if making a reproach that he does not write unit tests. This clause may be a clause on, say, a performance review. Vasya, seeing the claims of the manager, will try to find out from his colleagues what is wrong, but everyone says that everything is fine. Because for colleagues, the problem of unit tests, as such, is not. But at this moment trust begins to deteriorate. For Vasya, everything looks as if someone behind his back is blackening in the eyes of the manager, but does not speak to him. The situation is bad because no one deliberately blackens him. Then it gets worse, because if the manager cannot solve this problem, then in such an atmosphere the insecurity of people in the team increases and makes them constantly prove something to others.
Hint: insist on open discussion
Here it should be tense manager. First, not every complaint is really a problem. Secondly, you should listen to the employee, because he may give hints of such a situation. And thirdly, the manager should encourage people to talk about problems only in the presence of another person. The causes and facts of both parties must be taken into account.
3. There is always someone to blame for the error.
Problem type: team vs. employee
While error analysis is the norm, a constant reminder of past errors is not normal. Failure may occur due to lack of requirements or lack of knowledge, or due to successive failures at different stages of development, such as review code, QA, UAT. In this case, prolonged attention to the one person who made the mistake of teasing him will have a bad effect. If this behavior is the norm in the team, then outcasts in the team can appear. This behavior is usually supported by one of the leading roles. The rest of the people in the team simply adapt and follow the leader’s style. In the absence of support "from above", this behavior will not be long and will end quickly. Of course, the person who made a mistake should know about it and understand how it could have been avoided in order not to step on the rake again. But do not cling to it labels.
Hint: stop focusing on mistakes
The failure discussion should end immediately after all the conclusions have been made. Teammates should feel supported in this situation.
4. The team proceeds to tasks without description and planning.
Problem type: team vs. customer
The planning phase is important, and no one will tell you that you should not do it. At the same time, the team may experience a lack of authority, or lack of support from management, to push tasks that do not have a description. Management may say that they are very sorry and admit mistakes in planning that made them accept agreements that cannot be postponed. In such circumstances, developers are the ones who pay the final price. The manual will repeat the same mistakes again and again, because the developers simply do what they have been told. At the same time, everyone retains a face, because there is a formal recognition of the problem and a promise to fix it ... someday. In the course of work, developers are constantly faced with a situation when something is not described in the tasks. They begin to fall behind schedule, hurry and feel constant pressure from management. As a result, developers are always extreme.
Hint: protect the team, not yourself
Timlid, or the manager, should take the responsibility to protect the team from other managers and customers, resist their onslaught, and keep responsibility up to the level of the team. Definition of Ready for tasks should help managers prepare tasks well enough. In this case, it should be a strict rule.
5. Bypassing the process
Problem Type: Processes vs. employees
In a bright form, I met this feature in a young company, where the processes were developing at a very fast pace. In a personal conversation, the boss told me: "We have a process, but you need to understand when it is worth getting around in order to complete the task faster." This is true: sometimes bypassing a process helps you achieve goals faster, and it is even necessary. But when it is necessary to bypass the process in 50% of cases, the process itself begins to be perceived as a kind of formality. In this case, it is obvious that the process is more of an obstacle. On the other hand, without a process, management feels insecure due to weak control and lack of trust in the developers. As a result, everyone understands the problem, but changing the process is difficult because of bureaucracy (everyone’s consent is required, this is a bunch of meetings, and so on and so forth). Therefore, some managers may suggest that developers bypass the process based on the best motives. But by offering this, they put developers in a vulnerable position, when any such step can be viewed differently depending on the people and cases.
Hint: follow the process easier
You may not need a process or rules. Instead, you may need only recommendations on how to do something with the possibility of different implementation. Well, or you can think about the official process of bypassing the standard process, for some cases. But in this case, do you need a process that is slower?
Saw something similar? Add your cases to the comments.
Source: https://habr.com/ru/post/434826/
All Articles