You know what you're supposed to do. We've heard the same refrains for a decade or more. Conference keynotes. Blog posts. LinkedIn thought leadership.
Build a data culture.
Invest in data literacy.
Improve data quality at the source.
Get executive buy-in.
Implement strong governance.
Focus on business value, not technology.
All of this advice is correct. Objectively, unimpeachably correct. You know it's true. You probably have initiatives around most of these things. Or you're procuring a new tool.
And yet.
Your data infrastructure is still a mess. Pipelines still break. That "quick ask" from marketing still takes three months. Data quality issues persist despite your best efforts. Your governance policies exist mostly in a slide deck that no one actually follows. (probably named governance_v2_september_final). It must be just the specifics of your organization, your people, your culture, your inability to be disciplined. Funny thing, it's not just you.
What's happening? Are we all really that bad at execution? Is it a people problem? A culture problem? An organizational problem?
No.
Here's what I've noticed. We have an entire industry built around telling us what we should be doing. Data governance platforms. Data quality tools. Data catalogs. Data observability solutions. Data literacy programs. Change management consultants.
They explain, quite correctly, what needs to happen.
Billions are spent on these solutions, but the fundamental problems persist? Companies with the best tools, the biggest budgets, and the smartest people still struggle with the same issues.
We're all following a recipe that should work, using high-quality ingredients, following the instructions precisely... and the cake still won't rise.
Maybe the problem isn't the recipe. Maybe the problem is the we're making the wrong cake.
Take data quality. Everyone agrees it's critical. Companies invest heavily in data quality tools, cleansing processes, and validation rules.
You clean the data for finance's use case. Great. Now marketing needs the same data but in a different shape. So you clean it again, differently. Then customer support needs it. Then the ML team. Each use case requires its own transformations, its own definition of "clean."
Pretty soon you have six versions of the "same" data, all slightly different, all maintained separately, all potentially out of sync. And when something changes upstream? You get to update all six pipelines. If you can even remember where they all are.
The advice to "improve data quality" isn't wrong. But it's trying to fix a symptom of a deeper architectural problem. When your entire infrastructure is built on rigid, point-to-point pipelines from the 1980s, data quality becomes this impossible game of whack-a-mole.
Or take governance. The standard advice is to implement clear policies, establish ownership, create a data catalog. All correct. But when your data is scattered across dozens of systems, replicated in ways no one fully understands, transformed by pipelines built by engineers who left years ago... how exactly do you govern that?
You can't govern chaos. You can only document it.
We've all gotten so used to these problems that we've stopped questioning whether they're inevitable.
"Data projects take six months." Okay.
"Migrations are two-year death marches." Sure.
"Getting data requires an army of engineers." Obviously.
"Most of our data warehouse is dark data we never use." That's just how it is.
We've collectively agreed that data infrastructure is inherently complex, inherently fragile, inherently expensive. And now we're building the future of business, AI initiatives and all, on top of this shared hopelessness.
The advice we keep getting assumes this foundation is solid. It's like getting tips on how to arrange furniture in a house that's built on sand. The furniture arrangement advice might be great, but it's not going to stop your house from sinking.
Nobody wants to admit that the fundamental way we move and manage data might be wrong. That the pipeline model we've been using for forty years might not be fit for purpose anymore. That treating data as something that lives in places rather than something that flows might be limiting us.
Because admitting that means admitting that billions in infrastructure investments were built on flawed assumptions. That the tools everyone's using are solving the wrong problems. That maybe we need to rethink things from first principles.
That's a hard conversation to have. Especially when you've just spent millions on your modern data stack.
So here's what I'm wondering. What if instead of asking "How do we implement this advice better?" we asked "Why is this advice so hard to implement in the first place?"
What if the problem isn't that we need better data literacy, but that our systems make data fundamentally hard to use?
What if the issue isn't governance policies, but architectures that are impossible to govern?
What if data quality suffers not because we're not trying hard enough, but because our infrastructure destroys information in the name of cleanliness?
The advice about culture and literacy and governance and quality isn't wrong. But maybe it's like telling someone to run faster when the real problem is that they're running uphill in concrete shoes.
Perhaps it's time we started talking about the shoes.
I'm not saying burn down your entire data infrastructure tomorrow. But I am saying that if we keep accepting these problems as inevitable, we'll keep getting the same results no matter how much advice we follow. Sometimes the most important thing isn't following the best practices better. It's questioning why the best practices don't seem to work.
