The Problem With Solving Problems Too Quickly

Organizations tend to reward problem solving.

A report is wrong, so someone fixes the report. A workflow is slow, so a team automates a step. Revenue is missed, so Finance adds a reconciliation process. Sales doesn't trust the CRM, so someone builds another dashboard.

Each response may be reasonable. Sometimes it is exactly what needs to happen.

But when the same kinds of problems keep returning in different forms, solving them faster can become part of the problem.

The visible problem is often downstream

Most operational problems don't exist in isolation.

A reporting discrepancy may begin with inconsistent business definitions. A broken handoff may originate in system architecture. A manual workaround may exist because nobody owns the process across functional boundaries.

By the time the problem becomes visible to leadership, people may already have spent years adapting around it.

They create spreadsheets. They establish unofficial rules. They learn which report to use. They learn whose numbers leadership trusts. They compensate for system limitations with institutional knowledge.

The organization continues to function.

That can make the underlying problem harder to see.

Activity can hide architecture

When organizations are under pressure, the natural response is to act.

Replace the platform. Add the integration. Build the dashboard. Automate the workflow. Reorganize the team.

But each intervention makes an assumption about what is causing the problem.

If that assumption is wrong, the organization can successfully implement the solution and still have the problem.

• A new ERP can inherit inconsistent product structures.

• A new CRM can inherit unclear ownership.

• An automated workflow can accelerate a poorly designed process.

• AI can make decisions using definitions the organization never agreed upon.

Technology didn't create those ambiguities, and changing the technology doesn't necessarily resolve them.

Start with the system

This is why I increasingly begin transformation work one step earlier. Before asking what should change, establish how the business actually works today.

That means looking beyond individual technologies or functions and examining the relationships between systems, data, processes, ownership, and decisions.

• Where does information originate?

• How does it change as it moves?

• Where do documented processes differ from actual behavior?

• Who officially owns an outcome—and who does the organization actually trust when information conflicts?

• What workarounds have become so normal that nobody thinks of them as workarounds anymore?

  
  

Those questions don't delay transformation.

They reduce the likelihood of transforming the wrong thing.

Solve for the conditions, not only the symptom

The objective isn't analysis for its own sake.

It's to distinguish between a problem and the conditions that keep recreating it.

Sometimes the answer really is a better platform. Sometimes it's an integration, a redesigned process, clearer governance, a new data model, automation, or a different decision structure.

And sometimes the most valuable discovery is that the organization already owns most of what it needs—it simply hasn't connected the pieces in a way that allows them to work together.

The solution changes with the problem.

The discipline shouldn't.

Start with what's true. Then decide what should change.

Best,

Alfred McNair, MBA, ITIL®4, PSPO™   

Founder & Principal, Kinetic Scale Partners