The Customer Is Not Attacking You — They're Reacting to Fear

• Tags: customer-relations enterprise-support leadership crisis-management

Early in my career, I worked in IBM’s DB2 technical support team. Most of my interactions with customers happened during outages — which meant I was usually meeting them at their worst moments.

Frustrated. Anxious. Sometimes aggressive. The database was down, and their world was on fire.

It’s easy to take that personally. When someone raises their voice or sends an angry email, the natural instinct is to become defensive. To explain. To push back.

But one lesson from a senior manager changed how I approached these situations entirely:

“The customer is not attacking you. They’re reacting to fear.”

Fear, Not Aggression

When a production database goes down, the customer isn’t just dealing with a technical problem. They’re facing potential business loss, internal pressure from leadership, and uncertainty about when — or if — things will return to normal.

That pressure triggers a stress response. What looks like aggression is often fear expressing itself as urgency, frustration, or blame.

Understanding this distinction changed everything for me.

The Shift in Approach

Once I internalized this, I stopped reacting emotionally. Instead, I focused on a different goal:

Bring the situation back to a state where rational problem-solving is possible.

This meant:

  • Not taking things personally — their emotional state was about the situation, not about me
  • Staying calm under pressure — if I escalate, the situation escalates
  • Stabilizing the conversation first — before diving into technical solutions

Only after the emotional temperature drops does technical expertise actually matter.

Knowing Is Not Enough

Here’s the honest part: knowing this doesn’t make it easy.

I’m an emotional creature too. When someone raises their voice or blames me for something outside my control, my nervous system reacts. That’s not a choice — it’s automatic. Stress triggers stress.

The difference isn’t in eliminating that reaction. It’s in what happens next.

In those moments, I consciously remind myself: they’re not attacking me — they’re reacting to fear. That small reframe helps me return to a grounded state, even when my instincts are pushing me toward defensiveness.

It’s not about suppressing emotions. It’s about creating just enough space to respond rather than react.

Co-Regulation

And here’s what I’ve found: my stability becomes theirs.

When I stay grounded, the customer’s emotional state often begins to settle as well. Not because I told them to calm down — that never works — but because nervous systems are contagious. Calmness, like anxiety, spreads.

This is sometimes called co-regulation: the process by which one person’s regulated state helps another person regulate theirs. It’s well-documented in psychology, but rarely discussed in engineering contexts.

In practice, it means that staying calm isn’t just self-protection — it’s a service to the customer. It creates the conditions where they, too, can think clearly again.

Why This Matters Beyond Support

This lesson applies far beyond enterprise support. Any role that involves:

  • Customer-facing work
  • High-stakes deployments
  • Crisis response
  • Cross-functional coordination under pressure

…requires the ability to separate emotional noise from the actual problem.

In AI deployment, this is especially relevant. When an AI system fails or behaves unexpectedly, customers often can’t articulate what went wrong. They just know something is broken, and they’re scared.

The engineer who can absorb that fear, stabilize the conversation, and then apply technical judgment — that’s the person who actually solves problems in the real world.

The Meta-Skill

Looking back, this might be the most valuable thing I learned at IBM. Not database internals or debugging techniques — but how to stay grounded when everyone around me is under stress.

Technical skills get you in the room. But the ability to create conditions where those skills can be applied effectively — that’s what makes the difference between an engineer and a leader.

This insight came from four years of enterprise technical support at IBM Korea, handling mission-critical DB2 incidents for financial, telecom, and public sector clients.