Designing the Data Organization and Roles

The judgement call is *what goes in the hub versus the spoke*, and this is where CDOs get it wrong. The correct sorting rule is not "important things at the center." It's this:

> Centralize what benefits from scale, consistency, or scarcity. Federate what benefits from context and speed.

Run every function through that filter. Data platform engineering benefits from scale → hub. Business analyticsBusiness analyticsTechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → benefits from context → spoke. Data governanceData governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → policy benefits from consistency → hub, but governance *execution* benefits from context → spoke. That single distinction—policy central, execution local—is the most important structural decision you'll make, and we'll return to it.

Consider how Netflix and JPMorgan diverge here for defensible reasons. Netflix pushes enormous autonomy to embedded analysts because its strategic bottleneck is experimentation velocity. JPMorgan centralizes far more because its bottleneck is regulatory defensibility and the cost of a data error is measured in consent orders. Neither is "best practice." Each structure is a bet on where the friction that matters most lives.

The Governance–Delivery Split

The single most common structural failure I see is collapsing governance and delivery into one team under one leader. It feels efficient. It is poison.

Delivery teams are measured on shipping: pipelines live, dashboards launched, models in production. Governance is measured on control: quality, lineage, access, compliance. When the same leader owns both, delivery *always* wins the daily trade-off, because delivery has a deadline and governance has a principle. Quality erodes silently until an incident forces a reckoning.

The fix is to separate the two reporting lines while forcing them to share a workflow. Governance sets policy and owns the definition of "done well." Delivery owns "done fast." They meet at the point of production—the gate through which data products ship.

Here's the operating pattern that makes this work without creating a bureaucratic war:

• Governance defines the controls as code, not as a Word document. Data contracts, quality thresholds, access policies, and classification rules live in the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →, not in a review meeting.
• Delivery teams are free to move fast inside those guardrails and only escalate exceptions.
• The CDO owns the arbitration when the two collide—which they will.

A data contract is the concrete artifact where this split becomes real. It is the interface between a data producer and its consumers, and it lets governance be enforced automatically rather than through meetings:

Notice what this artifact does organizationally. The owner field forces domain accountability—a person, not a queue. The classification field lets central governance enforce PII handling without inspecting every pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →. The breaking_change_policy prevents a delivery team from silently breaking downstream consumers. The contract encodes your org design into the workflow, which is the only place org design survives contact with reality.

This is the mechanism behind data meshdata meshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.View full definition →, but you don't need the buzzword. You need the principle: domains own their data products end to end, the platform team gives them paved roads, and governance is federated *computationally*—enforced by the platform, not by a committee.

Roles: Who Actually Owns What

Titles proliferate and mean nothing across companies. Design your org around *accountabilities*, then attach titles. Here are the roles that matter and the boundary decisions that make them functional.

The Data Product Manager is the role most CDOs under-invest in and most regret skipping. As data-as-a-productdata-as-a-productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → moves from slide to reality, someone has to own a data asset the way a PM owns software: roadmap, consumers, SLAs, and lifecycle. Without this role, "products" are just tables with better marketing. The DPM sits in the spoke, close to the domain, and is the human counterpart to the data contract above.

The Data Platform / Data Engineering lead owns the paved road—the ingestion, transformation, storage, and self-serve tooling that spokes build on. This role belongs in the hub, unambiguously. The failure mode is letting each domain build its own platform; you end up funding five half-platforms and no leverage.

The Analytics Engineer / Domain Analyst lives in the spoke and turns raw domain data into decision-ready models. This is your context layer. Centralizing it starves the business of speed.

The Data Governance lead owns policy, standards, the data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition →, and the definition of quality. Hub. But—critically—they own *policy and tooling*, not day-to-day enforcement in every domain. Their job is to make the right thing the easy thing, embedded in the platform.

Data Stewards are the federated execution of governance. Here is the decision that trips up CDOs: *stewards should not report to you.* They should be respected domain experts who own dataown dataData collected directly from your own customers and prospects through your own channels: your most reliable and privacy-compliant source.View full definition → quality and definitions inside their business unit, with a dotted line to central governance. A steward who reports to central governance is an outsider policing the domain; a steward who belongs to the domain is an insider improving it. Same activity, opposite outcome.

MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → these roles against the hub/spoke split explicitly:

