Data mesh usually arrives as an answer to a real problem.
The central data team is a bottleneck. Dashboard requests queue behind one another. Domain teams understand their own data best, but wait weeks for someone else to model it.
Decentralizing ownership sounds like the obvious solution.
So the organization announces a data mesh. Domains become responsible for their own data products. The central data team becomes a platform team.
Twelve months later, there are nine domain data teams, no shared discovery layer, four definitions of “active customer,” and an executive asking why two reports show different revenue numbers.
The bottleneck is gone.
So is the coherence.
Nobody necessarily made a bad decision. The organization decentralized ownership before building the capabilities that make decentralized ownership work.
Domain ownership without self-service infrastructure, data products, and federated governance is not a data mesh. It is decentralization with better branding.
Why a Premature Data Mesh Costs More Than the Bottleneck
The central data team may have been slow, but it was also quietly performing four jobs:
Enforcing consistent metric definitions
Helping people discover available datasets
Acting as a quality gate
Controlling access to sensitive data
When ownership is decentralized without replacing those functions, they do not automatically transfer to the domains.
They stop happening.
The cost appears as reconciliation work. Finance and product report different revenue numbers, and a senior analyst spends three days tracing the discrepancy.
That work rarely appears on a roadmap. It still consumes real capacity.
The second cost is duplicated infrastructure. Each domain builds its own pipelines, cataloging process, quality checks, and access workflow. Platform spending increases without a proportional increase in what the business can answer.
The third cost is loss of trust.
Once consumers cannot tell which dataset is authoritative, they create private copies. Those copies develop their own definitions, owners, and freshness characteristics.
You have not created a mesh.
You have created multiple competing versions of reality.
Why Capable Teams Decentralize Too Early
Data mesh is often adopted as an organizational fix for a technical constraint.
The pressure is immediate. The central team is overloaded, and business stakeholders want faster delivery.
Reorganizing is something leadership can do this quarter.
Building a self-service data platform is a multi-quarter engineering investment. For much of that period, the work produces infrastructure rather than visible business features.
When given a choice between movement now and results later, organizations usually choose movement.
That is why the sequencing fails.
Data mesh has four commonly cited principles:
Domain ownership
Data as a product
Self-serve data infrastructure
Federated computational governance
The first principle is easy to announce. The other three are harder to show in an org chart, so they become aspirations in a strategy document.
Domain ownership without the other three produces local autonomy without shared standards, discoverability, or reliable access.
That is not a mesh. It is a collection of silos.
The Seven-Signal Data Mesh Readiness Audit
Answer each question honestly.
Each “no” identifies a capability you need to build before expanding domain ownership.
1. Can a domain team publish a new data product without filing a ticket with the central team?
If every new dataset requires a platform engineer to create pipelines, configure storage, register metadata, or grant access, you have not removed the bottleneck.
You have renamed it.
A real mesh requires a paved path that lets domain teams publish within defined standards without needing custom platform intervention every time.
2. Is there one place where anyone can discover available data products?
A consumer should be able to find:
What data products exist
Who owns them
What they contain
How fresh they are
What quality guarantees exist
How to request access
Without a shared discovery layer, decentralized ownership becomes decentralized invisibility.
People cannot use data they cannot find.
3. Are your top ten business metrics defined and owned?
Do you have written definitions for metrics such as:
Active customer
Gross revenue
Net revenue
Churn
Conversion rate
Qualified lead
More importantly, does each definition have a named owner?
Federated governance does not mean every domain defines everything independently. It means accountable owners apply shared standards locally.
Without shared definitions, you do not have federation.
You have local interpretation.
4. Can one domain grant another domain access without involving a platform engineer?
Access friction creates shadow copies.
If a product team needs customer data and must wait two weeks for a platform engineer to process the request, someone will eventually copy the data into a place they control.
That may solve the immediate problem.
It also creates another dataset with another permission model, another freshness risk, and another definition of truth.
Self-service access is not just a convenience feature. It is a control against uncontrolled duplication.
5. Does every existing dataset have a named owner today?
Do not assume a reorganization will fix unclear ownership.
If ownership is ambiguous now, decentralization does not assign accountability. It distributes the ambiguity across more teams.
Before assigning domain responsibility for new data products, identify who owns the datasets already in production.
If nobody can answer, start there.
6. Do you have data quality contracts?
A data quality contract should make expectations explicit between producers and consumers.
It may cover:
Schema
Freshness
Completeness
Valid value ranges
Availability
Change notification
Without a contract mechanism, an upstream schema change becomes a downstream incident.
Domain autonomy is only safe when consumers know what producers have promised to maintain.
7. Does anyone treat data as a product today?
A data product has more than a table and a pipeline.
It has:
A defined consumer
A clear use case
An accountable owner
A quality expectation
A freshness expectation
A way for consumers to provide feedback
If nobody in the organization treats data this way today, a reorganization will not create product thinking by itself.
You will simply assign ownership of poorly defined datasets to new teams.
Score Your Organization
Use the following interpretation:
6 to 7 yes answers: You may be ready for a controlled data mesh rollout.
4 to 5 yes answers: Build the missing platform capabilities before expanding domain ownership.
0 to 3 yes answers: Do not begin with a data mesh reorganization. Your immediate priority is platform readiness.
The score is not a maturity badge.
It is a sequencing decision.
What Correct Sequencing Buys You
Organizations that build the platform layer first can decentralize once and keep the model stable.
Organizations that decentralize first often reverse the decision eighteen months later, after reconciliation costs, duplicated tooling, and loss of trust become impossible to ignore.
The platform investment pays back before the mesh arrives.
Self-service pipeline tooling reduces central team intake.
A discovery catalog reduces duplicate dataset creation.
Standardized access workflows reduce copying.
Data quality contracts reduce downstream surprises.
These capabilities are useful under a centralized model and necessary under a distributed one.
That is the key sequencing insight:
You do not need to wait for a data mesh to build a platform that supports one.
Fix the bottleneck with platform capability first. Move ownership when the capability exists to support it.
A reorganization is not an architecture.
If the platform underneath cannot support autonomy, the org chart change only relocates the problem to a place where it is harder to see.
Before you announce a data mesh, score your organization against these seven signals.
If you have fewer than five yes answers, do not start with decentralization.
Start by building the missing platform capabilities.
That is how you create a data mesh instead of a collection of silos with better branding.
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.