Splitting a central platform into domain ownership
One data team of four supports twelve product teams and is a permanent bottleneck. Leadership approves a move to domain ownership: each product team will own its own data products. The reorganisation is announced with a date.
What you would do first
Answer before revealing anything. The value of the exercise is entirely in committing to a diagnosis you can be wrong about.
- 1Establish what the central team actually does today, and split it into what must be central — standards, catalog, lineage, deployment mechanics, cost attribution — and what should be domain-owned, which is models and their meaning.
- 2Assess capability honestly: how many of the twelve teams can own a data product today, and what would each need to be able to.
- 3Define what a data product must provide before another team may depend on it: declared grain, an owning team with a rota, a freshness target, assertions on the key, documented known gaps.
- 4Decide what is enforced by a gate rather than by a document, because a standard that can be skipped under deadline pressure will be.
What is actually going on
The trap
The fix that looks right. Read it even if you got the answer — especially then.
Reassign the datasets on the org chart and dissolve the central team into the domains. Ownership is nominally distributed on day one, the bottleneck genuinely disappears, and within two quarters there are twelve ingestion patterns, no catalog, no lineage across domains, and no group with the standing to say so.