| Role | Home | Accountable for |

|------|------|-----------------|

| Data Platform Eng | Hub | Paved roads, leverage, tooling |

| Governance Lead | Hub | Policy, catalog, standards-as-code |

| Data ProductData ProductA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → Manager | Spoke | Product roadmap, SLAs, consumers |

| Analytics Engineer | Spoke | Domain models, decision supportdecision supportTechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → |

| Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.View full definition → | Spoke (dotted to hub) | Quality & definitions in-domain |

The reporting lines in that table *are* your governance-delivery split made concrete. If you can't fill in the "Home" column for a role, you don't yet understand what that role is for.

One more judgement call: the span between your platform team and your embedded teams determines your scaling ceiling. If every spoke needs three central engineers to ship anything, your platform isn't self-serve and you'll hit a wall at a dozen domains. The test is ruthless: *can a domain team ship a new data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → without filing a ticket to the hub?* If not, you have a service organization wearing a product organization's clothes.

Sequencing, Reporting Lines, and the Reorg You Shouldn't Do Yet

Most CDOs try to draw the perfect end-state org chart in month one and roll it out in a big-bang reorg. This fails twice: the design is wrong because you don't yet understand where the real friction lives, and the political capital burns before you've shown value.

Sequence the structure to your strategic phase. In a control-establishment phase, lean centralized—pull scarce talent together, establish standards, win the trust battle. As trust and platform maturity grow, deliberately *federate outward*, pushing product ownership and stewardship into domains. The org chart should be a movie, not a photograph. Announce this trajectory openly: "We are centralizing now to build the platform, and we will push ownership to you within eighteen months." That converts a threatening reorg into a promise.

Where should you, the CDO, report? This is a strategy tell, not a vanity question. Report to the CEO or COO when data is a growth and monetization lever—you need P&L adjacency and peer status with business unit heads. Report to the CIO when the priority is platform and infrastructure consolidation. Report to the CFO or CROCROConversion Rate Optimization (CRO) is the systematic practice of increasing the percentage of users who complete a desired action, using data, testing, and user research.View full definition → when the mandate is defensive—risk, compliance, cost. The wrong line is fatal: a CDO with a monetization mandate reporting to a risk-obsessed CROCROConversion Rate Optimization (CRO) is the systematic practice of increasing the percentage of users who complete a desired action, using data, testing, and user research.View full definition → will be structurally starved of the mandate to take offensive bets.

The dotted-line problem is the crux of federated design, and dotted lines mostly don't work on their own. A dotted line without a lever is a suggestion. Give it teeth through three mechanisms:

1. Shared objectives. The embedded analytics lead's bonus is partly set by you, partly by the BU head. Split incentive, split loyalty—deliberately.

2. Control of the career path. If you own promotions and leveling for the data profession across the company, your dotted lines have gravity even when the solid line sits in the business.

3. Control of the platform. If the domains depend on the paved roads your hub builds, your influence is structural, not political.

That third point is the quiet secret of powerful CDOs. The ones with real authority rarely have everyone reporting to them. They own the platform, the standards, and the profession, so the entire organization runs on rails they laid—regardless of the reporting boxes.

A word on Conway's Law, because it governs everything above: your systems will mirror your communication structure. If you split ingestion and analytics into two teams that don't talk, you will build a pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → with a seam exactly at that boundary, and data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → will die in the gap. Design your team boundaries where you *want* the system interfaces to be, then let Conway's Law work for you instead of against you.

Key Takeaways

• Sort every function through one rule: centralize what benefits from scale, consistency, or scarcity; federate what benefits from context and speed. Hub-and-spoke is the answer for most mature orgs, but only if you make that sort deliberately.
• Separate governance and delivery into different reporting lines, then reunite them at the point of production through data contracts that encode controls as code. Never let one leader own both—delivery always wins the daily trade-off.
• Stewards belong to the domain, not to central governance. Policy is central; execution is local. An outsider policing a domain fails; an insider improving it succeeds.
• Build authority through the platform, the standards, and the profession—not the reporting boxes. The most powerful CDOs own the rails everyone runs on, which makes dotted lines behave like solid ones.
• Treat the org chart as a movie, not a photo. Sequence structure to your strategic phase—centralize to establish control, then federate to scale—and announce the trajectory so a reorg reads as a promise, not a threat.