Conflict management in a team - balancing act or a vital necessity?
Epigraph:
We met once in the forest Hedgehog and Teddy Bear.
- Hello, Hedgehog!
- Hello, Little Bear!
So, word for word, joke after joke, and hedgehog received from the Bear cub in the face ...
Under the cut of discussion of our team leader, as well as director of product development RAS - Igor Marnat about the specifics of work conflicts and possible methods of managing them.
Most of the conflicts that we encounter at work develop according to a scenario similar to that described above in the epigraph. There are several participants who were initially quite sympathetic towards each other, they are trying to solve some issue, but in the end the problem remains unresolved, and for some reason the relations between the discussion participants are ruined.
')
Life is diverse; variations occur in the scenario described above. Sometimes the relations between the participants are not very good initially, sometimes there is not even a question that needs to be addressed directly (as, for example, in the epigraph), sometimes after discussion the relationship remains the same as before it started, but the question is still not resolved.
What is common in all situations that can be defined as a situation of work conflict?
The first is the presence of two or more parties. These parties can occupy a different place in the organization, be in an equality relationship (colleagues in the team), or at different levels of the hierarchy (boss - subordinate), be individual (employee) or group (in cases of conflict between the employee and the team or two teams), and so on. The probability of conflict and the simplicity of its resolution is greatly affected by the level of trust between the participants. The better the parties know each other, the higher the level of trust, the higher the chance that they will agree. For example, employees of a distributed team who have never communicated in person are more likely to enter a conflict situation when solving a simple work question than people who have personally communicated at least several times. Therefore, when working in distributed teams, it is very important to ensure periodic personal meetings of all team members 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. Moreover, 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 goals and plans of the team, the fact of the existence of a hierarchy, etc.). This is the difference from the situation of solving a working (or not working) question in an organization from, for example, solving an important question: “Uh, kid, what region are you from ?!” on the street, or a conflict from an epigraph. In the case of solving a work issue, the quality of the work process and the culture of resolving issues in a team matter.
Third, the determining factor in 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 arbiter. 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 we must strive. Most likely, we will not even learn about such a conflict, or we will find out by chance after its resolution. The more questions a team can solve on its own, the more efficient it will work.
Another characteristic of the conflict, which is worth touching on, is the degree of emotional tension in the solution. Conflict is not necessarily associated with a high emotional degree. Participants do not have to shout and wave their arms so that the situation is essentially conflicting. The issue is not resolved, a certain emotional stress is present at the same time (perhaps it is not explicitly expressed externally), 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 drift and wait for the problem to resolve itself? Need to. It’s 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 several 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 solving a conflict, it is important to be above the battle, and not inside it (this is also called “occupy a metaposition”), that is, not to be in the process of resolution as part of one of the parties. Otherwise, from an external arbiter who helps 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 enthusiastic about the decision made, they would at least sincerely agree to implement it. What is called, be able to disagree and commit. Otherwise, the conflict will simply change its appearance, 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 - if you have already taken part in resolving the conflict, take this as seriously as possible from the point of view of communication and studying the context. Speak in person on each side. Separately from each, for starters. Do not be content with mail. In the case of a distributed team, talk at least by video link. Do not be satisfied with the rumors and paraphrases of witnesses. Understand the story of what each side wants, why it wants it, what it expects, have you tried to resolve this issue earlier, what will happen if it is not resolved, what options do they see, how do they represent the position of the other side, which, in their opinion right or wrong, etc. Load into your head all possible context, open-mindedly, assuming that everyone is right. You are not inside a conflict, you are outside it, in a metaposition. If the context is available only in the mail thread, at least read the entire thread and related discussions and documents. After reading - still speak in a voice. Almost guaranteed you will hear something important that is not in the mail.
The third important point is the general approach to communication. These are ordinary things, nothing cosmic, but they are very important. We’re not trying to save time, we’re talking with all the participants, we’re not criticizing the person, but we are considering the consequences of his actions (not “you are rude”, but “perhaps the guys can take offense at this thing”), we give the opportunity to save face, we conduct discussions in person, and not before the formation.
Conflicts are usually caused by one of two reasons. The first is related to whether the 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 control his emotions (which, incidentally, is not always associated with his age). The second common reason is the imperfection of the work process, which creates situations of gray zones in which responsibility is spread between the participants, the expectations of the parties are not transparent to each other, the roles in the process are blurred.
Accordingly, in resolving the conflict (as well as any other issue), the manager should 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 - to educate an adult culture in the team person.
Each of us has an inner child, about three to four years old. Most of the time at work, he sleeps, but sometimes 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 typewriter is the best (design is the best, he programs the best, ...). In a conflict situation, the child can press toys, stomp his feet and crack with a spatula, but he cannot solve adult issues (solution architecture, approaches to automatic testing, release dates, etc.), he does not think in terms of team benefits. A child in a conflict can be encouraged, comforted, and sent to bed by asking him to call his adult. Before starting a discussion in a conflict, make sure that you are talking to an adult, not a child, and that you yourself are in the position of an adult. 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 with a spatula - this is a children's position. Put your inner child to sleep and call an adult, or postpone the discussion. A person makes an emotional decision, and then looks for him a rational justification. 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 children's or adult position is also characterized by the level of responsibility that a person is ready to take on. In extreme cases, the programmer’s childhood position, which I met repeatedly, looks like this: I wrote the code, sent it to the review - my work is finished. The reviewers should look at it and check it, QA should check it, if there are problems, they will let me know. Oddly enough, even fairly 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 tested by him, has successfully passed a review (if necessary, there are no problems pinging reviewers, discussing issues with his voice, etc.) and was smug , QA if necessary, assistance will be provided, test scenarios are described, etc. In normal cases, the programmer is either initially closer to the adult edge of the scale, or shifts there as experience accumulates (provided that the correct 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.
Education in the team of the correct, adult culture is an important task of 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 they will definitely follow, the team always looks at the leader) and discussing and encouraging the right behavior. There is also nothing abstruse or highly formal, just when discussing problems, notice that you could do something like this, emphasize that you noticed when it was decided correctly, praise, mark on the release analysis, etc.
Consider a few typical conflict situations, from simple to complex:
Non-work related conflicts
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 - someone does not often use a washing machine or shower, which is not pleasant to others, someone is stuffy, and another blows if you open a 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 drift. By themselves, they will not resolve and will daily distract from work and poison the atmosphere in the team. Fortunately, it is usually not a big problem to solve them - it’s enough to talk calmly (of course, one on one) with a colleague who neglects hygiene, provide a comfortable seating arrangement for people who prefer silence / cool, buy sound-absorbing headphones or put up partitions, etc.
Another example that I have met several times during my work is the psychological incompatibility of team members. For some reason, people simply can’t work together, each 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 the work. To convince them to tolerate each other or to change their behavior is an unpromising task. The only exception that I met was that young colleagues with open perception, their behavior can still be gradually changed by periodic conversations. Usually, the issue is successfully resolved by breeding them for different teams, or, at least, by providing the opportunity to rarely intersect at work.
In all these situations, it is worth talking with all participants in person, discussing the situation, asking whether they see a problem at all in this case, asking what, in their opinion, there are solutions, to ensure their participation in making this decision.
From the point of view of optimizing the workflow (the medium-term perspective, which I mentioned), there is not much to be done here, the only moment 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.
From the point of view of team culture, such situations arise much less often in teams with an adult culture, where people respect the team and colleagues and are able to solve problems independently. In addition, such conflicts are resolved much easier (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 (because one of the participants is not in the position of an adult) and the imperfection of the work process itself. Perhaps the most frequent type of conflict I have encountered is conflicts in the process of code review or discussion of architecture between developers.
I would single out two typical cases here:
1) In the first case, the developer cannot obtain a code review from a colleague. The patch is sent for review, and nothing happens. At first glance, there is no obvious conflict between the two sides, but if you think about it, it’s quite a conflict. The working question is not resolved, one of the parties (awaiting a review) experiences 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, he may not pay attention to the request for a review, or an external arbiter (common to both sides of the manager ) may not exist at all.
An approach to a solution that helps in such a situation refers precisely to the long-term perspective, the culture of an adult. Firstly, intelligent activity works. You should not expect that the code hanging on the review will attract the attention of the reviewer himself. We need to help reviewers notice it. Pingani a couple of people, ask a question at the syncap, participate in discussions. Obviously, importunity is more likely to hurt than help; common sense must be included. Secondly, preliminary preparation works well. If the team understands what is happening and why, why this code is needed at all, the design was discussed and agreed upon in advance with everyone, people would rather pay attention to such a code and take it to work. Thirdly, authority works. If you want to be reviewed - do a lot of review yourself. Do quality reviews, with real checks, real tests, useful comments. If your nickname is known in the team on the good side, there is a better chance that your code will be paid attention to.
From the point of view of the workflow, possible improvements here are the correct prioritization aimed at helping the developer achieve his goals and the goals of the team (doing reviews of others, writing letters to the community, accompanying the code with a description of the architecture, documentation, tests, and participating in discussions with community, etc.), do not allow patches to hang too long in the queue, and so on.
2) The second common case of conflicts when reviewing a code or design - different views on technical issues, coding style, choice of tools. At the same time, the level of trust between the participants, belonging to one team, and experience in working together is of great importance. A dead end occurs when one of the participants takes a children's position, does not try to hear what the interlocutor wants to convey to him. Often, at the same time, the approach proposed by the other side and the approach proposed initially may well work successfully and it does not matter in principle 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 supported by colleagues from a neighboring department. One of them (Igor) had his own strong opinion on how to configure Linux services 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 neither one nor the second option had obvious technical advantages.
Our discussion looked something like this (very schematic, of course, the conversation was half an hour):
- Pasha, we have feature freeze in a few days. It is important that we collect everything and begin testing as soon as possible. How would we get through Igor?
- He wants to configure the services differently, he stuck me with comments there ...
- And what is there, big alterations, a lot of fuss?
- No, it’s a couple of hours of work there, but in the end there’s no difference, and so it will work, why is it needed? I did a working thing, let's get it and take it.
“Listen, how long have you been discussing all this?”
- Yes, we’ve been marking one and a half weeks.
“Um ... can we solve a question that has already taken one and a half weeks in a couple of hours, and we are not doing it?”
- Well, yes, but I don’t want Igor to think that I caved in ...
- Listen, but what is more important for you, release a release, along with your decision inside, or pick up Igor? We can pick it up, then, however, there is a good chance to fly with the release.
- Well ... it would be fun, of course, to wipe Igor’s nose, but okay, the release is more important, I agree.
- Is it really so important for you that Igor thinks? Honestly, he’s more or less on the drum, 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 begin testing.
- Thanks, Pasha! I was sure that of the two of you, you will be older, although Igor is older than you :) The
question was resolved, the release was released on time, Pasha did not feel much discontent, because he himself proposed a solution and implemented it. Igor was generally pleased, because his opinion was taken into account and done as he proposed.
Another type of the same, in essence, conflict is the choice between technical solutions / libraries / approaches in a 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 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 really inspire the team, because management tried and scored really cool pluses. At the same time, the American part of the team, both engineers and managers, worked in the company for a long time, got used to the existing state of things, they were happy with everything. 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 a group distribution and personal, from programmers to programmers and managers. As it usually happens, no one has read letters of this size except the authors and their ardent supporters. The chats squeaked from tension, conveying multiscreen considerations in different directions regarding the technical advantages of STL, how well it is tested, safe, and in general, how wonderful life is with it, and how terrible 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 actually not technical. The problem is not the advantages or disadvantages of STL or the difficulty of working without it. The problem is rather organizational. We just needed to understand how the company in which we worked was arranged. Previously, none of us had experience in such a company. The thing was that after developing the code and releasing it 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 completely basic minimum of technical means, so to speak, minimum minimorum. Everything that went beyond the engineering standard prevailing in the company,physically could not be supported in the future. The level of the team is determined by the level of its weakest members. After we understoodthe real motivation for the 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 did not work well to come to a common denominator, it took several trips and a lot of personal communication.
From the point of view of the work process, in this particular case, a description of the means used, requirements for them, restrictions on adding new ones, justification for such restrictions would help. These documents are roughly consistent with those described in the Reuse Strategy and Development Environment clauses of NASA 's “Manager's Handbook for Software Development,” developed by NASA.. Despite his age, he perfectly describes all the main activities and stages of planning software development of this kind. The presence of such documents greatly simplifies the process of discussing which components and approaches can be used in a product, and why.
From the cultural point of view, obviously, in a more adult position, in which the parties try to hear and understand the real motivation of the colleagues' actions and act on the basis of the priorities of the project and the team, rather than the personal ego, the conflict would be resolved easier and faster.
In another conflict, because of the choice of a technical solution, it also took me a considerable 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: in a team of about 20 people a new developer appears, let's call him Stas. Skype was our standard tool for team communication at that time. As it turned out later, Stas was a big fan of open standards and open source software, and used only tools and operating systems, the sources of which are publicly available, and which use the protocols described publicly. Skype does not apply to such 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’s attempts to convince the team to switch to other standards, writing to him personally by mail, calling him personally by phone, buying him a second computer specifically for Skype, etc. Finally, I realized that this is a problem, in fact,not technical and not organizational, it is rather a world outlook, even, one might say, religious (for Stas). Even if we eventually combined Stas and Skype (which took several months already), the problem would arise again on any next instrument. I had no real means at my disposal to change Stas's worldview, and there was no reason to try to change the worldview of a team that worked perfectly in this environment. Man and company were simply orthogonal in their worldview. In such situations, a good solution is organizational. We transferred Stas to another team, where he was more organic.I had no real means at my disposal to change Stas's worldview, and there was no reason to try to change the worldview of a team that worked perfectly in this environment. Man and company were simply orthogonal in their worldview. In such situations, a good solution is organizational. We transferred Stas to another team, where he was more organic.I had no real means at my disposal to change Stas's worldview, and there was no reason to try to change the worldview of a team that worked perfectly in this environment. Man and company were simply orthogonal in their worldview. 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, of course, this is a manager’s mistake. It was initially wrong to take him to a project of this kind. Stas eventually switched to an open source software project and excelled there.
A good example of a conflict caused simultaneously by the children's 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 transferred to QA. The developer believed that it was enough to write the code and throw the feature over the fence in QA - they would figure it out. Pretty adult and experienced, by the way, a programmer, but he already had such an internal threshold of quality. QA disagreed with this and demanded to show and describe to them what he checked himself, and demanded a test script for them. They already had in the past problems with functionality from this developer and did not want to waste their time in vain again. By the way, they were right - the feature really did not work, he did not check the code before passing it to QA.
To solve the situation, I asked him to show me that everything really worked (it didn’t work, and he had to fix it), we talked with the team and QA definition of done (we didn’t write it because we didn’t want to bureaucratize the process too ), but with this specialist we soon parted (to general relief).
From the point of view of the workflow, possible improvements in this case are the availability of definition of done, requirements for maintaining each feature of the unit and integration tests, a description of the testing conducted by the developer. In one of the projects, we measured the level of code coverage with tests during CI and if the level of coverage after adding a patch fell, the tests were marked as failed, i.e. any new code could be added only if there were new tests for it.
Another typical example of conflict is closely related to the organization of the work process. 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 realizes that the problem is in the product, passes the problem to the product team. The product team has a hot time, the release is on the way, so a ticket with a problem from the customer, lost among the other tickets from the developer to whom it is assigned, hangs for several weeks without attention. Support thinks 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 the support how things are going.Support asks for development. The developer flinches, looks through the list of tickets and finds a ticket from the customer there. Reading a ticket from the 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 understands that no one has worked on his problem all this time. And thunder will strike ...
In this situation, the solution to the conflict itself is quite obvious and linear (to fix the product, update the documentation and tests, pacify 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 has become possible at all. It is clear what needs to be fixed in the process - someone should 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 development is working on its tickets at the moment, if not, when it can start working, when you can expect a result. Support and development should periodically communicate and discuss the status of tickets, the collection of information necessary for debugging should be as automated as possible.etc.
Just as in the war the enemy tries to strike a joint between two divisions, so in work the most delicate and vulnerable place is usually the interaction between the teams. 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 the manager who can fix the situation intervenes.
Another characteristic example that I have met repeatedly in different companies is the 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 it is all operated is accompanied by a third team. Problems with test runs occur all the time, and the cause of problems in them can be both the product and the tests and infrastructure. It is usually problematic to agree who should perform the initial analysis of problems, file bugs, parse product logs, tests and infrastructure, etc. Conflicts here are very frequent, and at the same time, uniform. In the case of high emotional intensity, participants often fall into a children's position and begin discussions from the series: “why should I poke around with this”, “they break more often”, etc.
From the point of view of the workflow, specific steps to resolve the issue depend on the composition of teams, type of tests and product, etc. In one of the projects, we introduced periodic duty hours, during which the teams monitored the tests in turn, weekly. In another, the primary analysis was always carried out by test developers, but the analysis was very basic and the product was stable enough, so it worked well. The main thing is to ensure transparency of the process, clarity of expectations for all parties and a sense of fairness for everyone.
Is a conflict in the organization a problem at all, is it a bad sign that conflicts often occur in your team (or just periodically)? In general, no, because if there is growth, development, there is some kind of dynamics, then there are questions that have never been resolved before, conflicts can arise when solving them. This is an indicator that some areas need to be paid attention to, that there are areas for improvement. It’s bad if conflicts arise very often, they are solved difficultly or for a long time. This is most likely a sign of insufficiently streamlined work processes and insufficient maturity of the team.
We met once in the forest Hedgehog and Teddy Bear.
- Hello, Hedgehog!
- Hello, Little Bear!
So, word for word, joke after joke, and hedgehog received from the Bear cub in the face ...
Under the cut of discussion of our team leader, as well as director of product development RAS - Igor Marnat about the specifics of work conflicts and possible methods of managing them.
Most of the conflicts that we encounter at work develop according to a scenario similar to that described above in the epigraph. There are several participants who were initially quite sympathetic towards each other, they are trying to solve some issue, but in the end the problem remains unresolved, and for some reason the relations between the discussion participants are ruined.
')
Life is diverse; variations occur in the scenario described above. Sometimes the relations between the participants are not very good initially, sometimes there is not even a question that needs to be addressed directly (as, for example, in the epigraph), sometimes after discussion the relationship remains the same as before it started, but the question is still not resolved.
What is common in all situations that can be defined as a situation of work conflict?
The first is the presence of two or more parties. These parties can occupy a different place in the organization, be in an equality relationship (colleagues in the team), or at different levels of the hierarchy (boss - subordinate), be individual (employee) or group (in cases of conflict between the employee and the team or two teams), and so on. The probability of conflict and the simplicity of its resolution is greatly affected by the level of trust between the participants. The better the parties know each other, the higher the level of trust, the higher the chance that they will agree. For example, employees of a distributed team who have never communicated in person are more likely to enter a conflict situation when solving a simple work question than people who have personally communicated at least several times. Therefore, when working in distributed teams, it is very important to ensure periodic personal meetings of all team members 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. Moreover, 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 goals and plans of the team, the fact of the existence of a hierarchy, etc.). This is the difference from the situation of solving a working (or not working) question in an organization from, for example, solving an important question: “Uh, kid, what region are you from ?!” on the street, or a conflict from an epigraph. In the case of solving a work issue, the quality of the work process and the culture of resolving issues in a team matter.
Third, the determining factor in 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 arbiter. 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 we must strive. Most likely, we will not even learn about such a conflict, or we will find out by chance after its resolution. The more questions a team can solve on its own, the more efficient it will work.
Another characteristic of the conflict, which is worth touching on, is the degree of emotional tension in the solution. Conflict is not necessarily associated with a high emotional degree. Participants do not have to shout and wave their arms so that the situation is essentially conflicting. The issue is not resolved, a certain emotional stress is present at the same time (perhaps it is not explicitly expressed externally), 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 drift and wait for the problem to resolve itself? Need to. It’s 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 several 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 solving a conflict, it is important to be above the battle, and not inside it (this is also called “occupy a metaposition”), that is, not to be in the process of resolution as part of one of the parties. Otherwise, from an external arbiter who helps 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 enthusiastic about the decision made, they would at least sincerely agree to implement it. What is called, be able to disagree and commit. Otherwise, the conflict will simply change its appearance, 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 - if you have already taken part in resolving the conflict, take this as seriously as possible from the point of view of communication and studying the context. Speak in person on each side. Separately from each, for starters. Do not be content with mail. In the case of a distributed team, talk at least by video link. Do not be satisfied with the rumors and paraphrases of witnesses. Understand the story of what each side wants, why it wants it, what it expects, have you tried to resolve this issue earlier, what will happen if it is not resolved, what options do they see, how do they represent the position of the other side, which, in their opinion right or wrong, etc. Load into your head all possible context, open-mindedly, assuming that everyone is right. You are not inside a conflict, you are outside it, in a metaposition. If the context is available only in the mail thread, at least read the entire thread and related discussions and documents. After reading - still speak in a voice. Almost guaranteed you will hear something important that is not in the mail.
The third important point is the general approach to communication. These are ordinary things, nothing cosmic, but they are very important. We’re not trying to save time, we’re talking with all the participants, we’re not criticizing the person, but we are considering the consequences of his actions (not “you are rude”, but “perhaps the guys can take offense at this thing”), we give the opportunity to save face, we conduct discussions in person, and not before the formation.
Conflicts are usually caused by one of two reasons. The first is related to whether the 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 control his emotions (which, incidentally, is not always associated with his age). The second common reason is the imperfection of the work process, which creates situations of gray zones in which responsibility is spread between the participants, the expectations of the parties are not transparent to each other, the roles in the process are blurred.
Accordingly, in resolving the conflict (as well as any other issue), the manager should 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 - to educate an adult culture in the team person.
Each of us has an inner child, about three to four years old. Most of the time at work, he sleeps, but sometimes 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 typewriter is the best (design is the best, he programs the best, ...). In a conflict situation, the child can press toys, stomp his feet and crack with a spatula, but he cannot solve adult issues (solution architecture, approaches to automatic testing, release dates, etc.), he does not think in terms of team benefits. A child in a conflict can be encouraged, comforted, and sent to bed by asking him to call his adult. Before starting a discussion in a conflict, make sure that you are talking to an adult, not a child, and that you yourself are in the position of an adult. 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 with a spatula - this is a children's position. Put your inner child to sleep and call an adult, or postpone the discussion. A person makes an emotional decision, and then looks for him a rational justification. 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 children's or adult position is also characterized by the level of responsibility that a person is ready to take on. In extreme cases, the programmer’s childhood position, which I met repeatedly, looks like this: I wrote the code, sent it to the review - my work is finished. The reviewers should look at it and check it, QA should check it, if there are problems, they will let me know. Oddly enough, even fairly 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 tested by him, has successfully passed a review (if necessary, there are no problems pinging reviewers, discussing issues with his voice, etc.) and was smug , QA if necessary, assistance will be provided, test scenarios are described, etc. In normal cases, the programmer is either initially closer to the adult edge of the scale, or shifts there as experience accumulates (provided that the correct 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.
Education in the team of the correct, adult culture is an important task of 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 they will definitely follow, the team always looks at the leader) and discussing and encouraging the right behavior. There is also nothing abstruse or highly formal, just when discussing problems, notice that you could do something like this, emphasize that you noticed when it was decided correctly, praise, mark on the release analysis, etc.
Consider a few typical conflict situations, from simple to complex:
Non-work related conflicts
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 - someone does not often use a washing machine or shower, which is not pleasant to others, someone is stuffy, and another blows if you open a 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 drift. By themselves, they will not resolve and will daily distract from work and poison the atmosphere in the team. Fortunately, it is usually not a big problem to solve them - it’s enough to talk calmly (of course, one on one) with a colleague who neglects hygiene, provide a comfortable seating arrangement for people who prefer silence / cool, buy sound-absorbing headphones or put up partitions, etc.
Another example that I have met several times during my work is the psychological incompatibility of team members. For some reason, people simply can’t work together, each 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 the work. To convince them to tolerate each other or to change their behavior is an unpromising task. The only exception that I met was that young colleagues with open perception, their behavior can still be gradually changed by periodic conversations. Usually, the issue is successfully resolved by breeding them for different teams, or, at least, by providing the opportunity to rarely intersect at work.
In all these situations, it is worth talking with all participants in person, discussing the situation, asking whether they see a problem at all in this case, asking what, in their opinion, there are solutions, to ensure their participation in making this decision.
From the point of view of optimizing the workflow (the medium-term perspective, which I mentioned), there is not much to be done here, the only moment 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.
From the point of view of team culture, such situations arise much less often in teams with an adult culture, where people respect the team and colleagues and are able to solve problems independently. In addition, such conflicts are resolved much easier (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 (because one of the participants is not in the position of an adult) and the imperfection of the work process itself. Perhaps the most frequent type of conflict I have encountered is conflicts in the process of code review or discussion of architecture between developers.
I would single out two typical cases here:
1) In the first case, the developer cannot obtain a code review from a colleague. The patch is sent for review, and nothing happens. At first glance, there is no obvious conflict between the two sides, but if you think about it, it’s quite a conflict. The working question is not resolved, one of the parties (awaiting a review) experiences 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, he may not pay attention to the request for a review, or an external arbiter (common to both sides of the manager ) may not exist at all.
An approach to a solution that helps in such a situation refers precisely to the long-term perspective, the culture of an adult. Firstly, intelligent activity works. You should not expect that the code hanging on the review will attract the attention of the reviewer himself. We need to help reviewers notice it. Pingani a couple of people, ask a question at the syncap, participate in discussions. Obviously, importunity is more likely to hurt than help; common sense must be included. Secondly, preliminary preparation works well. If the team understands what is happening and why, why this code is needed at all, the design was discussed and agreed upon in advance with everyone, people would rather pay attention to such a code and take it to work. Thirdly, authority works. If you want to be reviewed - do a lot of review yourself. Do quality reviews, with real checks, real tests, useful comments. If your nickname is known in the team on the good side, there is a better chance that your code will be paid attention to.
From the point of view of the workflow, possible improvements here are the correct prioritization aimed at helping the developer achieve his goals and the goals of the team (doing reviews of others, writing letters to the community, accompanying the code with a description of the architecture, documentation, tests, and participating in discussions with community, etc.), do not allow patches to hang too long in the queue, and so on.
2) The second common case of conflicts when reviewing a code or design - different views on technical issues, coding style, choice of tools. At the same time, the level of trust between the participants, belonging to one team, and experience in working together is of great importance. A dead end occurs when one of the participants takes a children's position, does not try to hear what the interlocutor wants to convey to him. Often, at the same time, the approach proposed by the other side and the approach proposed initially may well work successfully and it does not matter in principle 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 supported by colleagues from a neighboring department. One of them (Igor) had his own strong opinion on how to configure Linux services 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 neither one nor the second option had obvious technical advantages.
Our discussion looked something like this (very schematic, of course, the conversation was half an hour):
- Pasha, we have feature freeze in a few days. It is important that we collect everything and begin testing as soon as possible. How would we get through Igor?
- He wants to configure the services differently, he stuck me with comments there ...
- And what is there, big alterations, a lot of fuss?
- No, it’s a couple of hours of work there, but in the end there’s no difference, and so it will work, why is it needed? I did a working thing, let's get it and take it.
“Listen, how long have you been discussing all this?”
- Yes, we’ve been marking one and a half weeks.
“Um ... can we solve a question that has already taken one and a half weeks in a couple of hours, and we are not doing it?”
- Well, yes, but I don’t want Igor to think that I caved in ...
- Listen, but what is more important for you, release a release, along with your decision inside, or pick up Igor? We can pick it up, then, however, there is a good chance to fly with the release.
- Well ... it would be fun, of course, to wipe Igor’s nose, but okay, the release is more important, I agree.
- Is it really so important for you that Igor thinks? Honestly, he’s more or less on the drum, 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 begin testing.
- Thanks, Pasha! I was sure that of the two of you, you will be older, although Igor is older than you :) The
question was resolved, the release was released on time, Pasha did not feel much discontent, because he himself proposed a solution and implemented it. Igor was generally pleased, because his opinion was taken into account and done as he proposed.
Another type of the same, in essence, conflict is the choice between technical solutions / libraries / approaches in a 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 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 really inspire the team, because management tried and scored really cool pluses. At the same time, the American part of the team, both engineers and managers, worked in the company for a long time, got used to the existing state of things, they were happy with everything. 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 a group distribution and personal, from programmers to programmers and managers. As it usually happens, no one has read letters of this size except the authors and their ardent supporters. The chats squeaked from tension, conveying multiscreen considerations in different directions regarding the technical advantages of STL, how well it is tested, safe, and in general, how wonderful life is with it, and how terrible 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 actually not technical. The problem is not the advantages or disadvantages of STL or the difficulty of working without it. The problem is rather organizational. We just needed to understand how the company in which we worked was arranged. Previously, none of us had experience in such a company. The thing was that after developing the code and releasing it 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 completely basic minimum of technical means, so to speak, minimum minimorum. Everything that went beyond the engineering standard prevailing in the company,physically could not be supported in the future. The level of the team is determined by the level of its weakest members. After we understoodthe real motivation for the 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 did not work well to come to a common denominator, it took several trips and a lot of personal communication.
From the point of view of the work process, in this particular case, a description of the means used, requirements for them, restrictions on adding new ones, justification for such restrictions would help. These documents are roughly consistent with those described in the Reuse Strategy and Development Environment clauses of NASA 's “Manager's Handbook for Software Development,” developed by NASA.. Despite his age, he perfectly describes all the main activities and stages of planning software development of this kind. The presence of such documents greatly simplifies the process of discussing which components and approaches can be used in a product, and why.
From the cultural point of view, obviously, in a more adult position, in which the parties try to hear and understand the real motivation of the colleagues' actions and act on the basis of the priorities of the project and the team, rather than the personal ego, the conflict would be resolved easier and faster.
In another conflict, because of the choice of a technical solution, it also took me a considerable 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: in a team of about 20 people a new developer appears, let's call him Stas. Skype was our standard tool for team communication at that time. As it turned out later, Stas was a big fan of open standards and open source software, and used only tools and operating systems, the sources of which are publicly available, and which use the protocols described publicly. Skype does not apply to such 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’s attempts to convince the team to switch to other standards, writing to him personally by mail, calling him personally by phone, buying him a second computer specifically for Skype, etc. Finally, I realized that this is a problem, in fact,not technical and not organizational, it is rather a world outlook, even, one might say, religious (for Stas). Even if we eventually combined Stas and Skype (which took several months already), the problem would arise again on any next instrument. I had no real means at my disposal to change Stas's worldview, and there was no reason to try to change the worldview of a team that worked perfectly in this environment. Man and company were simply orthogonal in their worldview. In such situations, a good solution is organizational. We transferred Stas to another team, where he was more organic.I had no real means at my disposal to change Stas's worldview, and there was no reason to try to change the worldview of a team that worked perfectly in this environment. Man and company were simply orthogonal in their worldview. In such situations, a good solution is organizational. We transferred Stas to another team, where he was more organic.I had no real means at my disposal to change Stas's worldview, and there was no reason to try to change the worldview of a team that worked perfectly in this environment. Man and company were simply orthogonal in their worldview. 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, of course, this is a manager’s mistake. It was initially wrong to take him to a project of this kind. Stas eventually switched to an open source software project and excelled there.
A good example of a conflict caused simultaneously by the children's 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 transferred to QA. The developer believed that it was enough to write the code and throw the feature over the fence in QA - they would figure it out. Pretty adult and experienced, by the way, a programmer, but he already had such an internal threshold of quality. QA disagreed with this and demanded to show and describe to them what he checked himself, and demanded a test script for them. They already had in the past problems with functionality from this developer and did not want to waste their time in vain again. By the way, they were right - the feature really did not work, he did not check the code before passing it to QA.
To solve the situation, I asked him to show me that everything really worked (it didn’t work, and he had to fix it), we talked with the team and QA definition of done (we didn’t write it because we didn’t want to bureaucratize the process too ), but with this specialist we soon parted (to general relief).
From the point of view of the workflow, possible improvements in this case are the availability of definition of done, requirements for maintaining each feature of the unit and integration tests, a description of the testing conducted by the developer. In one of the projects, we measured the level of code coverage with tests during CI and if the level of coverage after adding a patch fell, the tests were marked as failed, i.e. any new code could be added only if there were new tests for it.
Another typical example of conflict is closely related to the organization of the work process. 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 realizes that the problem is in the product, passes the problem to the product team. The product team has a hot time, the release is on the way, so a ticket with a problem from the customer, lost among the other tickets from the developer to whom it is assigned, hangs for several weeks without attention. Support thinks 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 the support how things are going.Support asks for development. The developer flinches, looks through the list of tickets and finds a ticket from the customer there. Reading a ticket from the 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 understands that no one has worked on his problem all this time. And thunder will strike ...
In this situation, the solution to the conflict itself is quite obvious and linear (to fix the product, update the documentation and tests, pacify 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 has become possible at all. It is clear what needs to be fixed in the process - someone should 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 development is working on its tickets at the moment, if not, when it can start working, when you can expect a result. Support and development should periodically communicate and discuss the status of tickets, the collection of information necessary for debugging should be as automated as possible.etc.
Just as in the war the enemy tries to strike a joint between two divisions, so in work the most delicate and vulnerable place is usually the interaction between the teams. 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 the manager who can fix the situation intervenes.
Another characteristic example that I have met repeatedly in different companies is the 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 it is all operated is accompanied by a third team. Problems with test runs occur all the time, and the cause of problems in them can be both the product and the tests and infrastructure. It is usually problematic to agree who should perform the initial analysis of problems, file bugs, parse product logs, tests and infrastructure, etc. Conflicts here are very frequent, and at the same time, uniform. In the case of high emotional intensity, participants often fall into a children's position and begin discussions from the series: “why should I poke around with this”, “they break more often”, etc.
From the point of view of the workflow, specific steps to resolve the issue depend on the composition of teams, type of tests and product, etc. In one of the projects, we introduced periodic duty hours, during which the teams monitored the tests in turn, weekly. In another, the primary analysis was always carried out by test developers, but the analysis was very basic and the product was stable enough, so it worked well. The main thing is to ensure transparency of the process, clarity of expectations for all parties and a sense of fairness for everyone.
Is a conflict in the organization a problem at all, is it a bad sign that conflicts often occur in your team (or just periodically)? In general, no, because if there is growth, development, there is some kind of dynamics, then there are questions that have never been resolved before, conflicts can arise when solving them. This is an indicator that some areas need to be paid attention to, that there are areas for improvement. It’s bad if conflicts arise very often, they are solved difficultly or for a long time. This is most likely a sign of insufficiently streamlined work processes and insufficient maturity of the team.
Source: https://habr.com/ru/post/461043/
All Articles