The Problem You See Usually Isn't the Problem I Start With

A business owner usually knows when something isn't working.

Reporting takes too long. Leads aren't being followed consistently. Employees have created their own spreadsheets. The CRM isn't trusted. Customers are falling through gaps. A manager seems overwhelmed. Leadership can't get a straight answer without calling a meeting.

By the time someone asks for help, they often already have a theory about the solution.

We need a better CRM.

We need to automate this.

We need a dashboard.

We need another person.

We need to replace the EHR.

Maybe.

But after more than twenty years working inside operations, I've learned to be careful about solving the problem I'm first handed.

I want to see how the work actually happens first.

I pay attention to the things people have built around the system

One of the first things I notice is the stuff that isn't supposed to be there.

The spreadsheet someone created three years ago.

The report somebody manually downloads every Monday.

The notes kept outside the CRM.

The person everyone knows to ask when something doesn't look right.

The extra step an employee takes because, as they explain it, "If I don't do this, this other thing gets screwed up."

It is tempting to look at those things and immediately see inefficiency.

I don't.

At least not yet.

I see clues.

That ugly spreadsheet may be doing something the expensive software never did.

The employee who seems to be ignoring the official process may have discovered that the official process doesn't actually work.

And the person everyone relies on may be carrying a piece of the operation nobody ever formally designed.

Eventually, some of those workarounds should disappear.

But I want to understand why they were created before I remove them.

Then I start asking people to show me

There is a big difference between asking someone, "What's your process?" and saying, "Show me what you do."

The first usually gets you the process as it is understood.

The second gets you reality.

Where did that information come from?

What do you do with it next?

Why did you open that spreadsheet?

Who gets this after you?

How do they know it's ready?

What happens if they're out tomorrow?

What tells you this patient, customer, lead or project needs attention?

What happens when something doesn't fit the normal process?

Those aren't complicated questions.

But after enough of them, you start seeing connections.

A reporting problem may actually begin with inconsistent definitions.

A technology problem may really be a workflow problem.

A performance problem may turn out to be unclear ownership.

And sometimes the thing everyone thought was broken isn't broken at all.

It's just where another problem became visible.

I want the view from both sides of the dashboard

I've worked at the executive level, but I didn't start there.

I started at the front desk of a sleep medicine clinic.

Over the years I worked across administration, patient care, clinical technology, management and eventually executive leadership. Later I built businesses, teams, healthcare programs and the systems supporting them.

That progression matters to how I work today.

I've been the person looking at the dashboard.

I've also been the person whose work eventually became a number on somebody else's dashboard.

Those are very different views of the same operation.

So when I'm trying to understand a business, I want both.

Leadership can tell me what needs to happen.

The people doing the work can show me what it takes to make it happen.

The interesting part is usually in connecting those two views.

I don't want a prettier number. I want to know what the number means.

This becomes especially important with reporting.

Businesses can spend enormous amounts of time building dashboards without first agreeing on what they're measuring.

Two departments can use the same word and mean different things.

"Completed."

"Active."

"Qualified."

"Retained."

"Lost."

"Follow-up."

Those definitions sound obvious until you ask several people to explain them.

If the answers are different, putting the data into a beautiful dashboard doesn't resolve the disagreement. It just presents it more professionally.

Before I automate reporting, I want to know:

What exactly are we measuring?

Where does that information come from?

Who is responsible for it?

What decision is somebody supposed to make when the number changes?

Once those answers are clear, the technology part becomes much easier.

Not everything I find needs fixing

This may be the least exciting part of operations consulting.

Not everything needs to be rebuilt.

Sometimes a process works.

Sometimes employees have adapted a system in a perfectly reasonable way.

Sometimes the software everyone complains about is capable of doing what the business needs, but it was never configured correctly.

Sometimes a manual step isn't worth automating.

And sometimes the best first decision is simply to define who owns something.

I would rather keep something that works than replace it because a newer solution makes a better presentation.

The objective isn't transformation for the sake of transformation.

It's making the business easier to understand and easier to operate.

Then I build

Observation isn't the end of the work.

Eventually, something has to change.

Once I understand what's happening, I start putting structure around it.

That might mean a clearer workflow.

A defined owner.

A common set of business definitions.

A reporting structure leadership can trust.

A CRM or EHR configured around the way the organization actually operates.

An integration between systems.

Automation that removes repetitive work.

Or a dashboard that turns information into an action somebody owns.

The solution depends on what we find.

That's why I don't like starting with the answer.

I would rather understand the operation well enough that the answer becomes increasingly obvious.

If your business feels harder to run than it should

You may not need a transformation.

You may not need a new platform.

And you may not need another layer of management.

You may simply need someone to look across the business, talk to the people doing the work, connect what's happening in different places, and figure out where the friction is actually coming from.

That's usually where I start.

And once we can see the operation clearly, we can decide what is worth changing.