Epigraph:
Once upon a time, Hedgehog and Bear Cub met in the woods.
— Hello, Hedgehog!
— Hello, Bear Cub!
So, word by word, joke by joke, Hedgehog got slapped by Bear Cub...
Below are the thoughts of our team lead, as well as the product development director RAS — Igor Marnat on the specifics of workplace conflicts and possible methods of managing them.
Most conflicts we encounter at work develop according to a scenario similar to the one described in the epigraph above. There are several participants, initially predisposed to each other quite amicably, who are trying to solve some issue, but ultimately the problem remains unresolved, and, for some reason, the relationships among the discussion participants end up being damaged.
Life is varied, and there are variations in the scenario described above. Sometimes the relationships among participants aren't very good initially, at other times there's not even a question that requires immediate resolution (as in the epigraph), sometimes after the discussion, the relationships remain the same as before it started, yet the issue ultimately remains unresolved.
What is common in all situations that can be defined as a workplace conflict?
Firstly, it involves two or more parties. These parties can occupy different positions within the organization, be in equal relationships (teammates), or at different hierarchical levels (supervisor — subordinate), be individual (employee) or collective (in cases of conflict between an employee and a team or between two teams), and so on. The level of trust among participants greatly influences the likelihood of conflict and the ease of its resolution. The better the parties know each other, the higher the level of trust, the greater the chance they will reach an agreement. For example, distributed team members who have never communicated in person are more likely to enter a conflict situation when addressing a simple work issue than those who have met in person even a few times. Therefore, when working in distributed teams, it is very important to ensure periodic personal meetings among all team members.
Secondly, in a workplace conflict situation, the parties are faced with a problem that is important for one party, both parties, or the organization as a whole. Given the specifics of the situation, the parties usually have enough time and various ways to resolve it (formal and informal methods, meetings, letters, management decisions, team goals and plans, the presence of a hierarchy, etc.). This distinguishes a workplace issue resolution from, for example, a crucial question like, "Hey, dude, where are you from?" on the street, or the conflict mentioned in the epigraph. In the case of resolving a work issue, the quality of the work process and the culture of problem-solving within the team are significant.
Thirdly, a defining factor of conflict (from the perspective of our discussion) is the fact that the parties involved in the process are unable to independently reach a resolution that satisfies everyone. The situation requires the intervention of a third party, an external arbitrator. This point might seem debatable, but in essence, if a conflict situation is successfully resolved without the intervention of an external arbitrator, the issue is resolved successfully and the relationship between the parties does not deteriorate; this is the situation we should strive for. In such cases, we might not even learn about the conflict, or we only find out about it accidentally after it has been resolved. The more issues the team can resolve independently, the more effectively it will work.
Another characteristic feature of conflict that is worth mentioning is the degree of emotional intensity during resolution. Conflict is not necessarily associated with high emotional levels. Participants do not have to shout and wave their hands for the situation to be considered inherently conflictual. If a question remains unresolved and a certain emotional tension is present (even if it is not overtly expressed), we are facing a situation of conflict.
Is it necessary to intervene in conflict situations, or is it better to let them resolve themselves and wait for the problem to dissipate on its own? It is necessary. You may not always have the power or expertise to fully resolve a conflict, but in any situation, regardless of the scale of the conflict, you can take a mature stance, thereby bringing others around you to that position, mitigating the negative consequences of the conflict and facilitating its resolution.
Before we examine several examples of conflict situations, let's focus on a few important points that are common to all conflicts.
When resolving a conflict, it is crucial to maintain a perspective from above the fray, rather than being caught up in it (this is also referred to as taking a meta-position), meaning not to become part of one side in the resolution process. Otherwise, instead of acting as an external arbitrator helping to resolve the issue, you will only strengthen one side's position at the expense of the other. It is important that any decision made is morally accepted by all parties, so to speak, 'purchased.' This way, even if the parties are not thrilled with the decision made, they at least agree to implement it sincerely. In other words, they should be in a position to disagree and commit. Otherwise, the conflict will simply change form; the smoldering fire will remain beneath the surface and will inevitably flare up again at some point.
The second point, partially connected to the first, is that if you've decided to participate in resolving the conflict, take it very seriously in terms of communication and understanding the context. Speak personally with each party. Start with each one separately. Don't settle for emails. In the case of a distributed team, at least talk via video call. Don’t rely on rumors and witness retellings. Understand the history, what each party wants, why they want it, what their expectations are, whether they have tried to resolve this issue before, what will happen if it remains unresolved, what solutions they envision, how they view the other party's position, what they think is right or wrong, etc. Load your mind with all possible context, impartially, assuming that everyone is right. You are not inside the conflict; you are outside it, in a meta-position. If the context is only available in an email thread, at least read the entire thread and related discussions and documents. After reading, still talk it out. You will almost certainly hear something important that isn't in the emails.
The third important point is the overall approach to communication. These are ordinary things, nothing cosmic, but they carry great significance. Don’t try to save time; talk to all participants, critique not the person but the consequences of their actions (not 'you are rude,' but 'perhaps the guys might be offended by this'), allow for saving face, hold discussions personally rather than in front of the group.
Conflicts are usually caused by one of two reasons. The first is related to whether the person involved in the conflict is in an adult position or in a child position (more on this below). This is tied to their emotional maturity and ability to manage their emotions (which, by the way, is not always related to their age). The second common cause is the imperfection of the work process, which creates gray areas where responsibility is blurred among participants, and one party's expectations are not transparent to the other, with roles in the process being unclear.
Accordingly, in conflict resolution (as well as any other issue), a manager must consider three perspectives: short-term — resolving the issue/conflict here and now, medium-term — minimizing the likelihood of another conflict arising for the same reason, and long-term — fostering a culture of maturity within the team.
Each of us has an inner child, approximately three to four years old. Most of the time at work, it is asleep, but sometimes it wakes up and takes over. The child has its own priorities. It is important for it to insist that this is its sandbox, that mom loves it more, that its toy car is the best (the design is the best, it programs the best, etc.). In a conflict situation, the child may cling to its toys, stomp its feet, and hit with a shovel, but it cannot solve adult issues (solution architecture, approaches to automated testing, release timelines, etc.), and it does not think in terms of benefits for the team. The child in a conflict can be encouraged, comforted, and sent to sleep, asking it to call its adult. Before starting a discussion in a conflict situation, make sure that you are talking to the adult and not the child, and that you are also positioned as an adult. If your honest goal at the moment is to resolve a serious issue, you are in the position of an adult. If your goal is to stomp your feet and hit with a shovel — that is a childish position. Send your inner child to sleep and call the adult, or postpone the discussion. A person makes an emotional decision and then seeks a rational justification for it. A decision made by a child, based on childish priorities, will not be optimal.
In addition to behavior during conflicts, a child's or adult's position is also characterized by the level of responsibility the person is willing to take. In extreme cases, the child's position of a programmer, which I have encountered repeatedly, looks like this: I wrote the code, sent it for review — my job is done. Reviewers should look it over and merge it, QA should check it, and if there are any issues — they will inform me. Strangely enough, even quite mature and experienced people sometimes behave this way. The other extreme of the scale is a person who considers themselves responsible for ensuring their code works, is covered by tests, has been personally verified, successfully passed review (if needed, there’s no problem pinging reviewers, discussing issues verbally, etc.), and has been merged; QA will receive assistance if necessary, testing scenarios will be described, etc. Normally, a programmer is either initially closer to the adult end of the scale or shifts there as they gain experience (provided that the team fosters the right culture). In extreme cases, they continue to work, usually taking the child’s position, leading to periodic problems and conflicts within the team.
Fostering the right, adult culture within a team is an important task for any manager. It requires time and daily effort, but the result is worth it. There are two ways to influence team culture — by personal example (which will definitely be followed; the team always looks to the leader) and through discussions and encouragement of the correct behavior. There’s nothing complicated or overly formal about this; during discussions of problems, point out how things could have been done differently, emphasize when you notice a solution was achieved correctly, praise the efforts, acknowledge during release reviews, etc.
Let's consider some typical conflict situations, from simple to complex:
Conflicts unrelated to work issues
Fairly often, conflicts unrelated to work issues arise in the workplace. Their occurrence and ease of resolution are usually directly related to the level of emotional intelligence of the participants, their maturity level, and are not connected to the perfection or imperfection of the work process.
Typical examples include someone not using the washing machine or shower frequently enough, which annoys others; one person feels stuffy while another feels a draft when the window is opened; someone is too noisy while others need silence to work, and so on. It's best not to delay resolving conflicts of this nature and to avoid letting them fester. They won't resolve themselves and will distract from work and poison the team atmosphere daily. Fortunately, these issues are usually not difficult to resolve—it's enough to have a calm one-on-one conversation with the colleague neglecting hygiene, ensure comfortable seating for those who prefer quiet/cool environments, purchase sound-absorbing headphones, or install dividers, etc.
Another example I have encountered several times during my work is the psychological incompatibility of team members. For some reason, people simply cannot work together, and every interaction ends in a scandal. Sometimes this is due to the fact that individuals hold polar views on some pressing issue (usually political) and cannot leave them outside of work. Trying to convince them to endure each other or to change their behavior is quite a futile endeavor. The only exception I've encountered is young colleagues with an open mindset; their behavior can still be gradually changed through periodic discussions. Usually, the issue is successfully resolved by separating them into different teams or, at the very least, ensuring they rarely cross paths at work.
In all the situations mentioned, it's important to have individual conversations with all participants, discuss the situation, inquire if they even see a problem in this case, and ask what they believe might be solutions, ensuring their involvement in the decision-making process.
From the perspective of optimizing work processes (the medium-term outlook I mentioned), not much can be done here; the only optimization point is to consider compatibility factors when forming a team and to not put together people who will conflict in advance.
In terms of team culture, such situations occur much less frequently in teams with a mature culture, where individuals respect each other and can resolve issues independently. Moreover, such conflicts are often resolved more easily (often automatically) in teams with a high level of trust, where people have worked together for a long time and/or frequently communicate outside of work.
Conflicts related to work issues:
These conflicts are usually caused by both emotional factors (when one of the participants is not in an adult position) and the imperfections of the work process itself. Perhaps the most common type of conflict I have encountered is conflicts during code reviews or discussions about architecture among developers.
I would highlight two typical cases here:
1) In the first case, a developer cannot get a code review from a colleague. The patch has been sent for review, and nothing happens. At first glance, there is no obvious conflict between the two parties, but upon closer examination, it is indeed a conflict. The work issue remains unresolved, and one of the parties (the one awaiting the review) feels a clear discomfort. An extreme subtype of this case is development within a community or across different teams, where the reviewer may not be interested in this particular code, may overlook the review request due to workload or other circumstances, and there may not be an external arbiter (a manager common to both parties) at all.
The approach to solving this situation relates to a long-term perspective and the culture of an adult individual. Firstly, rational activity plays a key role. One shouldn't expect that a piece of code sitting for review will draw the reviewer's attention on its own. It's important to help reviewers notice it. Ping a couple of people, ask a question in a sync-up, and participate in discussions. Obviously, being overly persistent is more likely to harm than help, so common sense should prevail. Secondly, adequate preparation works well. When the team understands what is happening and why, and the purpose of the code is clear, with the design discussed and agreed upon in advance, people are more likely to notice such code and accept it for work. Thirdly, authority matters. If you want your code to be reviewed, do a lot of reviews yourself. Conduct quality reviews with real checks, actual tests, and valuable comments. If your username is well-regarded in the team, there’s a greater chance your code will be noticed.
From a workflow perspective, potential improvements here include proper prioritization aimed at helping the developer achieve individual and team goals (reviewing others, writing community emails, accompanying code with architecture descriptions, documentation, tests, participating in community discussions, etc.), preventing patches from getting stuck in the queue for too long, and so on.
2) The second common scenario for conflicts during code or design reviews involves differing views on technical issues, coding style, and tool selection. The level of trust between participants, team cohesion, and experience with collaborative work is crucial. A deadlock occurs when one participant takes a juvenile stance and fails to listen to what the other party is trying to convey. Often, both the approach suggested by the other party and the originally proposed method can work successfully, and it doesn’t fundamentally matter which one is chosen.
Once, a programmer from my team (let's call him Pasha) prepared a patch with changes to the package deployment system, which had been developed and maintained by colleagues from the neighboring department. One of them (Igor) had a strong opinion on how Linux services should be configured when deploying packages. This opinion differed from the approach suggested in the patch, and they could not come to an agreement. As usual, deadlines were looming, and a decision needed to be made; someone had to take a mature stance. Pasha acknowledged that both approaches had their merits, but he wanted his option to be accepted, as there were no clear technical advantages to either option.
Our discussion looked somewhat like this (very schematic, of course, the conversation lasted half an hour):
— Pasha, we have a feature freeze in a few days. It's important that we compile everything and start testing as soon as possible. How can we get through to Igor?
— He wants to configure the services differently; he left me a bunch of comments...
— And what, are there big changes, a lot of fuss?
— Not really; it would take a couple of hours, but in the end, there’s really no difference; it will work either way, so what's the point? I made something that works; let's just accept it.
— Listen, how long have you been discussing this?
— We've been at it for about a week and a half.
— Um... we can resolve an issue that has already taken a week and a half in a couple of hours, and we're not doing it?
— Well, yes, but I don't want Igor to think I'm giving in...
— Tell me, what's more important to you, getting the release out with your solution included, or beating Igor? We can beat him, but that means there's a good chance we'll miss the release.
— Well... it would be cool to stick it to Igor, but okay, the release is more important, I agree.
— Is it really that important to you what Igor thinks? Honestly, he doesn't really care; he just wants a consistent approach in different places of the thing he’s responsible for.
— Alright, let me do it the way he asks in the comments, and we’ll start testing.
— Thank you, Pasha! I was confident that out of the two of you, you would be the more mature one, even though Igor is older than you :)
The issue was resolved, the release was delivered on time, and Pasha didn't express any particular dissatisfaction since he himself proposed the solution and implemented it. Igor was generally pleased because his opinion was taken into account and the solution was implemented as he suggested.
Another type of the same conflict essentially involves choosing between technical solutions/libraries/approaches in a project, especially in a distributed team. In one project that was positioned as using C/C++, it turned out that the project's technical management was categorically opposed to using the STL (Standard Template Library). This is a standard library of the language that simplifies development, and our team was quite accustomed to it. It turned out that the project was much closer to C than to C++, which wasn't very inspiring for the team, as the management had made an effort and recruited some really good C++ developers. Meanwhile, the American part of the team, both engineers and managers, had been working at the company for a long time, accustomed to the current state of affairs, and were satisfied with it. The Russian part of the team was gathered together only recently, within a few weeks (including myself). The Russian team was categorically unwilling to give up their accustomed approach to development.
Endless written discussions began between the two continents, emails several screens long flew back and forth, in group and personal messages, from programmers to programmers and managers. As is often the case, no one read emails of this length except for the authors and their fervent supporters. Chats crackled with tension, conveying extensive thoughts in various directions regarding the technical advantages of STL, how well it is tested, safe it is, and how wonderful life is with it, and how terrible it is without it.
This lasted quite a long time until I finally realized that we were discussing the technical aspects of the issue, while the problem was actually not technical. The issue is not about the merits or demerits of STL or the difficulties of working without it. It's rather an organizational problem. We needed to understand how the company we were working for was structured. None of us had experience working in such a company before. The fact was that after the code was developed and released into production, support was handled by completely different people from other teams in other countries. This huge engineering team of several tens of thousands of engineers (in total) could afford only the very basic minimum of technical tools, so to speak, the minimum of the minimum. Anything that went beyond the engineering standard established in the company could not be supported in the future. The level of a team is determined by the level of its weakest members. After we understood the real motivation of the American part of the team, this issue was taken off the agenda, and we all successfully developed and released the product together, using the standards accepted in the company. In this case, emails and chats worked poorly; it took several trips and a lot of personal communication to reach a common denominator.
From the perspective of the workflow, in this specific case, having a description of the tools used, requirements for them, limitations on adding new ones, and the rationale for such limitations would have been helpful. Such documents roughly correspond to those described in the Reuse Strategy and Development Environment sections of the "Manager’s Handbook for Software Development" developed at . Despite its age, it perfectly describes all the main activities and stages of planning software development of this kind. Having such documents greatly simplifies the discussion process regarding which components and approaches can be used in the product and why.
From a cultural standpoint, it is clear that with a more mature position, where parties try to hear and understand the real motivations behind their colleagues' actions and operate based on the project's and team's priorities rather than personal ego, conflicts would be resolved more easily and quickly.
In another conflict regarding the choice of a technical solution, I also needed significant time to understand one party's motivation (the situation was quite unusual), but once the motivation was clear, the decision became obvious.
Here's the situation: a new developer joined our team of about 20 people, let's call him Stas. At that time, our standard communication tool was Skype. It later turned out that Stas was a big fan of open standards and open-source software, and only used tools and operating systems whose source codes were publicly available and adhered to publicly described protocols. Skype does not fall into that category. We spent an enormous amount of time discussing the pros and cons of this approach, trying to run Skype alternatives on different operating systems, and attempts by Stas to convince the team to switch to other standards, write to him personally via email, call him directly, buy him a second computer specifically for Skype, etc. Eventually, I realized that this was essentially not a technical or organizational issue; it was more a matter of worldview, even, one might say, a religious issue (for Stas). Even if we eventually managed to connect Stas to Skype (which took several months), the problem would arise again with any subsequent tool. I had no real means to change Stas's worldview, and there were no grounds to try to change the team's worldview, which was functioning well in this environment. The person and the company simply had orthogonal worldviews. In such situations, a good solution is often organizational. We transferred Stas to another team where he was more suited.
In my opinion, the reason for this conflict lies in the mismatch between an individual's personal culture (who has a strong opinion that doesn't allow for compromises) and the company's culture. In this case, it was certainly a manager's mistake. It was fundamentally wrong to bring him onto a project of this nature. Eventually, Stas moved on to a project focused on open-source software and excelled there.
A good example of a conflict caused by both the immature position of the developer and flaws in the workflow is the situation where, in the absence of a definition of done, the developer and the QA team have different expectations regarding the readiness of a feature handed over to QA. The developer believed that it was enough to write the code and throw the feature over the fence to QA—they would figure it out. By the way, he was quite an adult and experienced programmer, but that was his internal quality threshold. QA disagreed and demanded that he show and describe what he had checked himself, and requested a testing scenario for them. They had already faced issues with functionality from this developer in the past and didn’t want to waste their time again. By the way, they were right—the feature indeed didn’t work; he had not checked the code before passing it to QA.
To resolve the situation, I asked him to show me that everything was indeed working (it wasn't, and he had to fix it). We discussed the definition of done with the team and QA (didn't make it written down because we didn't want to bureaucratize the process too much), and we soon parted ways with this specialist (to everyone's relief).
From a workflow perspective, potential improvements in this case include having a definition of done, requirements for each feature to be accompanied by unit and integration tests, and documentation of the testing performed by the developer. In one of the projects, we measured the level of code coverage during CI, and if the coverage level dropped after adding a patch, the tests were marked as failed; that is, 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 work processes. We have a product, a development team for that product, a support team, and a client. The client encounters issues with the product and reaches out to support. Support analyzes the problem and realizes that it lies within the product, forwarding the issue to the product team. The product team is busy with a release approaching, so the client's ticket, lost among the other tickets assigned to a developer, hangs for weeks without attention. Support believes the developer is working on the client's problem. The client waits and hopes someone is addressing their issue. In reality, nothing is happening. After a few weeks, the client finally decides to check in on the progress and asks support how things are going. Support inquires with the developers. The developer jolts, reviews the ticket list, and finds the client's ticket there. While reading the client's ticket, they realize that there is insufficient information to resolve the issue and that they need additional logs and dumps. Support requests more information from the client. At this point, the client realizes that no one has been working on their problem this whole time. And thunder will strike ...
In this situation, the solution to the conflict is quite clear and linear (fix the product, update documentation and tests, appease the client, release a hotfix, etc.). It is important to analyze the workflow and understand who is responsible for organizing the interaction between the two teams, and why such a situation was even possible. Clearly, something needs to be fixed in the process — someone needs to monitor the bigger picture without reminders from clients, proactively. Client tickets should stand out among other tickets for developers. Support should see whether development is currently working on its tickets, and if not, when they will be able to start and when results can be expected. Support and development should periodically communicate and discuss ticket statuses, and the gathering of necessary debugging information should be as automated as possible, etc.
Just as in war the enemy tries to strike at the junction between two divisions, in work the most delicate and vulnerable spot is often the interaction between teams. If support and development managers are mature enough, they can fix the process themselves; if not, the process will continue to generate conflicts and issues until a manager intervenes who can resolve the situation.
Another characteristic example I have encountered multiple times in different companies is the situation where one team develops the product, a second team creates automated integration tests for it, and a third team manages the infrastructure on which everything runs. Problems during test runs occur constantly, and the issues can stem from the product, the tests, or the infrastructure. It is usually problematic to agree on who should perform the initial analysis of issues, file bugs, and parse the logs of the product, tests, and infrastructure, etc. Conflicts are quite frequent here, and at the same time, they tend to be uniform. In situations with high emotional tension, participants often revert to childlike positions, leading to discussions like, 'Why should I deal with this?' or 'They break more often,' and so on.
From a workflow perspective, the specific steps to resolve issues depend on the makeup of the teams, the types of tests, and the product, etc. In one of the projects, we introduced periodic on-call duties, where teams monitored the tests in rotation, each for a week. In another instance, the initial analysis was always conducted by the test developers, but this analysis was quite basic, and the product was stable enough, so it worked reasonably well. The key is to ensure process transparency, clarity of expectations for all parties, and a sense of fairness in the situation for everyone.
Is conflict within an organization a problem at all? Is it a bad sign that your team often (or just occasionally) experiences conflicts? Generally, no. If there is growth, development, and some dynamics, new questions arise that were never addressed before, and conflicts may occur during their resolution. This indicates that certain areas require attention and that there are opportunities for improvement. It is problematic if conflicts arise too frequently and are difficult or time-consuming to resolve. This is likely a sign of poorly established workflows and a lack of team maturity.
Source: habr.com
