A project needs product data from another part of the organization. The data exists, but the definitions don't match. Something as straightforward as a product taxonomy turns out not to be: in the Netherlands, feta sits in the cheese category; in Greece, it's a category of its own. So the project team fixes it: just enough, just for this use case. It's the cheapest option and has the least impact on the timeline.

I saw this pattern early in my career, and I've seen it play out dozens of times since. Each fix makes perfect sense in isolation. But from an organizational perspective, it's penny-wise, pound-foolish. The same data gets defined differently across a dozen systems, quality gets fixed and re-fixed ad hoc, and eventually a stakeholder asks the question I've heard more times than I can count: why don't the numbers add up?

The answer is always the same. The data was made fit-for-purpose, exclusively for one purpose. When someone tries to use it across domains, it doesn't connect.

A working paper I read recently put a formal frame on this pattern. Gaston Besanson models it as a public goods game: each domain invests in making its data reusable only up to the point where the benefit comes back to itself. The benefit it creates for everyone else doesn't just go unnoticed: the incentive structure actively works against it. A domain leader who invested capacity in cross-domain reusability would be going against their KPIs, and their own leadership would rightly push back. Given how organizations measure performance, building only for your own use case isn't a shortcoming. It's the rational thing to do. So the cross-domain layer, the reusable middle, doesn't get built. Besanson calls this the data mesh trap.

The paper shows that the resulting technical debt scales quadratically with the number of domains. Five domains create twenty potential integration pairs. Twenty create three hundred and eighty. In a multi-brand organization, where each brand operates its own domains, the numbers grow further still.

This pattern is what drove me from working with data to working on data governance and management. I have a natural affinity for connecting data, technology, and policy. But the motivation was never compliance for its own sake. It was seeing that one-off fixes could never unlock value at the scale the organization needed. That conviction led me to write the first version of the governance and policy framework at Ahold Delhaize. Today, I'm working on the same challenge from a different angle: building interoperable data across organizations that were each designed for local autonomy, not for joint value.

But even the structural fix isn't as simple as putting someone in charge. Bringing in a SVP of Data and AI, or an equivalent role, can be counterproductive if their success is measured on delivering output from data rather than building the foundation the whole organization benefits from. Their incentives push toward the same project-by-project pattern, just at a higher altitude. A new title doesn't change the externality. If the reward is delivery, the cross-domain layer still isn't anyone's problem.

This is also why the CDO role so often disappoints. CDOs are hired to solve the cross-domain problem, but they're handed technical tools: platforms, architectures, systems. The real bottleneck isn't technical. It's the misaligned incentive structure and the leadership decisions required to change it. The more complex the organization, the more money there is to pour into technology that temporarily masks these dynamics rather than resolving them.

The reusable middle is a leadership decision, not an emergent property. And choosing not to make that decision doesn't avoid the cost. It just moves it: to the projects that take months instead of weeks, to the metrics that never quite align, to the AI initiatives that inherit every inconsistency the organization chose not to resolve.

The numbers won't add up until someone owns the middle. And with AI agents inheriting every ad hoc fix at machine speed, the quick fix isn't temporary anymore. It's what your AI runs on.