The Social Contract of Data Mesh

A CDO I respect told me something candid over coffee. His organisation had been running a data mesh programme for two years. The catalog was live. The governance council met every fortnight. Ownership had been assigned across twelve domains.

"The problem," he said, "is that I convinced my leadership team to do data mesh. But I never convinced my domain teams to want it."

That distinction — convincing versus wanting — is the entire social problem of data mesh in one sentence. Think about it - why is it that organisations willingly invest millions in data platforms, but struggle to convince the people who actually produce the data to own it?

You can mandate a data product owner into existence. You cannot mandate them into caring.

Every technical challenge in data mesh has a technical solution. The social challenge does not. And it is the social challenge that determines whether a data mesh will be successful.

Part 4 argued that data mesh fails because organisations change the vocabulary without changing the power structures underneath. This article goes one level deeper. Even when organisations redesign the power structure, another question appears: why would anyone want the responsibility? What is the incentive?

Why domains never owned data historically

Historically and even now, in many incumbent organisations, data has been an operational exhaust. The domain ownership ends the moment the data is pushed down to the analytics plane. The pipelines are designed to serve one consumer - not the one from the future. The central BI teams translated business requests and build or modify data assets reacting to the requirements as they arrive. Domain teams' primary responsibility has been to optimize operations, not analytical products. They have had nothing to do with the analytics. Nobody expected Sales to publish datasets. Nobody expected Finance to maintain APIs. And for decades, that model worked well. There were relatively few analytical consumers, reports had clearly defined audiences, and the central BI team could absorb the translation between business and technology. Data mesh is not asking domain teams to do data work differently. It is asking them to do data work for the first time.

What the Social Contract Actually Is

Data mesh is asking business domains to adopt a responsibility that never existed before. It asks them to take on accountability for data they already generate — but have never been responsible for maintaining, governing, or serving to others.

That is a genuine ask. And it comes with genuine costs. Time. Engineering effort. The risk of being visible when something goes wrong.

In return, the organisation must offer something equally genuine. Not just a title. Not just a catalog entry that says "Owner: Sales Team." Something real.

This exchange — accountability in return for authority, responsibility in return for capability — is the social contract of data mesh. When organisations get it right, domain teams become genuinely invested. When they get it wrong, domain teams become resentful participants in someone else's governance programme.

The contract has three terms. All three must be honoured. If any one is missing, the contract is broken.

Authority — the domain team must have the power to make decisions about their data. What quality standards to set. Who gets access. How it is structured. If every decision requires approval from central IT, the domain team is accountable without authority.

Capability — the domain team must have the budget and the people to fulfil the accountability they are taking on. A data product owner without a data engineer is a person with a responsibility they cannot meet. That produces either poor data products or burnout. Usually both.

Incentives — the organisation must make domain data ownership visibly valued. If doing data work well is invisible in performance reviews, if the data product owner gets no credit when their product is trusted and widely used, the incentive to care disappears. People respond to what gets measured and rewarded. If data quality is not in that set, it will not be prioritised.

What a Data Product Owner Actually Does

One reason the social contract breaks down is that organisations create the role without defining it. The data product owner title appears on the org chart. Nobody is quite sure what it means day to day.

The data product owner sits at the intersection of the business domain and the data platform — and that intersection is genuinely demanding.

On one side, they need to understand the business deeply enough to define what good data looks like. What constitutes a valid customer record in their specific context. What "active" means in their domain. What quality threshold is acceptable for their consumers. This requires domain expertise — not data engineering expertise.

On the other side, they need to understand the data platform well enough to specify what they need built and to assess whether the output meets their standards. They do not need to build the pipelines themselves. But they need to be able to hold the engineers accountable for what gets built.

In the organisations that have done this well — Intuit is the clearest example — the data product owner is explicitly empowered to reject a data product that does not meet quality standards before it is published. They have veto power. That veto power is what makes the role real.

Without it, the data product owner is a reviewer with no teeth. And reviewers with no teeth produce the governance theatre we covered in Part 4.

