Conflict Is Not the Problem
Every engineering team I have worked in has somewhat level of conflicts. For example, across different squads and projects, conflicts show up in different forms — disagreements about technical direction, frustration over code review feedback, tension between teams with overlapping responsibilities. It does not matter how good the people are. Put smart, opinionated engineers together, and friction will happen.
The mistake is treating conflict as something that should not exist. It always will. The real question is: why does it happen, and how do we make it productive instead of destructive?
Why Conflicts Happen
From what I see, most conflicts in engineering teams come from a few root causes:
Preference disguised as principle. Two engineers disagree on an approach — tabs vs spaces, monolith vs microservice, REST vs gRPC. Both think their way is "better," but often it is just preference. The problem is when people defend preference as if it is a technical requirement. I see this a lot in code reviews. Someone pushes back on a pattern not because it is wrong, but because it is not how they would write it.
Missing context. This is the biggest one. Engineer A makes a decision that looks bad to Engineer B, but Engineer B does not know the constraints Engineer A is dealing with. Maybe there is a deadline, maybe there is a dependency they do not see, maybe the PM changed the requirement last minute. Without that context, it is easy to assume the other person is just making a bad choice. At Unity, where multiple teams work on connected systems, this happens often — one team's trade-off looks like another team's tech debt.
Equal standing, nobody can win. Two engineers or two teams both have valid arguments. Both have good reasons. But neither can convince the other. They go back and forth, the discussion does not move forward, and it just stalls. This happens because both sides have equal authority — nobody has the power to make the final call. Process can help in many cases, but sometimes process alone is not enough. When two valid opinions are deadlocked, what is actually missing is not more arguments — it is someone who takes the responsibility to decide. If that person does not exist at the current level, the conflict just sits there and wastes everyone's time.
Silos. When teams do not talk to each other enough, they build assumptions about what the other team is doing. Then when they actually need to integrate, those assumptions break. The conflict is not really about the code — it is about the surprise. Nobody likes finding out at the last minute that the API they depend on works differently than they expected.
Blaming. Something breaks in production. The first instinct is to figure out who did it. Once a team develops a blame culture, people start playing defensive — writing overly cautious code, avoiding ownership of risky features, covering themselves in Slack messages. That is not healthy conflict. That is fear.
Bad day. Sometimes there is no deep reason. Someone is tired, stressed, having a bad week. A code review comment that would normally be fine feels personal. A Slack message that is meant to be neutral reads as passive-aggressive. Text-based communication makes this worse because you cannot see the other person's face.
How I Try to Mitigate It
These are things I try to promote to the team. None of them eliminate conflict, but they reduce the unnecessary kind and make the necessary kind more productive.
Process over preference. If the team agrees on a way of working — coding standards, review norms, ADRs — then individual preference matters less. When someone pushes back in a review, the question becomes "does this violate our agreed standards?" instead of "do I personally like this?" This removes a lot of pointless friction. The key is the team agrees together, not that the lead dictates.
Default to good intent. When I read a Slack message or a code review comment that feels off, I try to assume the person means well and is just expressing it badly. Most of the time that is true. Engineers are not great at writing warm, friendly text — we tend to be direct, and direct reads as cold in writing. Making "assume good intent" an explicit team norm helps a lot.
Switch from text to face. A Slack thread that goes back and forth tens times is a sign you should just hop on a call. Text strips away tone, facial expression, and body language. A 5-minute Zoom call resolves things that a 30-message thread cannot. From my own experience, many escalations die the moment two people actually see each other's faces. It is much harder to be adversarial when you are looking at someone.
Share context early. If I know my team is making a trade-off that other teams might question later, I write it down and share it proactively. A short message like "we are doing X because of Y constraint, we know Z is not ideal but here is why" prevents the "why did you do this?" conversation two weeks later. Most cross-team conflicts I see at Unity come from missing context, not bad decisions.
Hiring matters. This sounds obvious, but if someone is not a strong yes in the interview, they are a no. One person who creates constant friction can drain the entire team. Technical skills you can teach. The ability to disagree without being disagreeable is much harder to change. I would rather have a slightly less experienced engineer who communicates well than a brilliant one who makes every discussion a battle.
Treat conflict as learning. When a real disagreement happens — not a preference fight, but a genuine technical disagreement — that is actually valuable. It means people care and they are thinking critically. The goal is not to shut it down but to channel it. Write an ADR, run a quick spike, bring data instead of opinions. The conflict becomes a decision-making process instead of a fight.
Know when to escalate. Not every conflict can be resolved at the same level. When two sides both have valid points and neither can convince the other, the discussion is stuck — and more discussion will not unstick it. What is missing is not a better argument, it is decision-making authority. In that case, escalate. Bring it to someone who has the broader context and the responsibility to make the call. Escalation is not a failure. Letting a deadlock drag on for weeks because nobody wants to escalate — that is the failure.
It Never Goes Away
I do not think conflict-free teams exist. And honestly I do not think they should. A team with zero disagreements is probably a team where people stop caring or are afraid to speak up. The goal is not zero conflict — it is healthy conflict. The kind where people disagree openly, resolve it quickly, and move on without resentment.
We can not prevent every conflict but we could build an environment where conflict is safe, short-lived, and productive.