Motto:
Met somehow in the forest Hedgehog and Bear cub.
- Hello, Hedgehog!
- Hello, Little Bear!
So, word for word, joke for joke, and got the Hedgehog from the Bear cub in the face ...
Under the cut of the reasoning of our team leader, as well as RAS Product Development Director - Igor Marnat, about the specifics of work conflicts and possible methods for managing them.
Most of the conflicts that we encounter at work develop according to a scenario similar to the one described above in the epigraph. There are several participants who are initially quite benevolent towards each other, they are trying to solve some issue, but in the end the problem remains unresolved, and for some reason the relationship between the participants in the discussion is spoiled.
Life is diverse, in the scenario described above, variations occur. Sometimes the relations between the participants are not very good initially, sometimes there is not even a question requiring an immediate solution (as, for example, in the epigraph), sometimes after the discussion, the relations remain the same as before it began, but the issue has not been resolved in the end.
What is common in all situations that can be defined as a situation of labor conflict?
First, it is the presence of two or more parties. These parties can occupy a different place in the organization, be in a relationship of equality (colleagues in a team), or at different levels of the hierarchy (boss - subordinate), be individual (employee) or group (in cases of conflict between an employee and a team or two teams), and so on. The level of trust between the participants greatly affects the likelihood of conflict and the ease of its resolution. The better the parties know each other, the higher the level of trust, the higher the chance that they will agree. For example, members of a distributed team who have never had face-to-face contact are more likely to get into conflict over a simple work issue than people who have had at least a few face-to-face contact. Therefore, when working in distributed teams, it is very important to ensure that all team members have regular face-to-face meetings with each other.
Secondly, in a situation of conflict at work, the parties are in a situation of resolving some issue that is important for one of the parties, for both of them, or for the organization as a whole. At the same time, due to the specifics of the situation, the parties usually have enough time and various ways to solve it (formal, informal, meetings, letters, management decisions, the presence of team goals and plans, the fact that there is a hierarchy, etc.). This is the difference from the situation of solving a working (or non-working) issue in an organization from, for example, solving an important issue: “Hey, kid, what district are you from?!” on the street, or the conflict from the epigraph. In the case of solving a work issue, the quality of the work process and the culture of solving issues in the team matter.
Thirdly, the determining factor of the conflict (from the point of view of our discussion) is the fact that the parties to the process cannot independently come to a solution to the issue that suits all parties. The situation requires the intervention of a third party, an external arbitrator. This point may seem controversial, but, in essence, if the conflict situation was successfully resolved without the intervention of an external arbitrator, the issue was resolved successfully and the relations of the parties did not deteriorate, this is the situation to which one should strive. We will most likely not even find out about such a conflict, or we will find out by accident after its resolution. The more issues a team can solve on its own, the more effectively it will work.
Another characteristic feature of the conflict, which is worth mentioning is the degree of emotional intensity in the solution. Conflict is not necessarily associated with a high emotional degree. Participants do not have to shout and wave their hands for the situation to be, in essence, a conflict. The issue is not resolved, while a certain emotional tension is present (perhaps it is not explicitly expressed outwardly), which means that we are faced with a conflict situation.
Is it necessary to intervene in conflict situations at all, or is it better to let their solution take its course and wait for the problem to resolve itself? Need to. It is not always in your power or competence to resolve the conflict completely, but in any situation, in a conflict of any scale, you can take an adult position, thereby bringing a few more people around you to it, mitigate the negative consequences of the conflict and contribute to its resolution.
Before considering a few examples of conflict situations, let us dwell on several important points common to all conflicts.
When resolving a conflict, it is important to be above the fight, and not inside it (this is also called “taking a metaposition”), that is, not to be in the process of resolving as part of one of the parties. Otherwise, from an external arbiter helping the decision, you will only strengthen the position of one of the parties to the detriment of the other side. When making a decision, it is important that it be morally accepted by all parties, as they say, “bought”. So that, even if the parties were not delighted with the decision, they at least sincerely agreed to implement it. What is called being able to disagree and commit. Otherwise, the conflict will simply change its appearance, the smoldering fire will remain under the peat bog and at some point will inevitably flare up again.
The second point, partly related to the first, is that if you have already taken part in resolving the conflict, take it as seriously as possible in terms of communications and studying the context. Talk to each side personally. Separately with each, for starters. Don't settle for mail. In the case of a distributed team, at least talk via video link. Do not be satisfied with rumors and retellings of witnesses. Understand the story, what each side wants, why they want it, what they expect, have they tried to resolve this issue before, what will happen if it is not resolved, what solutions they see, how they represent the position of the other side, what, in their opinion , right or wrong, etc. Load all possible context into your head, with an open mind, assuming everyone is right. You are not inside the conflict, you are outside of it, in metaposition. If the context is available only in the mail thread, at least read it in its entirety and the threads and documents related to it. After you've read it, speak with your voice anyway. You're almost guaranteed to hear something important that isn't in the mail.
The third important point is the general approach to communication. These are ordinary things, nothing cosmic, but they are of great importance. We do not try to save time, we talk with all participants, we do not criticize a person, but we consider the consequences of his actions (not “you are rude”, but “perhaps the guys can be offended by this thing”), we give the opportunity to save face, we conduct discussions personally, and not before formation.
Conflicts are usually caused by one of two reasons. The first is related to whether a person is in the position of an adult or in the position of a child at the time of the conflict (more on this below). This is due to his emotional maturity, the ability to manage his emotions (which, by the way, is not always associated with his age). The second common reason is the imperfection of the work process, which creates situations of gray areas, in which responsibility is spread between the participants, the expectations of the parties are not transparent to each other, and the roles in the process are blurred.
Accordingly, in resolving a conflict (as well as any other issue), the manager must keep in mind three perspectives: short-term - to resolve the issue / conflict here and now, medium-term - to minimize the likelihood of another conflict for the same reason, and long-term - educating an adult culture in the team person.
In each of us there is an inner child, about three or four years old. Most of the time at work, he sleeps, but sometimes he wakes up and takes control. The child has his own priorities. It is important for him to insist that this is his sandbox, his mother loves him more, his machine is the best (the design is the best, he programs the best, ...). In a conflict situation, a child can press toys, stomp his feet and crack a spatula, but he cannot solve adult issues (solution architecture, approaches to automated testing, release dates, etc.), he does not think in terms of benefit for the team. A child in conflict can be encouraged, comforted, and sent to bed by asking him to call his adult. Before starting a discussion in conflict, make sure you are talking to an adult, not a child, and stand in the position of an adult yourself. If your honest goal at the moment is to solve a serious issue, you are in the position of an adult. If your goal is to stomp your feet and crack your spatula, this is a childish position. Send your inner child to bed and call an adult, or reschedule the discussion. A person makes an emotional decision, and then looks for a rational justification for it. The decision made by the child, based on children's priorities, will not be optimal.
In addition to behavior at the time of conflict, a child's or adult's position is also characterized by the level of responsibility that a person is ready to take on. In extreme manifestations, the childish position of a programmer, which I have met repeatedly, looks like this: I wrote the code, sent it for review - my work is finished. Reviewers should review and merge it, QA should check it, if there are problems, they will let me know. Oddly enough, even quite mature and experienced people sometimes behave in this way. The other end of the scale is that a person considers himself responsible for ensuring that his code works, is covered by tests, has been personally checked by him, has successfully passed the review (if necessary, there are no problems pinging the reviewers, discussing issues by voice, etc.) and was merged , QA will provide assistance if necessary, test scenarios are described, etc. Under normal circumstances, a programmer will either initially be closer to the adult end of the scale, or move there as experience accumulates (provided that the right culture is cultivated in the team). In extreme cases, he continues to work, usually taking a childish position, then he and the team periodically have problems and conflicts.
Cultivating the right, adult culture in the team is an important task for any manager. It takes a long time and daily effort, but the result is worth it. There are two ways to influence the culture of the team - a personal example (which will definitely be followed, the team always looks to the leader) and discussion and encouragement of correct behavior. Here, too, there is nothing abstruse or highly formal, just when discussing problems, notice that you could do something like this here, emphasize what you noticed when it was solved correctly, praise, mark on the release analysis, etc.
Consider several typical conflict situations, from simple to complex:
Conflicts not related to work issues
Quite often at work there are conflicts that are not related to work issues. Their occurrence and ease of resolution are usually directly related to the level of emotional intelligence of the participants, their level of maturity, and are not related to the perfection or imperfection of the work process.
Typical examples are someone who doesn’t use the washing machine or shower often enough, which others don’t like, it’s stuffy for someone, and it blows for another if you open the window, someone is too noisy, and others need silence to work, and so on. With the solution of conflicts of this kind, it is better not to delay and not let it take its course. By themselves, they will not resolve and will daily distract from work and poison the atmosphere in the team. Fortunately, solving them is usually not a big problem - just talk calmly (of course, one on one) with a colleague who neglects hygiene, provide comfortable seating for people who prefer silence / coolness, buy sound-absorbing headphones or put up partitions, etc.
Another example that I encountered several times during my work is the psychological incompatibility of team members. For some reason, people simply cannot work together, every communication ends in a scandal. Sometimes this is due to the fact that people hold polar views on some burning issue (usually political) and do not know how to leave them outside of work. Persuading them to tolerate each other or change their behavior is a rather hopeless task. The only exception I have come across are young open-minded colleagues whose behavior can still be gradually changed by occasional conversations. Usually the issue is successfully resolved by breeding them to different teams, or at least by providing the opportunity to very rarely intersect at work.
In all the above situations, it is worth talking with all the participants personally, discussing the situation, asking if they see a problem at all in this case, asking what, in their opinion, there are solutions, ensuring their participation in making this decision.
From the point of view of workflow optimization (the medium term that I mentioned), there is not much that can be done here, the only point for optimization is to take into account the compatibility factor when forming a team and not to put together people who will conflict in advance.
In terms of team culture, these situations are much less common in teams with mature cultures, where people respect the team and colleagues and know how to resolve issues on their own. In addition, such conflicts are resolved much more easily (often automatically) in teams where the level of trust is high, people have been working together for a long time and / or often communicate outside of work.
Conflicts related to work issues:
Such conflicts are usually caused by both reasons at once, both emotional (the fact that one of the participants is not in the position of an adult), and the imperfection of the work process itself. Perhaps the most common type of conflict that I have encountered is conflicts during code reviews or architecture discussions between developers.
I would single out two typical cases here:
1) In the first case, the developer cannot get a code review from a colleague. The patch has been submitted for review and nothing happens. At first glance, there is no obvious conflict between the two parties, but if you think about it, this is quite a conflict. The working issue is not resolved, one of the parties (waiting for a review) is experiencing obvious discomfort. An extreme subspecies of such a case is development in the community or in different teams, while the reviewer may not be interested in this particular code, due to loading or other circumstances, may not pay attention to the request for review at all, and an external arbiter (manager common to both parties ) may not exist at all.
The approach to the solution that helps in such a situation refers precisely to the long term, the culture of an adult. First, intelligent activity works. You should not expect that the code hanging on the review will attract the attention of the reviewer itself. We need to help reviewers notice it. Pingani a couple of people, ask a question on syncap, participate in discussions. It is obvious that importunity will hurt rather than help, you need to use common sense. Secondly, advance preparation works well. If the team understands what is happening and why, why this code is needed at all, the design has been discussed and agreed in advance with everyone, people are more likely to pay attention to such code and accept it for work. Thirdly, authority works. If you want to be reviewed, do a lot of reviews yourself. Make high-quality reviews, with real checks, real tests, useful comments. If your nickname is well known in the team, there are more chances that your code will be noticed.
In terms of workflow, the possible improvements here are the right prioritization aimed at helping the developer achieve his goals and the goals of the team (review others, write letters to the community, accompany the code with a description of the architecture, documentation, tests, participate in discussions with community, etc.), keep patches from waiting too long in the queue, and so on.
2) The second common case of conflicts when reviewing a code or design is different views on technical issues, coding style, choice of tools. In this case, the level of trust between the participants, belonging to the same team, and the experience of working together are of great importance. A dead end occurs when one of the participants takes a childish position, does not try to hear what the interlocutor wants to convey to him. Often, both the approach proposed by the other side and the approach proposed initially can work successfully and it does not matter which one to choose.
Once a programmer from my team (let's call him Pasha) prepared a patch with changes to the package deployment system, which was developed and maintained by colleagues from a neighboring department. One of them (Igor) had a strong opinion about exactly how Linux services should be configured when deploying packages. This opinion was different from the approach proposed in the patch, and they could not agree. As usual, the deadlines were running out, and it was necessary to come to some kind of decision, it was necessary for one of them to take an adult position. Pasha admitted that both approaches have the right to life, but he wanted his version to pass, because. there were no obvious technical advantages in either of the two options.
Our discussion looked something like this (very schematic, of course, the conversation lasted for half an hour):
- Pasha, we have a feature freeze in a few days. It is important that we collect everything and start testing as soon as possible. How would we get through Igor?
- He wants to set up services differently, he stuck comments there for me ...
- And what is there, big alterations, a lot of fuss?
- No, there is work for a couple of hours, but in the end there is no difference, and so, and so it will work, why is it needed? I made a working thing, come on and accept it.
“Listen, how long have you been discussing this?
“Yes, we’ve been trampling for a week and a half.
“Um… we can solve an issue in a couple of hours that has already taken a week and a half, and we don’t do it?”
- Well, yes, but I don’t want Igor to think that I caved in ...
- Listen, what is more important for you, to release the release, along with your decision inside, or to fight Igor? We can win, then, however, there is a good chance to fly by with the release.
- Well ... it would be cool, of course, to wipe Igor's nose, but okay, the release is more important, I agree.
- Do you really care so much what Igor thinks? To be honest, he doesn't really care at all, he just wants a unified approach in different places of the thing for which he is responsible.
- Well, ok, let me do as he asks in the comments, and start testing.
Thanks, Pasha! I was sure that of the two of you you would be older, although Igor is older than you :)
The issue was resolved, the release was released on time, Pasha did not feel much dissatisfaction, because. he proposed the solution himself and implemented it. Igor was generally satisfied, because. his opinion was taken into account and they did as he suggested.
Another kind of the same, in essence, conflict is the choice between technical solutions / libraries / approaches in the project, especially in a distributed team. In one of the projects, which was positioned as using C / C ++, in the end it turned out that the technical management of the project was categorically against using the STL (Standard Template Library). This is a standard language library that simplifies development, our team is very used to it. It turned out that the project is much closer to C than to C++, which did not inspire the team very much, because. management tried and scored really cool pluses. At the same time, the American part of the team, both engineers and managers, had worked in the company for a long time, got used to the existing state of affairs, everything suited them. The Russian part of the team was brought together quite recently, in a few weeks (including me). The Russian part of the team categorically did not want to abandon the usual approach to development.
Endless written discussions began between the two continents, letters of three or four screens flew back and forth, in group mailings and personal, from programmers to programmers and managers. As is usually the case, no one, except for the authors and their ardent supporters, read letters of this size. The chats creaked with tension, relaying multiscreen considerations about the technical advantages of the STL, how well tested it is, how secure it is, and in general, how wonderful life is with it, and how terrible it is without it.
It all lasted quite a long time, until I finally realized that we were discussing the technical aspects of the issue, and the problem was not really technical. The problem is not the merits or demerits of the STL, or the difficulty of working without it. The problem is more organizational. We just needed to understand how the company we worked for works. None of us had any previous experience in such a company. The thing was that after the development of the code and its release in production, completely different people from other teams, from other countries, were engaged in support. This huge engineering team of several tens of thousands of engineers (in aggregate) could afford only a very basic minimum of technical means, so to speak, minimum minimorum. Everything that went beyond the engineering standard established in the company could not be physically supported in the future. The level of a team is determined by the level of its weakest members. After we understood real motivation actions of the American part of the team, this issue was removed from the agenda, and together we successfully developed and released the product using the standards adopted by the company. Letters and chats in this case worked poorly, to come to a common denominator, it took several trips and a lot of personal communication.
From the point of view of the workflow, in this particular case, it would help to have a description of the tools used, requirements for them, restrictions on adding new ones, justification for such restrictions. Such documents roughly correspond to those described in the Reuse Strategy and Development Environment paragraphs of the “Manager's Handbook for Software Development” developed in . Despite his age, he perfectly describes all the main activities and stages of planning the development of software of this kind. Having such documents makes it very easy to discuss what components and approaches can be used in a product, and why.
From the point of view of culture, obviously, with a more adult position, in which the parties try to hear and understand the real motivation for the actions of colleagues and act on the basis of the priorities of the project and the team, and not personal ego, the conflict would be resolved easier and faster.
In another conflict, due to the choice of a technical solution, it also took me a noticeable time to understand the motivation of one of the parties (it was a very unusual case), but after the motivation was clear, the solution was obvious.
The situation is this: a new developer appears in a team of about 20 people, let's call him Stas. At that time, Skype was our standard tool for team communication. As it turned out later, Stas was a big fan of open standards and open source software, and used only tools and operating systems whose source codes are publicly available and which use publicly described protocols. Skype is not one of those tools. We spent a lot of time discussing the advantages and disadvantages of this approach, trying to launch Skype analogues on different operating systems, Stas trying to convince the team to switch to other standards, write to him personally by mail, call him personally on the phone, buy him a second computer specifically for Skype, etc. Finally, I realized that this problem, in essence, is not technical or organizational, it is more of an ideological, one might even say, religious (for Stas). Even if we ended up connecting Stas and Skype (which has already taken several months), the problem would arise again on any next tool. I had no real means at my disposal to change the outlook of Stas, and there was no reason to try to change the outlook of a team that worked perfectly in this environment. The person and the company were simply orthogonal in outlook. In such situations, a good solution is organizational. We transferred Stas to another team, where he was more organic.
The reason for this conflict, in my opinion, is the discrepancy between the personal culture of a particular person (who has a strong opinion that does not allow him to compromise), the culture of the company. In this case, it is, of course, the manager's fault. It was initially wrong to take him on a project of this kind. Stas eventually switched to an open source project and did very well there.
A good example of a conflict caused by both the childish position of the developer and the shortcomings of the workflow is a situation in which, in the absence of a definition of done, the developer and the QA team have different expectations regarding the readiness of the feature submitted to QA. The developer believed that it was enough to write code and throw the feature over the fence in QA - they would figure it out there. Quite an adult and experienced, by the way, a programmer, but he had such an internal quality threshold. QA disagreed with this and demanded to show and describe to them what he tested himself, and demanded a test script for them. They already had problems with functionality from this developer in the past and did not want to waste their time again. By the way, they were right - the feature really did not work, he did not check the code before transferring it to QA.
To solve the situation, I asked him to show me that everything really works (it didn’t work, and he had to fix it), we talked with the team and with the QA definition of done (we didn’t make it in writing, because we didn’t want to bureaucratize the process too much) ), but we soon parted ways with this specialist (to the general relief).
From the point of view of the workflow, possible improvements in this case are the presence of a definition of done, the requirements for supporting each feature with units and integration tests, and a description of the testing carried out by the developer. In one of the projects, we measured the level of code coverage by tests during CI, and if the coverage level fell after adding a patch, the tests were marked as failed, i.e. any new code could only be added if there were new tests for it.
Another typical example of a conflict closely related to the organization of the workflow. We have a product, a product development team, a support team, and a customer. The customer has problems with the product, he turns to support. Support analyzes the problem and understands that the problem is in the product, transfers the problem to the product team. The product team has a hot time, the release is on the way, so the ticket with the problem from the customer, lost among other tickets from the developer to whom it is assigned, hangs unattended for several weeks. Support thinks that the developer is working on a customer problem. The customer waits and hopes that they are working on his problem. In reality, nothing is happening yet. After a few weeks, the customer finally decides to take an interest in the progress and asks support how things are going. Support asks for development. The developer shudders, looks through the list of tickets and finds a ticket from the customer there. Reading a ticket from a customer, he understands that there is not enough information to solve the problem, and he needs more logs and dumps. Support requests additional information from the customer. And then the customer realizes that no one has been working on his problem all this time. And thunder rolls...
In this situation, the solution to the conflict itself is quite obvious and linear (fix the product, update the documentation and tests, appease the customer, release a hotfix, etc.). It is important to analyze the workflow and understand who is responsible for organizing the interaction between the two teams, why such a situation became possible at all. It is clear that you need to fix it in the process - someone has to monitor the big picture without reminders from customers, proactively. Tickets from the customer should stand out from the rest of the tickets from the developers. Support should see if the development is working on its tickets at the moment, if not, when it can start working, when you can expect the result. Support and development should periodically communicate and discuss the status of tickets, the collection of information necessary for debugging should be automated as much as possible, etc.
As in war the enemy tries to strike at the joint between two subunits, so in work the interaction between teams usually turns out to be the thinnest and most vulnerable point. If the support and development managers are old enough, they will be able to fix the process themselves, if not, the process will continue to generate conflicts and problems until a manager intervenes who can fix the situation.
Another typical example that I have seen repeatedly in different companies is a situation in which a product is written by one team, automatic integration tests for it are written by a second team, the infrastructure on which this is all operated is accompanied by a third team. Problems in test runs occur all the time, and the cause of problems in them can be either a product or tests and infrastructure. It is usually problematic to agree on who should do the initial problem analysis, file bugs, parse product, test and infrastructure logs, etc. Conflicts here are very frequent, and, at the same time, uniform. In the case of high emotional intensity, the participants often fall into a childish position and discussions begin in the series: “why should I be tinkering with this”, “they break down more often”, etc.
From a workflow point of view, the specific steps to resolve the issue depend on the composition of the teams, the type of tests and the product, and so on. In one of the projects, we introduced periodic shifts, in which the teams followed the tests in turn, for a week. In another, the primary analysis was always carried out by the test developers, but the analysis was very basic and the product was stable enough, so it worked well. The main thing is to ensure the transparency of the process, the clarity of expectations for all parties and the feeling of fairness of the situation for all.
Is conflict in the organization a problem at all, is it a bad sign that conflicts often (or just periodically) happen in your team? In general, no, because if there is growth, development, there is some kind of dynamics, then questions arise that have never been resolved before, conflicts may arise when they are resolved. This is an indicator that some areas need attention, that there are areas for improvement. It is bad if conflicts arise very often, are solved difficultly or for a long time. This is most likely a sign of insufficiently streamlined work processes and insufficient team maturity.
Source: habr.com