A company of a few hundred people asks whether to adopt data mesh; how do you decide whether a central data team is still the better model?
answer
- is the central team actually the bottleneck
- how many real domains
- can domains staff data ownership
- is there a platform to self-serve
- adopt in steps, measure lead time
basics
~20 sAdopt it only if the central team is a real bottleneck, the business has several distinct domains, domains can staff data ownership, and a self-serve platform exists or can be funded. Otherwise improve the central model, adding domain ownership step by step.
solid answer
~50 sData mesh solves **organisational scale**: many domains, many sources and consumers, and a central team that cannot keep up or lacks domain knowledge. I would test for that before recommending it. **Is the central team the bottleneck** — measured by lead time for new data, backlog and quality issues rooted in missing domain knowledge? **How many distinct domains** generate and consume data? **Can domains staff ownership** — people with data skills and time — or will ownership exist only on paper? **Is there a platform** that makes building a data product cheap, or the budget to build one? For a few hundred people with a handful of domains, the answer is often a **strong central team** with domain-aligned analysts, product thinking for key datasets and platform-enforced standards — borrowing mesh ideas without the full reorganisation. I would revisit when the measured bottleneck appears, and pilot with one or two mature domains rather than switching wholesale.
go deeper
Know that data mesh targets large organisations where a central data team becomes a bottleneck.
Explain which conditions, such as many domains and a self-serve platform, make data mesh worthwhile.
Assess an organisation's readiness with evidence such as lead time and domain skills, and propose a pilot.
Make and defend the recommendation, including what to borrow from data mesh without reorganising and when to revisit the decision.
## What data mesh is for Data mesh's principles respond to a specific failure: a **central data team** that becomes a bottleneck as the number of sources, consumers and domains grows, and that lacks the domain knowledge to model data well. Where that failure is absent, the reorganisation, platform investment and coordination cost of a mesh buy little. The decision is therefore an assessment, not a trend to follow. ## Questions to answer first | Question | Evidence | Leans towards | |---|---|---| | Is the central team the bottleneck? | lead time for new datasets, backlog age, quality issues caused by missing domain knowledge | mesh if yes | | How many distinct domains produce and use data? | business units with their own systems and analytical needs | mesh with many, central with few | | Can domains staff data ownership? | engineers or analysts with data skills and time in each domain | central if not | | Is there, or can there be, a self-serve platform? | tooling for pipelines, storage, access, catalog; platform budget | central if not | | How mature is governance? | classification, access policy, shared identifiers already in place | mesh needs these to be automatable | ## Typical conclusions - **Small organisation, few domains, capable central team**: keep the central model; add domain-aligned analysts, treat key datasets as products with owners, and enforce standards in the platform. - **Growing organisation, clear bottleneck, some mature domains**: pilot mesh with one or two domains that already have data skills, building platform capabilities as the pilot needs them. - **Large organisation, many domains, persistent bottleneck**: a mesh-style operating model is plausible, but only with a funded platform team and a governance federation. ## Borrowing without reorganising Several ideas pay off at any size: 1. **Data as a product** for the most-used datasets: named owner, stated objectives, documentation. 2. **Standards enforced by the platform** rather than by review. 3. **Shared identifiers** for core entities decided once. 4. **Quality accountability close to the source**, for example by involving producing teams in contracts. ## Risks of adopting too early - Ownership on paper only, with no people or time behind it. - Each domain building its own infrastructure, multiplying cost. - Fragmented, non-interoperable data because governance was not ready. ## Measuring the decision Track **lead time** from request to usable data, **quality incidents** traced to missing domain knowledge, and **consumer satisfaction**. If they worsen under the central model as the company grows, the case for decentralising strengthens; if a pilot does not improve them, stop and reassess. ## Why interviewers ask it It is a principal-level judgement with no single right answer. Interviewers look for a candidate who ties the choice to **evidence of the problem mesh solves**, considers staffing and platform readiness, and proposes an **incremental, measured** path instead of an all-or-nothing reorganisation.
- What would you pilot first if the evidence favours data mesh?One or two domains that already have data skills and a clear set of consumers, building their first data products on minimal platform capabilities, with lead time and consumer satisfaction measured before and after.
- Which data mesh idea would you adopt even in a small company?Treating the few most important datasets as products with named owners and stated objectives, because it improves trust and accountability without reorganising teams or building a large platform.
saying these in an interview costs you the question
- Recommending data mesh because it is fashionable rather than because of a measured bottleneck
- Declaring domain ownership without people and time in the domains
- Decentralising before shared identifiers and platform standards exist
- Treating the choice as all-or-nothing