Second in a three-part series on the scaling tensions inside modern data platforms. Part 1, “Scale the Team or Scale the System?”, is here.

In Part 1 I framed the question every data org eventually collides with: do you scale the team or scale the system? This post answers the half that sounds organizational but is really architectural — ownership.

The re-badge trap

The most common failure I watched play out isn’t technical. A company decides to decentralize, draws a box around each business area, calls it a “domain,” and declares victory. Nothing else changes. The same team, the same backlog, the same lack of authority — now with a new name on the org chart.

This is ownership as lip service, and the industry has a name for the outcome now: teams get re-badged as domains without a genuine mandate, without business-aligned incentives, and without the authority to actually decide anything. A domain that can’t say no to a bad request doesn’t own its data. It just holds it.

Real ownership means three things move together:

  • Mandate — the domain decides what its data means and how it’s exposed.
  • Incentive — the domain is measured on whether other teams can actually use its data, not just on shipping its own features.
  • Authority — the domain can reject work, set an SLA, and be held to it.

Take away any one of the three and you don’t have a domain. You have a cost center with a fancier label.

Data as a product, minus the buzzword

“Data as a product” gets eye-rolls because it’s usually said and never done. The test is boring and concrete: does the data have an owner you can name, a documented contract, a quality SLA, and a consumer who’d complain if it broke? If a dataset has consumers but no one who’d get paged when it goes wrong, it isn’t a product. It’s a leak that happens to be useful.

The shift that made this real for us wasn’t tooling. It was making the domain team feel the consumer’s pain directly — routing the complaints to the people who could fix them, instead of to a central team three steps removed from the cause. The day a domain team starts triaging its own consumer complaints is the day it starts behaving like a product team.

Why you can’t just declare ownership

Here’s the part that surprised me. You cannot assign ownership faster than your platform can support it.

The recurring pattern across the field is brutal and predictable: decentralize ownership without investing in the platform, and each domain quietly rebuilds the same plumbing — its own ingestion, its own catalog, its own quality checks. Within a year you have the same problem solved eight different ways by eight teams who don’t talk to each other. The central bottleneck you dissolved reappears as eight smaller ones, plus the integration tax of making them agree.

So ownership isn’t something you declare. It’s something the system has to afford. Give a domain a mandate to own its data before it has a self-serve way to publish, secure, and monitor that data, and you’ve handed it a responsibility with no tools — which is how you get either shadow pipelines or quiet non-compliance.

The rule I’d keep

If I compressed this into one line for the next team doing it: decentralize ownership only as fast as the platform can carry it. Ownership is a promise the domain makes to its consumers. The platform is what lets the domain keep that promise. Ship them out of order and the whole thing re-centralizes within eighteen months — or just stalls.

Part 3 takes on the other half: the self-serve platform itself, and how you govern a system where no single team is in charge.

Part of a series drawn from hands-on experience building and scaling data platforms. Details are anonymized; no client or employer is identified.