Share this
by Marc de Haas on Apr 10, 2026 9:53:02 AM
In many data platforms, everything technically works. Data is available: pipelines run, dashboards load. And yet, no one fully trusts it.
The underlying issue is often not technical, but that ownership is unclear, which makes it harder to maintain consistent definitions and resolve problems quickly. But in most cases, the real issue is simpler and harder to fix: no one clearly owns the data.
If no one owns the data, no amount of tooling will make it reliable
Ownership tends to be loosely defined, sitting across multiple teams or existing more as an expectation than a clear agreement. As long as systems continue to run, that ambiguity stays in the background. Until something breaks. At that moment, it becomes obvious very quickly, because no one is fully accountable for fixing it.
Then the question becomes very simple: who is responsible for fixing this? If that question takes too long to answer, the issue isn’t technical, but organisational.
Why ownership is not a technical concern
Ownership is often treated as something the platform can support, or even enforce, when in reality it has to be decided first. Assigning ownership means being explicit about who is responsible for the quality of a dataset, who defines key metrics, and who is accountable when something goes wrong. Those decisions involve trade-offs, and they are rarely just technical. They touch on priorities, incentives, and how teams work together.
Even assigning a “data owner” in a system doesn’t mean that person feels responsible, has decision-making authority, or is accountable for outcomes. This is often where organisations spend more time, since tooling decisions are typically easier to make than defining accountability in a clear and lasting way. However, without clear decisions, ownership becomes symbolic: a name in a system, not a responsibility in practice.
When ownership stays unclear
When ownership is not clear, teams find ways to work around it.
Extra validation steps are added to catch issues that no one owns directly, multiple versions of the same metric start to appear because there is no agreed definition, and pipelines become more defensive as trust in upstream data declines. Each of these decisions makes sense in isolation, but over time they add up to a system that is harder to understand and maintain without actually becoming more reliable.
Over time, they also make the system more expensive and slower to deliver value.
As trust declines, the instinct is often to compensate by increasing speed, which is where the focus starts to shift towards real-time data. This is also where it becomes visible at leadership level: decisions take longer because numbers are debated, engineering time is spent maintaining workarounds, and data initiatives stall because inputs aren’t trusted.
That shift towards real-time data is understandable, but it does not resolve the underlying issue. When ownership is unclear, pushing for more immediacy tends to add pressure to a system that is already struggling with trust. If definitions are not stable and accountability is unclear, real-time data simply means you see inconsistent results sooner.
Governance is where ownership becomes visible
Governance is often described as process or documentation, but in practice it shows up in how systems behave day to day. When ownership is unclear, governance becomes inconsistent, with different teams applying different standards and decisions being revisited more often than they should. When ownership is clear, governance tends to settle and becomes a natural part of how things are done, rather than something that needs constant attention.
At its core, it comes down to a few simple questions:
- Who owns which data?
- What standards define quality?
- And what happens when those standards are not met?
When those answers are clear and accepted, systems tend to stabilise. In their absence, governance often becomes something teams try to patch in afterwards.
The limits of what a platform can solve
Modern data platforms can support a lot of good practices, from enforcing schemas and managing access to introducing quality checks, and while all of that helps, it does not replace ownership.
A platform cannot decide who is responsible for a dataset, resolve conflicting definitions between teams, or take accountability when something breaks. When these questions are not addressed at an organisational level, the platform ends up compensating, often by becoming more complex than it needs to be.
Complexity shows up in cost
There is also a cost dimension that tends to be overlooked. When platforms compensate for unclear ownership, they often do more processing, more validation, and more duplication than necessary. That shows up directly in infrastructure costs, but also in time spent maintaining logic that should not have been needed in the first place.
Simpler ownership models tend to be more efficient, not just easier to manage; they scale better and cost less over time.
What good ownership actually looks like
In organisations where things work, ownership is explicit and practical. Data is owned in the domain where it is created and understood, not in a central team.
Responsibilities are clearly defined: definition, quality, and availability. Owners have the authority to make decisions and resolve conflicts. Without authority, ownership does not work.
Interfaces between teams are predictable, reducing the need for constant coordination.
This does not make systems perfect, but it makes them stable and stability is what allows teams to move faster without constant rechecking.
Why this starts with leadership, not tooling
In practice, it is more effective to start with a simpler question: who owns which data, end-to-end?
Not who contributes to it or who uses it, but who is accountable for its quality, its definition, and its availability over time. If that answer is unclear, the architecture will reflect it.
Ownership doesn’t emerge organically. It requires leadership decisions around accountability, trade-offs, and how teams work together. If leadership avoids these decisions, ownership remains vague. If leadership is clear, ownership becomes enforceable.
Boring is the goal
The systems that hold up over time are not the most complex or the most feature-rich. They are the ones where ownership is clear, governance is consistent, and the platform supports a stable way of working.
A few years in, those systems are still understandable. Teams are not constantly firefighting, and changes do not require untangling layers of hidden assumptions. That kind of stability does not come from adding more capability. It comes from limiting responsibility, making ownership explicit, and keeping the system intentionally simple.
