Being good at communicating with people is a skill which I’ve been training for my whole life. On this way there were a lot of different people, I had different issues with some of them and their solution was always very specific for each case. The difficulty lies in the fact that some problems are hidden and make themselves felt clearly when it is already too difficult or too late to fix something. I remembered five cases that I personally encountered. Not all of them have been solved. Not all of them I tried to solve intentionally. Further in the text you’ll find five stories illustrating the five signs of problems. I supplemented each story with a very concise clue how to fix because the real solution is very subjective.
How it was in Tolstoy’s book “Anna Karenina”:
“All happy families are alike, each unhappy family is unhappy in its own way.”
Everyone has their own understanding of the Good and the Bad. In my opinion, communication in each social group (from team to organization) has certain features which are the consequence of unconscious people’s behavior. Indeed this unconsciousness part of our behaviour is not obviously visible and leads to increased level of subjective idealism. You can notice it by spotting a divergence of declared behavior and values in the company and their real implementations. Because of the unconscious nature and unawareness of participants such problems are hidden and 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 traits that could quickly figure out the nature of existing problems and the way to find solutions.
1. Developers are Just Another Resource
Type of problem: Company vs. Employee
One manager told me: “I report to the CEO and stakeholders. And you are just a developer. ” It meant that he had a great responsibility, and for me, as a developer, there was no such responsibility. Later it turned out that he did not have his own opinion about the people who were under his command and he simply broadcast the ideas of his boss. And his boss did not communicate very closely with the developers. As a result, management was minimal and only reporting was a priority. Because of this, the attitude towards people was as if they were cogs in the mechanism. No one could say this directly by virtue of accepted norms, but things spoke for themselves. No one will tell you that your goals are not important because they will lose face. But, at the same time, no one will take your interests into account, as your manager knows exactly what you should do, how to think and what to feel. When you discuss prospects, you can be told pleasant 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, introducing big risks into the project. Obviously, your boss refuses to find a solution that would be beneficial to both. The simplest solution for him is you, doing only what he said. In the company, this attitude towards employees was maintained at a high level. As a result, the staff turnover has increased. And a number of key people (developers and product owners) left the company.
Hint: Look for Synergy
It’s normal that people have their own personal goals, and the company has their own. Quite often they don’t coincide, but it’s important to understand how much people and the company diverge in goals. Finding synergies with employees, you multiply the gain compared to the case when people just do what they are told.
2. Someone is Constantly Monitoring Your Mistakes
Type of problem: Manager vs. Employee
This is normal when people at work try to help teammates openly and respectfully discussing issues. This support atmosphere breaks if it is misused by managerial roles (team leaders or managers). The situation may be developed unintentionally and more often take place when the manager is one of participants. For example, a manager asks you what you would like to improve in the team. With good intention you tell him about a heap of things and mention slightly that it would be nice if John wrote more unit tests. When the manager talks with John he tells him that he does not write enough unit tests, as if reproaching him. After the manager’s claim John would try to find out from his colleagues what is wrong with unit tests, but they will say that everything is fine. It’s because for colleagues the problem of unit tests is very small since everyone writes them. The manager took subjective judgement and converted it to objective without taking into account all participants. At that moment, the supporting atmosphere begins to deteriorate. For John everything looks as if someone behind his back is blackening him in the eyes of the manager, but does not tell him in the eyes. At the same time no one blackens him on purpose. The situation may get worse if the manager doesn’t notice and cannot solve this problem. The insecurity of people in the team increases and makes them constantly prove something to others.
Hint: Insist on Open Discussion
In this situation the manager is the person who should be pro-active. Firstly, 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 openly talk about problems only in the presence of another person. The reasons and facts of both parties must be taken into account.
3. There is Always Someone Who is to Blame for the Mistake
Type of problem: Team vs. Employee
While analysis of mistakes is the norm, a constant reminder of past mistakes is not normal. Mistakes can occur due to lack of requirements or lack of knowledge, or due to successive failures at different stages of development, such as code review, QA, UAT. In this case, prolonged attention to one person who has made a mistake, making fun of him (even with good intention) will have a bad effect. Such behavior may cause occurrence outcasts in the team. This behavior is usually supported by one of the leading roles. The rest of the people on the team simply follow the style of the leader. In the absence of support “from above”, this behavior will not be long and will end quickly. Of course, the person who made the mistake should know about it and understand how it could be avoided so as not to step on the rake again. But don’t cling labels on him.
Hint: Stop Focusing on Mistakes
The discussion about mistakes should end immediately after all conclusions have been made. Team mates should feel support in such a situation.
4. The Team Starts Tasks Without Description and Planning
Type of problem: 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 lack authority, or lack support from the management, to postpone tasks that do not have a description. Management may say that they are very sorry and acknowledge planning mistakes that made them accept agreements that cannot be delayed. In such circumstances, developers are the ones who pay the final price. Management will repeat the same mistakes over and over again because the developers simply do what they were told. At the same time, everyone keeps their face, because there is a formal recognition of the problem and a promise to fix it … someday. During the work, developers are constantly faced with a situation where something is not described in the tasks. They begin to lag behind the schedule, rush and feel constant pressure from the leadership. As a result, developers are always the weak chain.
Hint: Protect the Team, Not Yourself
The team leader, or manager, must take responsibility for protecting the team from other managers and customers, resist their onslaught, and not let down responsibility to the level of the team. Definition of Ready for tasks should help managers prepare tasks well enough. In this case, this should become a strict rule.
5. Process Workarounds
Type of problem: Processes vs. Employees
In vivid form, I met this feature in one young company, where the processes developed 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 to complete the task faster.” This is true: sometimes bypassing the process helps to 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 some 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 poor control and a lack of trust in developers. As a result, everyone understands the problem, but changing the process is difficult due to bureaucracy (everyone needs consent, this is a bunch of meetings, etc.). 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 where any such step can be considered differently depending on people who judge and occasions.
Hint: Develop and Follow Simple Processes
You may not need a process, or rules. Instead, you may only need recommendations and guidelines on how to do something with the possibility of different execution. Or you can think of the official process of bypassing the standard process, for some cases. But in this case, do you need the process which is slower?