Technology is the easy half
Session 4 chose the platform. This one decides who stands on it. Almost every stalled data programme fails on the organisational half, not the technical half - the pipeline works, but nobody is clearly accountable when it breaks, and two teams each assume the other owns the number. DataOps borrows its org thinking from modern software teams: clear ownership, a shared paved road, and explicit agreements between the people who produce data and the people who depend on it.
Central team vs data mesh 10 min live
There are two honest ways to organise data ownership, and both are right for different organisations. A central team is one group serving everyone. A data mesh gives each business domain ownership of its own data as a product. The choice is not fashion - it is a bet about where your bottleneck will appear as you scale.
LiveWhen each model fits4 min▶
Neither model is the enlightened one. They solve different problems, and choosing the wrong one for your size is how good data teams end up either overwhelmed or ungoverned. A concept to hold: you do not choose between quality and scale - you choose where to put the bottleneck.
- A central team fits smaller or earlier organisations. One group owning all data gives you consistent standards, a single source of truth, and easy governance - because everything runs through one door. Its failure mode is that same door: as demand grows, every domain queues behind the central team, and the team becomes the bottleneck that slows the whole company.
- A data mesh fits larger, multi-domain organisations. Each domain - sales, finance, operations - owns its data as a product, including its quality. This scales because no single team is the chokepoint, and the people closest to the data own it. Its failure mode is fragmentation: without strong shared governance and a common platform, a mesh becomes a set of disconnected silos that cannot be trusted across domains.
Team topologies - who does what 8 min live
Whichever ownership model you pick, a mature data organisation needs three distinct kinds of team doing three distinct jobs. Borrowing the language of Team Topologies - a well-known model for organising modern technical teams - keeps these roles from blurring into one overloaded group that does everything and owns nothing clearly.
| Team | What it owns | What "good" looks like |
|---|---|---|
| Platform team builds the paved road | The shared infrastructure - orchestration, quality tooling, access control - that every other team builds on | Domains ship faster because the hard parts are already solved and standardised for them |
| Data product teams own the domains | The actual data products for their domain - sales, finance, operations - including their quality and reliability | Each team is clearly accountable for its data and treats its consumers like customers |
| Enabling / governance team sets the guardrails | Standards, policies, and coaching - the rules of the road and the help to follow them | Governance is enabling and mostly invisible, not a committee that slows everyone down |
LiveThe trap of one team doing all three3 min▶
In most organisations, one small data team is quietly doing all three jobs at once - building the platform, owning every domain's data, and setting the standards - and doing none of them well because the roles pull in different directions.
- The platform team builds leverage, not features. Its job is the paved road that makes every other team faster. When platform work is squeezed in between firefighting requests, the road never gets paved and everyone stays slow.
- Data product teams create value, and must be accountable for it. When "the data team" owns every domain's data, no business unit feels responsible for its own quality - accountability evaporates into a shared inbox.
- The enabling team protects trust by setting light, clear guardrails and coaching teams to meet them. Done well it is nearly invisible. Done as a gatekeeping committee, it becomes the bottleneck it was meant to prevent.
Separating these three - even loosely, even in a small org where one person wears two hats - is what lets a data organisation grow without collapsing into a single overloaded team.
Data contracts as social technology 6 min live
Once domains own their own data, they need a way to promise each other that a dataset will not change without warning. That promise is a data contract. It looks technical - a schema, a set of expectations - but its real purpose is social: it turns a silent, breakable assumption between two teams into an explicit, negotiated agreement.
Self-studyWhy contracts are human, not technical3 min read▶
A data contract records four things a producer and consumer agree on: the schema (what columns and types exist), the quality expectations (how fresh, how complete, which values are valid), the ownership (who is accountable and who to call), and the SLA (how reliable and timely the data will be). Written down and checked automatically, a contract does two jobs:
- It prevents silent breakage. Today, a producer can rename a column on Tuesday and a consumer's dashboard breaks on Wednesday, with nobody warned. A contract makes that change a visible, agreed event instead of a silent surprise - the breakage is caught before it reaches a leader's screen.
- It makes ownership explicit. A contract names who is responsible for the data and who depends on it. When something goes wrong, there is no argument about whose problem it is - the agreement already said.
Ownership map ★ 12 min · map it together
The fastest way to find your organisational risk is to try to name the owner of each critical dataset out loud. Where the room hesitates, or two people answer differently, is where accountability is unclear - and unclear accountability is where data quietly rots.
List your five most business-critical datasets - the numbers a leader actually decides on. Revenue, active customers, pipeline, inventory, whatever moves your decisions.
For each one, name the single accountable owner - a person or a team, not "the data team" in general. If you cannot name one clearly, mark it red; that is an ownership gap.
For each dataset, name its main consumers - who breaks if it breaks? If the producer does not know who depends on their data, mark it: that is a silent-breakage risk waiting to happen.
Circle every dataset where ownership was unclear or contested. These are your first candidates for an explicit owner and a data contract.
Ask the harder question: are we a central team that has become a bottleneck, or a set of domains with no shared governance? The pattern in your red marks usually answers it.
The dataset three teams thought someone else owned. A data leader ran this map and found the company's headline "active customers" metric had no clear owner - marketing assumed data engineering owned it, data engineering assumed the product team did, and the product team assumed marketing did. The number had been subtly wrong for months and steered a campaign budget. Naming the owner took ten minutes. Finding out nobody owned it was the whole point.
★ Questions to ask your data team
- "Who is the single accountable owner of our most important dataset?" If the answer is a vague "the data team" or a debate, ownership is unclear and quality has no home.
- "Are we a central team, a data mesh, or an accident?" Many orgs have drifted into a shape nobody chose. Naming it is the first step to fixing the bottleneck or the fragmentation.
- "Do we have a platform team building the paved road, or is everyone reinventing the same plumbing?" Without a platform team, leverage never accumulates.
- "When a producer changes a dataset, how do the consumers find out - before or after it breaks?" "After" means you have no data contracts and silent breakage is routine.
- "Where does our data have producers and consumers who have never actually agreed on what is promised?" Those unspoken assumptions are your next contracts.
What this session covers
This session draws on the data-mesh literature, the Team Topologies model, and the growing practice around data contracts. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · The main failure mode of a single central data team is...
A central team gives clear standards and one source of truth, but its single door becomes a chokepoint at scale. That bottleneck is the signal it may be time to evolve toward a mesh.
2 · A data mesh only works well when...
Domain ownership scales, but without strong shared governance a mesh fragments into untrusted silos. Mesh is a graduation you earn once your governance foundation is solid.
3 · A data contract is best understood as...
The YAML is only the record. The real value is the explicit agreement between two teams that prevents silent breakage and makes ownership clear. Fund the conversation, not just the file.