Understand: See the System Beneath the Symptom

Why organizations often have the information they need and still solve the wrong problem

The second step of the HUBER Strategy™ is Understand.

That may sound obvious. Of course we should understand the problem before trying to solve it. Everyone would agree with that in theory.

In practice, organizations skip this step all the time.

They hear a complaint, see an error, receive an escalation, or identify a performance issue, and immediately move into action. Meetings are scheduled. Tasks are assigned. Emails start flying. People begin troubleshooting, explaining, defending, or escalating.

Everyone feels busy.

Everyone feels responsive.

Everyone feels like they are doing something.

The problem is that activity is not the same thing as understanding.

In many cases, the organization is not solving the actual problem. It is solving the first visible symptom.

The Visible Issue Is Rarely the Whole Story

This is one of the most important lessons I have learned in my career.

The visible issue is rarely the whole story.

A customer says the software is broken.

An employee says the process does not work.

A leader says the team is not performing.

A project manager says the timeline is at risk.

Those statements may all be true, but they are not complete. They are the surface-level expression of something deeper. Sometimes the problem is technical. Sometimes it is procedural. Sometimes it is a training issue. Sometimes it is a communication issue. Sometimes it is a trust issue that has been building for months.

That is why Hear must come before Understand.

Hearing gathers the signal.

Understanding makes sense of it.

Without understanding, even good intentions can lead to bad decisions.

The Cost of Solving the Wrong Problem

Solving the wrong problem is expensive.

It wastes time, burns trust, frustrates employees, and teaches customers that the organization does not really understand what they are dealing with.

Worse, solving the wrong problem can create the illusion of progress. A team may close a ticket, finish a task, deliver a report, or implement a change, only to find that the original issue comes back again in a slightly different form.

That is usually a sign that the symptom was addressed, but the system was not understood.

I have seen this happen in customer support, software implementations, operations, leadership, and change management. The names of the problems change, but the pattern is consistent.

Someone reacts to what is visible.

Nobody pauses long enough to understand what created it.

FACE: A Practical Way to Understand the Problem

When I am trying to understand a problem, I like to break it down through four lenses:

• Facts
• Assumptions
• Context
• Effects

I call this FACE because it forces us to look directly at the problem before deciding what to do about it.

Facts: What do we actually know?

Facts are the information we can verify.

Not what we think happened.

Not what someone assumes happened.

Not what usually happens.

What do we actually know?

This may include:

• What changed?
• When did it start?
• Who is affected?
• How often is it happening?
• What evidence do we have?
• What has already been tried?
• What can be confirmed independently?

Facts matter because they keep the conversation grounded.

Without facts, teams often build entire plans around assumptions.

Assumptions: What are we treating as true?

Assumptions are dangerous because they often feel like facts.

This is especially true when people have experience. Experience is valuable, but it can also make us overconfident. The more familiar a situation feels, the easier it is to assume we already understand it.

That assumption may be correct.

It may also be completely wrong.

This is why I like to ask:

• What are we assuming?
• Why are we assuming it?
• What would prove this assumption wrong?
• Are we relying on history, evidence, or instinct?
• Are different teams making different assumptions?

Many organizational failures begin with people confidently acting on untested assumptions.

Context: What else is happening around the issue?

Context is where the system starts to reveal itself.

A problem rarely exists in isolation. It sits inside a larger environment made up of people, processes, incentives, history, timing, communication, and constraints.

A customer escalation may not be only about the specific issue they are reporting. It may also be about six months of slow responses, unclear ownership, missed expectations, or unresolved frustration.

An employee performance issue may not be only about the employee. It may also be about unclear priorities, poor training, conflicting direction, or a process that makes success harder than it needs to be.

Context helps us understand why the problem makes sense inside the system that produced it.

Questions worth asking include:

• What else changed recently?
• What pressure is the organization under?
• What history exists here?
• What incentives are influencing behavior?
• Where are the handoffs?
• Who owns the outcome?
• What constraints are people working within?

Context does not excuse poor outcomes.

It explains how they were produced.

That distinction matters.

Effects: What is the real impact?

Effects help separate inconvenience from urgency.

Not every issue has the same level of impact. Some problems are annoying. Some are expensive. Some create operational risk. Some damage trust. Some quietly drain morale until people stop believing anything will improve.

Understanding the effect means asking:

• Who is impacted?
• How are they impacted?
• What does this prevent them from doing?
• What happens if nothing changes?
• What risk does this create?
• What trust has already been damaged?
• What would a successful outcome actually look like?

This is especially important because different stakeholders may experience the same problem differently.

A technical team may see a minor defect.

A customer may see a production delay.

A leader may see a risk to revenue.

An employee may see another example of the organization ignoring problems they have been raising for months.

Understanding requires seeing those effects together.

Understanding Is Not Agreement

One mistake people make is assuming that understanding means agreement.

It does not.

You can understand a customer without agreeing with their conclusion.

You can understand an employee without agreeing with their behavior.

You can understand a leader’s constraints without agreeing with their decision.

Understanding does not mean surrendering judgment. It means gathering enough information to make a better judgment.

That is why this step is so important.

When people skip understanding, they often end up arguing over conclusions before they have aligned on reality.

Why Leaders Struggle With This Step

Leaders are often rewarded for decisiveness.

That can make understanding feel slow.

But there is a difference between decisive leadership and premature certainty.

Good leaders do not wait forever to act. They also do not confuse the first version of the story with the full truth.

The best leaders I have worked with are willing to ask one more question before making the call. They are willing to admit when something does not add up. They are willing to slow down just enough to avoid moving quickly in the wrong direction.

That discipline saves time.

It also builds trust.

People do not need leaders to know everything immediately. They need leaders who are committed to understanding reality before making decisions that affect everyone else.

AI Makes Understanding More Important, Not Less

Artificial intelligence can help organizations analyze large amounts of information faster than ever before.

That is powerful.

It is also risky.

If the organization does not understand the problem, AI may simply help summarize the wrong information, optimize the wrong process, or reinforce the wrong assumptions.

AI can help us see patterns, but it cannot decide which patterns matter unless we know what we are trying to understand.

That is why the human role becomes even more important.

We need people who can ask better questions, challenge assumptions, recognize context, and evaluate impact. We need people who understand not just the data, but the system the data came from.

Technology can support understanding.

It cannot replace the responsibility to think clearly.

Understanding Comes Before Trust

This is where the HUBER Strategy™ begins to build on itself.

First, we Hear.

Then, we Understand.

Only then can we begin to Build Trust.

Trust is difficult to build when people feel misunderstood. Customers lose patience when they have to explain the same thing repeatedly. Employees disengage when leadership responds to symptoms instead of causes. Teams become frustrated when decisions are made without understanding the reality of the work.

Understanding does not solve everything.

But without it, every solution is weaker than it needs to be.

HUBER Reflection

Before making your next decision, pause and FACE the problem:

• Facts: What do we actually know?
• Assumptions: What are we treating as true?
• Context: What else is happening around this issue?
• Effects: What is the real impact?

Then ask yourself one more question:

Are we solving the problem, or are we reacting to the symptom?

Understanding is the difference between motion and progress.

And in complex organizations, that difference matters.

In the next article, we’ll explore the third step of the HUBER Strategy™: Build Trust. Because once people feel heard and the real problem is understood, the next challenge is earning enough trust to move forward together.