You Don't Fix Team Conflict by Winning the Argument

Every team I've ever joined has had at least one conflict that was already in progress before I showed up. Sometimes it's about who makes technical decisions, sometimes it's about what engineering is actually supposed to do. The specifics change, but the pattern is always the same. Someone has an expectation that doesn't match reality, and nobody has built the process to resolve it.

The instinct, especially when you're new, is to win the argument, prove you're right, convince the other person, and move on. I've tried that, and let me tell ya: it doesn't work. Not because you're wrong, but because arguments between individuals don't change systems, and the conflict is almost always a system-problem wearing a personality-problem's clothes.

Two stories. Different teams. Different years. Same lesson.

The engineer who wanted my job

At SAMi, I was brought in to rebuild the mobile apps for a medical monitoring device, a camera that streams video over a local network for caregivers of people with epilepsy and infants. The team was small, and one of the other engineers felt like the technical direction should be hers to set. She wanted to be the Tech Lead on a team small enough not to need one. The problem was that her technical decisions kept creating problems.

I'll be direct about that, because it matters. This wasn't a difference of opinion between two valid approaches. This was someone pushing for architectural choices that would have cost us weeks of rework, on a product where the stakes were people's health and safety, where time was of the essence. And because there was no formal decision-making process, every disagreement turned into a personality contest. Who could argue louder, who had the most technical jargon to throw around, who had the CEO's ear...

The fix wasn't confrontation, it was process.

I started pushing for tech spec meetings, the same kind of lightweight architecture review I've written about before. Every significant technical decision gets written down, discussed as a group, and decided with rationale documented. Not to undermine anyone, but to create a space where the quality of the idea matters more than who said it. When you force decisions into a structured format, you take the personality out of it. A bad idea documented in a spec is obviously bad in a way that a bad idea floated in a Slack thread never is, because nobody goes back and reads the Slack thread. It doesn't matter who is right when the conversation is going to be forgotten the next day, and when no minds have been changed.

It took a few rounds for the team to trust the process. But once the specs started catching real problems early, the dynamic shifted. The engineer who wanted to lead started contributing better ideas because the process gave her a framework to think through her proposals before presenting them. And I didn't have to fight her for authority, because the authority lived in the process, not in either of us.

The designer who wanted a robot

At Jane, I walked into a different kind of conflict. One of the designers told me, in so many words, that my job was to take his designs and implement them at pixel-perfect fidelity, full stop. Regardless of whether they were technically viable, regardless of performance implications, regardless of whether the interaction model he'd designed was even possible on the target platform.

I tried the direct approach first. I sat down with him and walked through the specific constraints, but he wasn't interested. The conversation ended with some version of "that's an engineering problem, not a design problem."

So I involved the PM, and he had the same conversation with the same result. The designer's position was that design delivered mockups and engineering delivered implementations, and any gap between the two was a failure of engineering.

At that point, most people either give up or go to war. I went to the director of UX instead. Not to complain about one person, but to raise the systemic issue: there was no shared process for evaluating design feasibility before committing to a direction. Designers were working in isolation, handing off finished comps, and any pushback from engineering felt like an attack on their work because they'd already invested in it emotionally and professionally.

The director got it. What came out of that conversation wasn't a reprimand or a team meeting about "collaboration." It was a set of ideation principles that required cross-functional input during the design phase, not after it. Engineers had a seat at the table before mockups were finalized. The question shifted from "can you build exactly this" to "what's the best version of this we can actually ship?" And the designer who'd been the problem, adapted. Because the system changed around him, and the new process made it natural to include engineering input rather than resist it.

Same lesson, different rooms

Both of these were, at their core, the same problem. Someone had a fixed idea about how things should work, and there was no process to challenge that idea constructively. In both cases, the person wasn't malicious. The engineer at SAMi genuinely believed her approach was right. The designer at Jane genuinely believed his role was to deliver perfect mockups and engineering's role was to execute them. And in both cases, a direct confrontation would have damaged the relationship without fixing the underlying issue.

The fix was always structural. Build a process that makes good decisions visible and bad decisions obvious. Route the problem to whoever has the authority and context to change the system, not just the behavior of one person.

What I'd tell someone walking into this

If you're joining a new team and you hit conflict in the first few weeks, resist the urge to prove yourself by winning the argument. You might be completely right, and that doesn't matter. Winning a fight with a colleague in your first month creates a dynamic that takes months to undo, and it doesn't fix the thing that caused the conflict in the first place.

Look for the missing process instead. There's almost always one, or even more. Maybe technical decisions are happening in Slack threads and nobody's writing anything down. Maybe handoffs between teams are producing friction because nobody defined what "done" looks like at each stage, and so on. Whatever the shape of the conflict, the question worth asking is this: what process, if it existed, would make this conflict unnecessary?

And when the direct approach doesn't work, escalation isn't failure. It's routing the problem to someone who can change the system, not just referee the people inside it. What came out of my escalation at Jane wasn't a talk about one designer's attitude, it was a set of principles that changed how the entire team worked together. That's the difference between winning an argument and solving a problem.