Handling Conflict in Engineering Teams
When leading an engineering team, you'll inevitably have to deal with internal conflict. As a engineering manager it's your responsibility to make sure all parties involved get treated fairly and with respect, their opinions valued, and in the end coming to an fair, and often, compromising solution.
In this short article I will explore some of the most common reasons for why conflict arises; how to deal with it, or more specifically, my personal experiences on how I've dealt with it in the past; what signs to be on the look out for, so you can detect it early, and how to manage to people involved.
There are many reasons for why conflict happens in an engineering team. While not all stemming from a good place, most of what you'll encounter comes from passion. Either for the product, the project, the craft, all these reasons should be celebrated as they show real commitment to what you and the team are doing. I won't be touching on all possible reasons within this article as it would make it excessively large and hard to read, but I will go into detail about the latter, conflict that stems from genuine passion or care.
Spotting Conflict
Conflict will arise, with software engineers, almost constantly to some degree. Be it use of a library, a coding pattern or an architectural decision, as soon you have two competing ways of achieving something, you'll most likely have engineers taking sides.
Now granted, this can be improved, or at least made less frequent, by having and maintaining proper coding standards, approved libraries, and thorough documentation. However, conflict is healthy, it shows dedication and care, and as long you have to deal with it, you can be sure you have a team that's invested in the project and they like what they are working on.
Even if it's not always possible, the best way of managing conflict is to spot it early. Be on the lookout for early signs of blockers or disagreements within stand-ups, 1-on-1's or code reviews, as you might spot passive aggressive remarks or personal jabs.
However though, you will not always be able to spot it early. Sometimes it's just well hidden or happens instantly. So as soon as you're aware of conflict, either brewing, or if it's already happening, you have to act on it. Don't let it fester; don't wait to see how it evolves; don't hope it will resolve itself. Even if it does, it might have lasting impact on the team or its culture.
Handling Conflict
I remember one time, that two great developers were up in arms about how to handle the implementation of a new feature. Now, because of the nature of the work we were doing at that time, all of us lacked the whole picture on how this will end up working. And these two otherwise amazing people were undermining each other at every step due to a disagreement, which, was itself based on incomplete knowledge. After a frank, but open minded discussion with both parties, we decided that in order to settle this, we would need more information. We ended up spending an extra week, putting together a proof-of-concept, which resulted in a approach that both engineers agreed was the correct way forward.
Personally, I like being direct. So as soon as I spot conflict, even a minor one, I tend to sit everyone down and discuss the situation. Being direct doesn't mean being mean, or being a "bully". But I also don't like to let conflict go by ignored.
My approach usually takes the form of going into a meeting with all parties involved, and keeping an open mind. Hearing each person out, giving credit to their idea and intention, and boiling everything down, as much as possible, to pros and cons. The most important thing you'll have to do in this meeting is to create psychological safety. Everyone needs a chance to explain their viewpoint without being interrupted; everyone needs to be, and feel, heard.
Usually, unless there's bigger systematic issues in your team, this will provide a solution everybody will agree on as being the way forward, and in most cases that will take the form of some sort of compromise.
That is actually my preferred way setting internal team conflicts, by trying to find a good middle-ground that will satisfy everyone, basically a win-win. I do however have to point out, that this will not always be the case, that there will be times where you'll have to take firm action, and either side with one party, or rule against all with a different solution altogether.
Luckily, I haven't have to do that too much over my career, as usually, if spotted early enough, and if you pay attention to your team, you can deal with anything early and in a compromising manner, rather than having to intervene so heavy handed.
Another practical piece of advice that I need to mention is the practice of follow-ups. Especially after a conflict that took a more direct form, something that couldn't be resolved in it's incipient stages. After you have reached you conclusion and got all parties to agree on an approach, I highly recommend you do a follow-up with each person involved, individually, after a short period of time.
Give them some time to mull it over, but not enough so that's already forgotten. And then follow-up. I usually follow a 1-on-1 meeting format, and touch on how they feel about the decision that was just made, if they feel it was fair, or if their side was taken into account, what feedback do they have for you or your process. It not only shows that you care about what's going on in your team, it's also a great way to gather data, which will help you spot conflict earlier.
As I've said in the beginning, this is by no means an exhaustive list of all types of conflict that can arise, and mostly, this article gives you practical examples and advice for only the most common conflict type, yet I feel like it's important for you to understand what to look out for and how to treat conflict, on top of which you can build yourself.
Since no two teams are the same, no two managers will act the same, so a strict line by line guide will never be useful. General ideas like the ones presented above should be studied, learned, but then adapted to your own scenario, personality, and most importantly, to your own team's culture.