Your Data Problem Might Not Be a Data Problem

Data has a funny way of revealing the difference between how we think the business works and how it actually works.

Like many of you, I once worked with a team that wanted access to raw data. They were smart. They knew the business. They had analysts. They knew what they wanted to build. And they were increasingly frustrated that someone else stood between them and the information they needed.

Their position was straightforward: Give us the data. We can take it from here.

They certainly weren’t lacking capable tools. They understood the questions the business was trying to answer. So why keep waiting for someone else to prepare the data for them? Clearly, it wasn’t an unreasonable argument. Which is why they, unsurprisingly, eventually got the access they wanted. And that’s exactly when things got interesting.

They couldn’t make heads or tails of the mess either.

Not because they weren’t capable. Not because the technical teams had been right and the business had been wrong. They had simply arrived at the same mess from a different direction.

Access Wasn’t the Problem

Once we started pulling at the threads, the problem wasn’t confined to the technical data environment at all.

Some of the information the business depended on came from outside the organization, but adequate expectations hadn’t yet been established around what should be delivered, when it should arrive, how information would be shared, or what “good” looked like. In other cases, capabilities had been put in place without the internal follow-through required to make them work as intended.

The common thread wasn’t that outsourcing didn’t work. It was that outsourcing the work hadn’t eliminated the business’s responsibility to establish expectations, ownership, and follow-through.

That very pattern persisted in other pockets of the organization, where key processes and systems producing the data didn’t have clearly documented responsibilities.

And then we got to questions that sounded almost absurdly basic — but every data professional will attest to how pervasive they are:

• What is a customer?

• What is a product?

  
  

Those answers depended on who you asked.

At that point, access isn’t going to save you. Neither is a prettier dashboard. You can give someone every raw table you own and unlimited analytical firepower, but technology can’t decide what your company means by customer.

Folks began to understand what I meant when I said: you can delegate execution - perhaps even decision authority, with clear parameters - but you cannot outsource responsibility for deciding where that authority belongs (not even to technology, as advanced as it is).

Technology can implement a decision, whether it’s a definition or a process. It cannot make the business agree on one.

The Data IS Doing Exactly What You’d Expect

We tend to name problems based on where we encounter them:

• Numbers don’t reconcile? Data problem. 

• Nobody trusts the report? Data problem. 

• People spend hours cleaning information before they can use it? Data problem.

Except the data is doing exactly what you’d expect it to do given everything that happened before it got there.

If two parts of the business define the same thing differently, that disagreement shows up in the data. If an external partner isn’t expected to deliver information consistently, that shows up in the data. If a process has no clear owner, that shows up in the data.

And if nobody decides what should happen when something goes wrong, somebody creates a workaround. Eventually, that workaround shows up in the data too.

The data didn’t create those problems; it just made them harder to ignore.

Data has a funny way of revealing the difference between how we think the business works and how it actually works.

Ctrl+Z Until You Find the Decision You Skipped

Technology has a phrase for moving closer to where a problem originates: shift left.

It’s a useful concept. It’s also not something I’ve heard many business leaders casually toss into conversation. So here’s my business translation: Ctrl+Z until you find the decision you skipped.

When a problem surfaces in a dashboard, report, spreadsheet, or data environment, move backward. Not endlessly, but with intention. How far? Far enough for the business to signal it actually hurts.

Pain is a clue. You see it on their faces, hear it in their tone of voice, and notice it in the emails that mysteriously lack a “reply all.”

Very often, somewhere near that behavior is a decision that was never made, never effectively communicated, or never revisited:

• What did we mean by customer?

• Who was supposed to own this?

• What did we expect our partner to provide?

• What happens when they don’t?

• Why are we collecting this information?

• What decision is somebody trying to make with it?

  
  

Those aren’t data questions. They are business questions with data consequences.

And every once in a while, you’ll discover the decision wasn’t skipped at all. The business simply outgrew the answer.

Either way, answering those questions upstream is usually a whole lot more effective than continuously compensating for them downstream.

When the Room Gets Uncomfortable

There’s something else I’ve learned to pay attention to over the years: frustration is information.

When a conversation that supposedly started with data suddenly gets tense, there’s a decent chance you’re getting closer to something that matters. And no, that doesn’t automatically mean somebody screwed up.

Sometimes it’s simply growing pains. The business got bigger. More people became involved. Processes crossed teams. Vendors were added. Systems multiplied.

Sometimes a decision actually was made — and it was the right decision for the business at the time. The business just outgrew it.

Other times, responsibility evolved without ever being explicitly assigned. Things that once worked because everyone knew who did what suddenly required someone to actually say who does what.

Either way, yesterday’s perfectly reasonable way of working can quietly become today’s source of friction if no one realizes it needs to be revisited.

And then there’s the question of who actually owns the decision. Sometimes everyone else assumed a person owned a decision, and that person had no idea it was theirs to make. Other times, they knew it was their responsibility but didn’t know they had the authority to decide. Then there are scenarios where multiple people believe they have the authority.

