Most toxic team conflict is just a missing standard in disguise.

The Working in Teams material and HBS's Strategy Execution before it, taught me to think about teams in deliberate parts: how you design the team, the processes you run it on, how you launch it, how you support it. So when I became Head of Engineering, I built a fair amount of process. Stand-ups where the point is to surface bad news early, not to perform progress. Working sessions where supervisors and senior engineers actually sit together, argue it out, and only then open a pull request. One-on-one catch-ups to understand an engineer's strengths and where they're stuck. War rooms when something's on fire. The whole apparatus exists to keep feedback flowing up and out, so problems don't get stuck at the bottom.

But here's the thing I didn't expect to learn from running all that process: the process doesn't remove conflict, and it isn't supposed to. What it does is give conflict a place to happen safely. And once I'd watched enough of it, a pattern jumped out that I now can't unsee.

Healthy conflict and toxic conflict don't differ by topic or by temperature. They differ by whether there's a standard underneath the argument.

Where we have strong standards, and we've worked hard on them, across backend, frontend, machine learning, data engineering, disagreement stays productive. People argue hard, but they're arguing about the work, inside a shared frame everyone accepts. The heat goes into the problem. Where there's no standard yet, the same smart people can turn an argument personal fast, because there's nothing to anchor it. Everyone fills the vacuum with their own preference, and then defends the preference like it's an identity.

Two examples from my own teams.

We once held a debate on whether to standardize on Apache NiFi or Airflow for data pipelines. On paper it was a tooling decision. But the real outcome I was looking for wasn't the winner. It was whether the engineers could disagree, land somewhere and keep their eyes on the larger objective without it fracturing the team. They could. That's a team with a frame.

Another time, one of my direct reports wanted to consolidate the frontend onto a single framework, Vue.js, instead of carrying three. The team pushed back (in a meeting setting) and it got heated. But that debate was useful precisely because it was really a debate about whether we should have a standard at all. We were arguing our way toward a frame we didn't yet have. Once you have it, the next argument is calmer, because it's no longer about taste, it's about the work inside the standard.

That reframed conflict for me as a leader. When a technical argument on my teams turns sour, my first question now isn't "who's being difficult." It's "what standard is missing here that's forcing everyone to argue from preference?" Most of the time, the toxicity isn't a people problem. It's a clarity problem wearing a people problem's face. Define the standard and the same disagreement that felt personal last month becomes a normal, even healthy, technical debate this month.

Process gives conflict a safe room to happen in. Standards give it something solid to push against. You need both. Without them, you don't get less conflict, you just get conflict with nowhere useful to go.