A CDO proposes moving to a data mesh because the central data team is a bottleneck with a nine-month backlog. How do you assess the proposal?
Show the full answer Hide the answer
Agree with the diagnosis, examine the prescription
The bottleneck is real and it is structural rather than a matter of capacity. A central team receives data from dozens of source systems whose semantics it does not know, is asked to model it correctly, and is blamed when a source changes without notice. Adding people does not fix a knowledge asymmetry.
So domain ownership addresses the right problem. Whether it will work here depends on three conditions, and the proposal should be assessed against them rather than against the concept.
Condition 1: capability in the domains
Does each domain have, or can it acquire, the data engineering skill to publish a product with a schema, stated semantics, a freshness commitment and an owner?
If not, ownership is a transfer of blame rather than of work, and the outcome is worse than the status quo: the same backlog, distributed, with no one team able to address it.
Condition 2: a self-serve platform
This is the condition most often skipped and the one that determines the outcome. Without a platform that makes publishing genuinely easy — storage, compute, catalogue, lineage, access control, quality monitoring — every domain builds its own ingestion, and the estate fragments.
Ask what platform investment is in the proposal. If the answer is that the central team becomes the platform team, that is coherent and it means the migration is sequenced platform-first, which is a materially different plan from the one usually presented.
Condition 3: funding
Publishing data for other domains benefits someone else's roadmap. Teams do not do that on goodwill for long. Either the platform absorbs most of the cost, or domain data work is funded explicitly.
What to recommend
Sequence it: platform first, then two willing domains as a pilot, then expand from evidence. Federated governance from the start, with a deliberately short list of global decisions — identity keys, classification, retention floors — because a governance function that decides everything is the central team again with more meetings.
And be specific about the failure to avoid: renaming existing teams as domains, declaring ownership, providing neither platform nor funding. That decentralises the problem and removes the one team that was solving any of it.
The honest alternative worth considering
For an estate with a small number of sources, a well-funded central team with data contracts imposed on producers achieves much of the same benefit at a fraction of the organisational cost. Mesh earns its complexity at scale, and the scale threshold is higher than most proposals assume.