What Is the Actual Blocker?

One of the most valuable lessons I've learned working with enterprise customers is that people are often remarkably good at solving problems.

They are much less effective at agreeing on which problem actually needs solving.

That distinction sounds small, but I have seen it delay enterprise programmes by months.

A Programme That Looked Technical

One project I worked on had effectively stalled for almost a year.

The ingredients all appeared to be there. Multiple teams were involved. Regular meetings were taking place. Technical specialists were discussing implementation details in depth. Action trackers continued to grow.

Everyone was busy.

Very little moved forward.

Like many enterprise programmes, everyone believed the challenge was technical.

It wasn't.

The Real Blocker Was Trust

After spending time with the different stakeholders, it gradually became clear that the technology itself wasn't preventing progress at all.

The real blocker was trust.

One group simply needed confidence that a particular requirement would be met before they were willing to commit to the next step.

Nothing in the architecture needed to change.

Nothing in the implementation plan needed to change.

The question we were trying to answer needed to change.

Why the Wrong Problem Can Survive for Months

Enterprise organisations naturally gravitate towards visible problems.

A technical issue can be documented. A process gap can be mapped. A delivery delay can be tracked. Those are tangible, measurable and relatively comfortable to discuss.

Trust is different.

It may appear as hesitation, repeated requests for clarification, reluctance to approve a design or resistance to a proposed next step.

Those behaviours can easily be interpreted as technical disagreement when the real concern is whether the organisation believes the promise being made.

When the underlying concern remains unspoken, teams continue solving the visible problem because it is the only problem they can see.

The Conversation Changed Once the Problem Changed

Once the real concern was identified, the conversation changed.

Instead of debating implementation details, everyone focused on a much simpler question:

“How do we address the actual concern?”

A project that had struggled for months began moving forward within weeks.

The technology did not change.

The people did not change.

The requirements did not change.

The definition of the problem changed.

Activity Is Not Evidence of Progress

This is one of the reasons stalled programmes can be deceptive.

There may be no shortage of meetings, updates, analysis or effort. Every team may be doing exactly what it believes is required.

Yet if everyone is solving a different version of the problem, that activity creates motion without meaningful movement.

The leader's role is not simply to ask for another status update.

It is to understand why the situation is not progressing despite all the apparent activity.

Helping People Agree on the Question

This is one of the reasons I enjoy Customer Success.

The most valuable contribution is not always providing the answer.

Sometimes it is creating enough clarity for customers, technical teams and internal stakeholders to agree on the question.

Before proposing a solution, I try to ask:

• What is actually preventing progress?
• Is this technical, organisational, commercial or relational?
• What assumption are we making?
• Which concern has not yet been expressed clearly?
• What would need to become true for everyone to move forward?

A technically perfect solution to the wrong problem still leaves the programme stuck.

Sometimes the most valuable thing you can do is not provide the answer. It is helping everyone agree on the question.