Episode 016 – Conflict Is a Signal, Not a Failure

Summary

Engineers treat conflict like a system fault — find the root cause, fix it, restore steady state. In human systems, that instinct doesn’t resolve conflict. It suppresses it, and suppressed conflict doesn’t disappear. It migrates downstream and detonates where you have the least control and the highest cost. Using a real situation where avoiding early friction with a young engineer led to a near fist fight with a client and a threat to blacklist the company, Chris walks through the pattern: block the signal upstream, it explodes downstream. The episode distinguishes productive friction (signal) from destructive friction (noise) and gives three concrete moves for reading and using conflict instead of eliminating it.

Takeaways

  • Suppressing conflict doesn’t eliminate it. It reroutes it downstream to wherever you have the least control and the highest cost.
  • The absence of visible conflict in a team or relationship isn’t health. It’s a blocked signal path — people stopped surfacing things because the cost of dissent was too high.
  • The engineering instinct — find fault, fix it, restore steady state — is exactly wrong in human systems. Friction is often the system working, not the system failing.
  • “Afraid to ask for help” is data. If someone on your team won’t raise a problem, that tells you something about the cost structure you’ve built, not about their courage.
  • Early friction is cheap information. The same issue six months later is a client relationship, a disciplinary action, or a termination.
  • Productive friction is aimed at the problem. Destructive friction is aimed at a person. Your job isn’t to eliminate friction — it’s to read which type you’re looking at.

This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.

So we’ve been talking about relationships in the last few episodes. So episode 14, we talked about managing the signal going up. Last episode in 15, about influence going sideways to people who owe you nothing and don’t report to you. Both of these assume things are moving forward. This episode is about what happens when they aren’t. When friction shows up and why the engineering instinct is to eliminate that friction as quickly as possible, which is actually the wrong move. Engineers treat conflict like a system fault, something broke. So find the root cause, fix it, and restore it to steady state. We look for ways to reduce friction in systems, whether that’s actual physical friction or inefficiencies.

 

That instinct works great in technical systems. It’s exactly wrong in human systems. The absence of conflict in a human system doesn’t usually mean health. It actually means that people stopped surfacing things.

 

Now, there’s a big difference between resolving conflict and suppressing it. So resolving it means the issues get named, they get worked through and they get moved past. Suppressing it means the issues stay, but the signal goes underground, which is not where you want to be. When you suppress, you don’t lose the conflict. You merely lose visibility into it.

 

We talked about this a little bit back in episode 10 when it was about the cost of dissent. So when you made it expensive for people to push back, they wouldn’t, and you don’t get alignment there. It’s a blocked signal path. When you make the cost to push back low, or you even encourage it, or dare I say, demand it, that’s when the signal flows freely.

 

So I most certainly saw this years ago when I was still managing people. There was a young engineer and you know, I saw him not really handle conflict well, but I didn’t think it was that big a deal and he was deployed onto a project and I saw some early friction with the client, but I figured it was small and it would likely work itself out and probably a great learning opportunity for him.

 

And there was also a part of me that really wanted to avoid conflict and really wanted to avoid micromanaging. And so I stepped back and I waited. Now, unfortunately, the pressure didn’t go away. That young engineer was struggling and he was afraid to ask for help. That part, the afraid to ask, it’s part of the data.

 

I had created in the past a system where the cost of raising that problem was way too high.

 

So the friction migrated and it found itself or reared its ugly head with the client. That young engineer was ill prepared for the project that he stepped into. And he was taking far too long to implement the solution that the client was paying us to do. And this set the client’s schedule back significantly from hours to a couple of days.

 

Well, by day two, the client started to push and pushed a little harder and eventually that young engineer snapped and there was almost a fist fight. That’s when I got the phone call. That’s when the client told me if that engineer wasn’t removed from site immediately and replaced with someone capable, our company would never work for them again.

 

Now I live in a small town and reputation goes a long way. And this is a big multinational player, not someone that you want to be blacklisted from. So that was where the suppressed conflict surfaced. There was no safety relief valve and it had to go somewhere, and it exploded at a point where I had the least control and the highest cost.

 

So I obviously did not eliminate that conflict by avoiding it. When I kicked it down the road, I merely rerouted it. The small friction that I could have worked with that young engineer became a client relationship that I almost lost.

 

The pattern kind of looks like when you block the signal upstream, it detonates downstream. That earlier friction was information for me. It was a data point telling me something about preparedness, about the relationship, about what that young engineer needed. I read it as something to manage away. I figured it would work itself out. Well, it worked itself out all right. The system found its own outlet.

 

Now, not all friction is useful, but not all of it is destructive, and you need to be able to tell the difference. So productive friction is typically about the work, or about the plan, or about the approach to solving the problem. The energy is aimed at the problem and the people involved are invested in solving the issue.

 

Now, destructive friction, that’s often about status or territory, or perceived as a threat. The energy is aimed at a person. The stated disagreement is a proxy for something underneath. Now your job isn’t to eliminate friction. It’s to read which type you’re looking at. Productive friction is a signal. Destructive friction is noise.

 

Now what can we do about this? So to start with, you need to name that friction without escalating it. Saying something like, “We’re seeing this differently. I want to understand your read before we make a decision”.

 

Then you need to resist solving it instantly. The first thing people argue about is rarely the real issue. Let the situation breathe long enough for the actual concern to arise till it comes to the surface through time or discussion.

 

Then you need to separate the position from the concern. A statement like, “This timeline is unrealistic”, that’s a position. The concern underneath it might be a fear of being set up to fail, maybe not being consulted, maybe related to past blame. You can’t address what you haven’t surfaced yet.

 

So now you’ve got the mechanics for managing up, for influencing sideways and for working through friction. There’s one failure mode left. You can do all of this and still be invisible to the people who decide what happens next. That’s what we’ll talk about in the next episode.

No Comments

Sorry, the comment form is closed at this time.