The Leadership Commitment That Most Organisations Do Not Make

Every successful data mesh implementation I can point to — Zalando, Saxo Bank, Intuit, JPMorgan — has one thing in common that is rarely mentioned in the case studies.

Leadership sustained the commitment for eighteen to twenty-four months before meaningful results were visible. They showed the patience required for organisational change of this complexity.

That is not a small thing. In most organisations, a programme that has not shown clear ROI within twelve months is at serious risk of being cancelled, deprioritised, or quietly absorbed into something else. Data mesh requires a leadership team that is willing to defend a transformation that looks painful and produces nothing obvious and sizable even after the project has run for long.

At Intuit, the CDO made domain data ownership an explicit part of how domain teams were evaluated. Not just encouraged — evaluated. Performance reviews included data product quality metrics. This changed the incentive structure in a way that no governance document could.

At Zalando, their opt-in publishing model meant domain teams had to actively choose to make their data available to others. That choice came with accountability — if you publish, you maintain. Leadership backed this model through the difficult early period when domain teams resisted, when the first published products had quality problems, when the catalog was thin and the network effect had not yet arrived.

The common thread is not a specific technology decision. It is leadership treating the cultural transformation as the primary deliverable and exhibiting the patience while the practice matured to produce the first results.

The Accountability Avoidance Problem

In most large organisations — and this is particularly pronounced in hierarchical structures across government entities and large incumbents — there is a systematic incentive to avoid data accountability.

Taking ownership makes failure visible. If you take ownership of a data domain and the data turns out to be wrong, you are visible and answerable. If ownership stays vague — with the central IT team, with nobody in particular — the accountability is too spread out to attach to any individual.

This is not laziness or bad faith. It is rational behaviour within a system that punishes visible failure more than it rewards visible success.

I have seen this play out in government entities across the Gulf, and in large corporate environments across multiple sectors. The pattern is the same. A data governance initiative launches. Ownership is offered to domain teams. The domain teams smile, nod, and then — with remarkable consistency — find reasons why their team is not quite ready, why the timing is not ideal, why it would be better to wait until the central team has done a bit more preparation first.

They are not wrong to be cautious. They are not resisting data mesh. They are responding rationally to the incentive structure around them.

The social contract of data mesh requires leaders to change that incentive structure explicitly — to make data accountability visible, valued, and rewarded. Not just for the domains that do it well, but consequential for the domains that do not engage.

What Change Management for Data Mesh Actually Looks Like

Change management for data mesh is not training sessions and communication plans. It is restructuring who benefits from getting data right.

Three things that work — drawn from the implementations that have actually succeeded:

Make the first data product a win for the domain team, not for the programme. The first domain to publish a real data product should get something tangible from it — faster access to other teams' data, a reduction in the inbound requests they receive, visibility with leadership. If the first mover bears all the cost and gets nothing back, every domain that watches them will decide to wait.

Build the self-serve infrastructure before asking anyone to self-serve. Domain teams are given ownership responsibility before the platform makes ownership tractable. They have to file tickets for things that should be one-click. They hit friction at every step. They conclude that data ownership is more burden than benefit — and they are right, because the infrastructure that would make it easy has not been built yet.

Make data product quality visible to everyone, including consumers. Saxo Bank implemented consumer ratings on data products — like rating an app. If your data product has a low rating, your domain leadership sees it. That single mechanism — consumer feedback made visible to producers — changed domain team behaviour more than any governance policy. It created a social accountability that organisational structures alone cannot produce.

The common thread across all three: change the economics of ownership before asking anyone to own anything.

Conclusion

Data Mesh is often presented as a distributed architecture. I think it is first a distributed accountability model. The platform merely makes that accountability possible. Whether people choose to accept it depends on whether the organisation honours its side of the social contract. The question that reveals whether you are ready: if your data product has a quality issue next month, who in your team will fix it — and will they have time to do so?

Coming next — Part 6: Is Data Mesh Right for Your Organisation? A practitioner's honest assessment — when mesh is the answer and when it is an expensive distraction.