Data Team Structure: Why Most Fail Before Sprint One

Why Most Data Team Structures Fail Before the First Sprint

Last summer, a VP of Engineering asked David Ohnstad to audit why their data team of fourteen people had shipped two products in eighteen months. The team had three data engineers, four analysts, two ML engineers, three data scientists, and two product managers. On paper, the ratio looked fine. In practice, nobody could answer a basic question: who owns data quality for the customer churn model?

The problem was not headcount. It was not talent. It was topology. The team had been assembled using a standard software engineering org chart—squads aligned to product surfaces—without accounting for the unique decision rights, feedback loops, and ownership boundaries that data products require. According to Gartner’s 2024 Data & Analytics Leadership Survey, 72% of enterprises restructure their data teams at least once within the first two years of formation, and the primary driver is unclear accountability for data outputs.

Most companies approach how to organize a data product team the same way they structure feature engineering teams. That is the mistake. Data products are not features. They cross organizational boundaries. They require different governance models. They fail differently. A miswired data team does not just ship slowly—it ships work that nobody trusts, nobody maintains, and nobody can explain when regulators or executives ask questions.

What Breaks When Data Teams Are Structured Like Software Teams

Software engineering squads are optimized for velocity within bounded domains. A payments team owns the checkout flow. A notifications team owns email and push. Ownership is clear because the surface area is discrete. Data products do not work that way. A customer health score might pull data from billing, product usage, support tickets, and marketing engagement. Who owns that score when it drifts? Who decides when to retrain it? Who validates that the features feeding it are still accurate after a schema change three systems upstream?

When data PMs are embedded in product squads without a shared operating model across the data organization, three failure modes emerge. First, data quality becomes everyone’s problem, which means it becomes nobody’s problem. Second, prioritization fractures—each PM optimizes for their squad’s roadmap, and cross-functional data infrastructure work gets perpetually deferred. Third, there is no forcing function for feedback loops. A model ships, usage drops after two months, and nobody notices because the PM has already moved to the next sprint.

IBM’s 2025 report on structuring modern data teams found that 64% of data leaders cited “unclear decision rights” as the top barrier to velocity. That number has increased from 48% in 2023. The problem is getting worse, not better, as organizations layer AI/ML capabilities onto already fragmented data team structures. If you cannot answer who decides when to deprecate a dashboard, you are not ready to operationalize a production ML model.

The Three-Horizon Data Team Topology

David Ohnstad has tested several data team structures across multiple organizations, and the one that consistently resolves accountability gaps without creating bottlenecks is what he calls the Three-Horizon Data Team Topology. It separates the data organization into three layers with distinct decision rights, communication cadences, and success metrics. This is not a hierarchy—it is a responsibility map. Each layer operates semi-independently but with defined interfaces and escalation paths.

Horizon One is the platform layer. This is where data infrastructure, core pipelines, observability tooling, and governance frameworks live. The team here is centralized. They own the data warehouse architecture, the ETL orchestration, the data catalog, and the contracts that downstream teams rely on. The product manager in this layer is not optimizing for feature velocity—they are optimizing for reliability, cost efficiency, and developer experience. Their roadmap is driven by SLAs, incident reports, and usage analytics from internal stakeholders. This is the only layer where centralization is non-negotiable. If every squad runs its own ETL stack, you will have six different tools, inconsistent data quality, and no leverage across the organization.

Horizon Two is the domain layer. This is where data product managers embed with business verticals: marketing analytics, sales operations, customer success intelligence, financial reporting. These PMs build domain-specific data products—dashboards, datasets, automated reports, predictive models—that directly serve business stakeholders. They own the what and the why: what decision does this product enable, why does this metric matter, what threshold triggers an alert. They do not own the infrastructure. They consume the platform that Horizon One provides. The decision right here is prioritization within their domain. They can say yes or no to a stakeholder request, but they cannot unilaterally change the schema of a shared table or deprecate a pipeline that other domains depend on.

Horizon Three is the experimentation layer. This is where data scientists, ML engineers, and analytics engineers prototype new capabilities that do not yet have product-market fit. This layer operates with higher risk tolerance and shorter feedback cycles. The output here is not production models—it is validated hypotheses and proof-of-concept work that either graduates to Horizon Two or gets killed. The PM role here is more like a research lead: curating experiments, setting success criteria, deciding what gets staffed and what gets shelved. Most organizations skip this layer entirely and push experimentation into Horizon Two, which creates friction because domain PMs are measured on delivery predictability, not discovery velocity. You cannot run both in the same org structure without one cannibalizing the other.

Decision Rights: The Part Most Org Charts Skip

The hardest part of structuring a data team is not drawing boxes on a slide. It is defining decision rights at the boundaries. What happens when a Horizon Two PM needs a new data source that requires a schema change in Horizon One? What happens when a Horizon Three experiment wants to use a production model owned by Horizon Two? Most data teams resolve these questions informally—Slack conversations, hallway negotiations, whoever escalates loudest wins. That does not scale past twelve people.