And sometimes, yes, we’ve found something nobody particularly wants to own.

Those situations can look remarkably similar by the time they reach the data:

• A process stalls.

• Definitions conflict.

• Information is missing.

• People create workarounds.

• The report doesn’t reconcile.

  
  

Then someone says: “We have a data problem.”

Maybe.

But why nobody decided matters. There’s a big difference between:

• I didn’t know that was mine to decide. 

• I didn’t think I was allowed to decide. 

• We don’t agree on who decides. 

• I don’t want to make that decision. 

  
  

The symptoms could be identical. The solution isn’t. And that’s why curiosity matters more than ever.

Before you hold someone accountable for a decision, make sure they know it’s theirs to make — and that they’ve actually been given the authority to make it.

Making the Unmade Decisions

Finding the unanswered question isn’t the same thing as solving the problem. It’s much easier to identify the mess than it is to take responsibility for untangling it.

• Complaining about bad data is easy. Deciding who owns it isn’t. 

• Saying a process is broken is easy. Getting the people who depend on that process to agree on how it should work can take months. 

• Pointing toward another team is easy. Rolling up your sleeves and making the decisions nobody made the first time is work. 

  
  

And sometimes those decisions take a very, very long time to sort out. That’s not necessarily failure; it’s your growth curve.

Real change doesn’t always arrive as one brilliant decision in a conference room. Why? Because you make one decision, and that exposes another. You clarify one responsibility, and that reveals an overlap somewhere else. You agree on a definition, and now you discover three processes built around three different versions of it.

So you make the next decision. And the next.

The organizations I’ve seen make meaningful progress aren’t necessarily the ones that started with the cleanest data or the best technology. They’re the ones where enough people were willing to stay in the mess long enough to move through it.

What does that pathway to success look like?

• Having the uncomfortable conversation.

• Making the previously unmade decision.

• Assigning responsibility - and managing that responsibility.

And then dealing with whatever that decision uncovers next. Not when you have time. Not when you feel motivated. Not when another external consultant tells you to.

You do it because it’s become how you actually work.

But How Do We Actually Want to Work?

Looking back at that original request for raw data access, I think there was an even bigger question underneath it. While the conversation was largely about who should have access to the data, no one was prepared to lean into how we wanted to work.

Because giving an data savvy team direct access to raw data isn’t just an access decision. It’s an operating-model decision.

Once they’re in there, are they now expected to interpret raw source structures, clean the data, determine whether it’s complete, create business rules, resolve discrepancies, and build reusable datasets for everyone else? Or should some of that happen before the data ever reaches them?

And that’s only one team.

What does Technology own? What does the Business own? What does Operations own? What does an external provider own?

Who decides what “good” looks like? And when something inevitably doesn’t work, who is responsible for doing something about it?

The list can go on and on. And frankly, that may be part of the reason nobody wants to deal with the “how” question. Granting access is faster.

But those operating questions don’t disappear when you grant access. If anything, access makes answering them more important. Otherwise, we’ve taken an unclear process and simply given more people the ability to participate in it.

You can call granting access a quick win. You can call it progress. But giving more people access to an unclear way of working isn’t transformation. It’s distribution.

Start With the Business

This is one of the reasons I’m wary when conversations begin with solutions:

• We need a dashboard. Maybe.

• We need a new system. Possibly.

• We need everyone to have access to the raw data. Perhaps.

• We need AI. We’re going to need a few more questions. 

The proposed solution might ultimately be exactly right.

But first: What does the business need to be able to do?

From there, we can sort out:

• How do we want the work to happen?

• Who should be responsible for what?

• Who has the authority to make which decisions?

• What information do those people need?

• Where should it come from?

• What needs to be true for them to trust it?

Only then can we have a particularly useful conversation about the overall system — people, processes, data, and tools — along with architecture, reporting, access, or technology.

So many of the things we call data problems are really unmade business decisions that have traveled far enough downstream to become visible in the data.

And once they’re there, it’s tempting to solve them there. It can be a quick win. It can be a goodwill gesture. It can help build trust.

It can also be yet another:

• Another reconciliation.

• Another control.

• Another spreadsheet.

• Another dashboard.

• Another analyst.

• Another platform.

• Another access request.

More sand around a rock we still haven’t moved.

Sometimes those things are necessary. Just make sure you haven’t skipped the Ctrl+Z step first so you can find the decision underneath it.

The Dashboard Might Be Telling You Something

The next time you or someone else says there is a data problem, let yourself get curious about where the problem started. Look for:

• The definition nobody agreed on.

• The expectation nobody established.

• The responsibility nobody assigned.

• The person who didn’t realize the decision was theirs.

• The authority nobody actually granted.

• The uncomfortable conversation everyone keeps finding a reason not to have.

  
  

And then ask: How do we want to work?

The goal isn’t to eliminate every uncomfortable conversation before you build the dashboard. It’s to recognize when the dashboard is telling you there’s a conversation you haven’t had yet.

Because before we decide what our data needs to do, we should probably decide how we want our business to work.