David Ohnstad’s framework assigns explicit decision rights at each boundary. For Horizon One to Horizon Two: platform changes require RFC (request for comment) review by all domain PMs who depend on the affected pipelines. The platform PM can override for reliability or cost reasons, but they must document the tradeoff and commit to a migration path. For Horizon Two to Horizon Three: any production data product can be forked into the experimentation layer, but the domain PM retains the right to sunset the original if the experiment proves a better approach. For Horizon Three to Horizon One: no experimental tooling or infrastructure can be promoted to the platform layer without passing a production-readiness review that includes cost modeling, observability coverage, and an on-call rotation plan.

This sounds bureaucratic. It is not. It is a forcing function for the conversations that data teams avoid until they create a crisis. A Horizon Two PM at a SaaS company David worked with wanted to migrate a customer segmentation model from a batch SQL job to a real-time feature store. The platform team said no—not because it was a bad idea, but because the feature store was still in Horizon Three and did not yet have the observability instrumentation required for production use. The conversation surfaced early, the domain PM adjusted their roadmap, and the platform team staffed the observability work for the next quarter. That negotiation would have happened eventually. The Three-Horizon model forced it to happen before anyone committed engineering time to a path that was not yet feasible.

Where Data Quality Ownership Actually Lives

One of the most common failure modes in data team design is treating data quality as a platform responsibility. It is not. The platform team owns the infrastructure that makes data quality measurable—data validation frameworks, anomaly detection, lineage tracking, schema enforcement. But they do not own the business logic that defines what “correct” means for a given dataset. That belongs to the domain layer.

In the Three-Horizon model, data quality ownership splits by concern. Horizon One owns pipeline reliability: did the data arrive, did the transformation complete, did the schema match expectations. Horizon Two owns semantic correctness: does this revenue number match the finance team’s source of truth, does this customer count exclude test accounts, does this churn definition align with how the business actually defines churn. Horizon Three owns experimental validity: is this training dataset representative, is this feature engineered correctly, does this model generalize beyond the sample.

This distinction prevents the most common blame spiral in data teams. A dashboard shows wrong numbers. The domain PM points at the pipeline. The platform engineer points at the SQL transformation written by the analytics engineer embedded with the domain team. Nobody owns the fix because nobody owned the definition in the first place. In David’s model, the domain PM owns the semantic contract. If the churn definition is wrong, that is a Horizon Two problem. If the pipeline failed to execute the correct definition, that is a Horizon One problem. The interface between them is the contract—documented, versioned, and testable. When the contract breaks, the failure mode is obvious.

When to Centralize, When to Federate, and Why Most Teams Get It Backwards

The question every data leader asks is whether to centralize the data team under a Chief Data Officer or federate PMs into business units. The answer is both, but not at the same time. Horizon One must be centralized. Horizon Two should federate as the organization scales. Horizon Three can operate as a centralized lab or as embedded researchers depending on how mature the business verticals are.

David has seen companies federate too early—spinning up domain data teams when the platform layer is still duct tape and manual runbooks. The result is duplicated infrastructure, inconsistent tooling, and data quality issues that metastasize because there is no forcing function for shared standards. He has also seen companies centralize too long—keeping all data work under a single VP while the business grows to thousands of employees and dozens of product surfaces. The result is a bottleneck. Domain stakeholders cannot get on the roadmap. The data team becomes an order-taking function, and the best PMs leave.

The forcing function for federation is when Horizon One reaches operational maturity. That means the platform has SLAs, the data catalog is discoverable, the observability tooling surfaces issues before stakeholders notice them, and onboarding a new data source takes days, not quarters. At that point, embedding domain PMs into business verticals accelerates delivery because they are not blocked waiting for platform work. If you federate before the platform is stable, domain PMs spend half their time troubleshooting infrastructure instead of building products.

Here is the contrarian part: most organizations federate data teams to increase velocity, but the actual unlock is accountability. A centralized data team optimizes for shared infrastructure. A federated model optimizes for business outcomes. If your data products are not changing business decisions, federation will not fix that—it will just distribute the problem. The prerequisite for federation is a culture where business stakeholders are willing to own the success metrics for the data products they request. If they are not, you are just moving PMs closer to people who will treat them like report factories.

Why Reporting Lines Matter More Than Most PMs Admit

Org design is not just about what work happens where. It is about who has authority to say no, who controls headcount allocation, and who gets credit when something works. David has worked in structures where data PMs reported to engineering, structures where they reported to business unit leaders, and structures where they reported to a standalone data organization. Each creates different incentive misalignments.

When data PMs report to engineering, the risk is that data product prioritization stakeholder management becomes subordinate to platform engineering velocity. The PM is encouraged to say yes to infrastructure projects that make engineers’ lives easier but do not directly improve data product outcomes. When data PMs report to business unit leaders, the risk is short-termism. The PM is pressured to ship dashboards that answer this quarter’s question, even if it means accruing technical debt or skipping the observability work that would prevent future incidents.

The structure David advocates is that Horizon One PMs report to a VP of Data Platform (or similar infrastructure leadership), Horizon Two PMs report to business unit leaders but with a dotted line to a Chief Data Officer for standards and governance, and Horizon Three PMs report to a Head of Data Science or Analytics who has explicit mandate to kill experiments. This creates healthy tension. The platform PM is insulated from short-term business pressure but measured on internal NPS and platform adoption. The domain PM is embedded with the business but accountable to a data leader for quality standards. The experimentation PM has air cover to say no to half-baked requests but must demonstrate learning velocity.

This is not the only way to structure reporting lines, but it is the structure that prevents the most common failure mode: data PMs becoming order-takers with no authority to push back on bad requests. If a data PM cannot kill a project that is not driving decisions, they are not a PM—they are a project coordinator. Reporting lines either enable or disable that authority. Most data team restructures fail because they change the boxes on the org chart but leave decision rights and escalation paths implicit. The org chart is a user interface for power. If you do not design it intentionally, it will encode the dysfunction you are trying to fix.

The Operational Overhead Nobody Budgets For

One of the surprises in data team design is how much operational overhead comes from the boundaries between horizons, not from the work within each layer. Cross-horizon coordination is not free. It requires standing meetings, shared artifacts, escalation runbooks, and someone with the authority to break ties when domain priorities conflict. Most organizations budget for the PMs, the engineers, and the infrastructure—but not for the operating model that makes those people effective.

David’s framework includes three operational primitives that are non-negotiable. First, a weekly cross-horizon sync where platform PMs surface upcoming changes, domain PMs flag capacity constraints, and experimentation leads propose graduating prototypes. This is not a status meeting—it is a forcing function for early conflict resolution. Second, a shared roadmap artifact that shows dependencies across horizons. This is not a Gantt chart. It is a directed graph where nodes are projects and edges are dependencies, updated weekly, visible to the entire organization. Third, a bi-weekly data council where senior leadership from each horizon reviews metrics, approves or kills major initiatives, and allocates shared budget.

These primitives feel bureaucratic when you write them down. But the alternative is Slack threads with fourteen people, decisions that get made in hallway conversations and never documented, and PMs who waste hours re-explaining context because there is no shared source of truth. Organizations that adopt AI/ML toolchains without integrated platforms—like those discussed in David Ohnstad on AI and enterprise SaaS—often discover that fragmented tooling compounds these coordination costs exponentially. The operational overhead is not optional. The question is whether you design for it upfront or let it emerge as meetings that could have been emails and emails that should have been decisions.

What This Means for Mid-Year Restructures Happening Right Now

If your company is in the middle of summer planning and someone just proposed reorganizing the data team, here are two diagnostic questions that will clarify whether the Three-Horizon model applies. First: can you name who owns data quality for your three most critical data products, and do those people agree with your answer? If no, you have an accountability gap that an org chart will not fix. You need decision rights, contracts, and enforcement mechanisms before you move people around. Second: does your data team have a forcing function for killing low-impact work, or does everything that gets started eventually ship? If the latter, you are missing the experimentation layer. Domain PMs are doing discovery work on production timelines, and it is burning them out.

For practitioners: if you are a data PM being asked where you should report, push back on the question. Ask instead: what decisions do I need authority to make, and what decisions should require escalation? If the answer is “you own the roadmap but leadership has veto rights,” you are being set up to be a scapegoat. If the answer is “you own prioritization within your domain but platform changes require cross-team review,” you have real authority. The reporting line follows from the decision rights, not the other way around.

For leaders: the failure mode David sees most often is restructuring the data team without changing how data product management strategy is resourced or how success is measured. You move a PM from centralized to embedded, but you do not change their OKRs, you do not give them budget authority, and you do not shield them from the request queue. The structure changes, the problems do not. If you are serious about making data a product discipline and not just an engineering function, the operating model matters more than the org chart. As explored in David Ohnstad on leadership and career growth, reverse mentorship between data leaders and junior talent can accelerate adoption of these structures across organizational levels—but only if the structure itself is coherent.

How do you decide whether to centralize or federate a data product team?

Centralize the platform layer first. Federate domain-focused PMs only after the data platform has documented SLAs, self-service tooling, and observability that surfaces issues before stakeholders notice them. If you federate before the platform is stable, domain PMs spend more time firefighting infrastructure than building products. The signal you are ready to federate: new data sources onboard in days, not quarters.

What decision rights should a data product manager actually have?

A data PM should own roadmap prioritization within their scope, define semantic contracts for the data products they ship, and have authority to kill low-impact projects. They should not have unilateral authority to change shared platform infrastructure, deprecate datasets other teams depend on, or bypass governance reviews. Decision rights must be explicit, documented, and matched to reporting lines—otherwise authority becomes whatever the loudest stakeholder demands.

Why do most data team restructures fail within the first year?

Because organizations change the org chart without changing decision rights, success metrics, or operating cadences. A PM moves from centralized to embedded but keeps the same backlog, same stakeholders, and same lack of authority to say no. The structure changes, the dysfunction does not. Restructuring works only when paired with explicit accountability boundaries, cross-team coordination primitives, and leadership willing to enforce prioritization discipline across competing business units.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.