The Org Chart Problem: Why AI Features Die Between Teams

The model works. The pipeline runs. The demo looks great. And then the feature dies somewhere between the data team's Slack channel and the product engineer's JIRA board.

This is the pattern behind most AI project failures—not a technical failure, but an organizational one. A 2025 survey found that 42% of companies abandoned most of their AI initiatives that year, up from 17% the year prior. The average sunk cost per abandoned initiative was $7.2 million. When the post-mortems get written, the causes listed are "poor data readiness," "unclear ownership," and "lack of governance"—which are three different ways of saying the same thing: nobody was actually responsible for shipping the feature.

The engineering team blames the data team for unstable pipelines. The data team blames the ML platform for slow deployment tooling. The ML platform team blames product for constantly changing requirements. And the feature sits in that gap, slowly rotting, until someone decides the cost of continuing is higher than the cost of canceling.

Three Teams, Zero Owners

The classic setup that kills AI features is this: an ML platform team builds infrastructure, a data team owns pipelines and training data, and product engineering owns the user-facing code. On paper, this looks like specialization. In practice, it looks like three groups with no incentive to own the hard problems that fall between them.

The hard problems are not glamorous. Who debugs the discrepancy between the model's training accuracy and its production behavior? Who writes the alert that pages someone when the model starts degrading at 2am? Who owns the decision about when model quality is "good enough" to ship? Who iterates on the prompt when a product manager finds a failure case in user research?

Every one of these questions has a ready-made deflection. The ML team will say model evaluation is their job but production monitoring belongs to platform. Platform will say they provide the infrastructure but not the business logic. Product engineering will say they own the API but not the model. And the data team will say they own the features used in training but not what happens during serving.

This is what organizational accountability gaps look like in practice. Nobody is lying about their responsibilities. Everyone is accurately describing the boundary of their role. But the features that actually need to ship live in the space between those boundaries—and that space has no owner.

Conway's Law Has a Model Problem

Conway's Law states that systems mirror the communication structures of the organizations that build them. Every engineer who has worked in a microservices shop knows this intuitively: the service boundaries tend to follow the team boundaries.

For AI systems, Conway's Law applies with extra force. The Volkswagen Cariad disaster is the textbook example: three organizational silos (Audi, Porsche, and VW brand teams) built three separate architectural approaches within a single company. Insiders described arriving with no job description, no clarity on their role, and defaulting to "building what I knew from my brand." The result was duplicate models, incompatible architectures, and a system that structurally reflected organizational dysfunction rather than engineering decisions.

When you split AI ownership across ML platform, data, and product engineering, you don't get the benefits of specialization. You get a model serving layer that doesn't match the training pipeline, a data schema that was designed for analytics queries and not feature serving, and a product team that treats the AI as a black-box API they can't debug. Each team optimizes for their own success criteria, and nobody owns the coherent whole.

The teams that build AI features into successful products tend to look different. They're small, cross-functional, and they own the feature end-to-end. One ML engineer, one product engineer, one data engineer, one PM. One team, one feature, one clear owner of every question that falls between disciplines.

The Last Mile Nobody Owns

The "last mile" problem in AI is the gap between a working model and a shipped product feature. Fewer than 50% of AI projects that produce a working model ever reach production. The reasons are almost never technical—the model works, the infrastructure exists. What's missing is someone who owns the integration.

Consider what integration actually requires:

• The model needs to be versioned and deployed with the same rigor as application code.
• The production serving path needs monitoring with alerts someone actually responds to.
• The feature needs fallback behavior for when the model fails or degrades.
• Someone needs to bridge model accuracy metrics and product business metrics—they're not the same thing, and both matter.
• Prompt changes need a deployment path that isn't "ask an ML engineer to merge a PR."

None of these problems require specialized AI expertise. They require ownership. They require one team that is responsible for the feature working—end to end, in production, over time.

When ML platform owns infrastructure, data owns pipelines, and product owns the UI, nobody owns the integration. The feature works in staging, fails in production, and the post-mortem produces a list of contributing factors rather than a single responsible party.

The Friction Points That Don't Show Up in Retros

The accountability gaps that kill AI features rarely announce themselves as the root cause of a failure. They show up as friction that teams learn to live with.

Training-serving skew. Data scientists write SQL to extract features for model training. When deployment time comes, someone has to rewrite that logic for production serving—usually in a different language, with different dependencies, optimized for latency rather than throughput. This rewrite introduces bugs. The model behaves differently in production than it did in training. Who owns the discrepancy? In a split-team structure, this question stays unanswered until something breaks loudly.

Prompt iteration velocity. In generative AI products, the prompt is a core component of the feature—but it often doesn't have a clear owner. Product managers can't edit it without engineering cycles. ML engineers can edit it but may not have the domain context. Platform teams own the deployment mechanism but not the content. The result is prompt changes that take two weeks to ship when they should take two hours.

On-call without ownership. When a model degrades in production, who gets paged? If the answer involves three teams receiving the same alert, you'll get three teams waiting for each other to respond. If the answer is nobody, you'll find out about the degradation when a user complains. Production AI systems need on-call ownership the same way backend services do, and that ownership has to belong to a team that can actually act on the alert.

Metrics translation. ML teams measure accuracy, F1 score, BLEU, or whatever domain-specific metric the model was trained against. Product teams measure conversion, engagement, task completion, and user satisfaction. These metrics don't automatically correspond to each other—a 3% accuracy improvement on the model might be invisible to product metrics, while a specific failure mode the model handles poorly might be destroying user trust. Without a team that owns the bridge between these two metric spaces, models pass validation and then underperform in production.

Ownership Models That Close the Gaps

There are a few organizational patterns that actually work. They share a common property: they locate accountability for the end-to-end feature in a single team.

The embedded ML engineer model. An ML engineer sits inside the product team, co-locates with product and software engineers, and owns the AI feature as their primary responsibility. They're not a platform team member loaned out to product—they're a product team member with ML expertise. The data team provides support; the platform team provides infrastructure. But the embedded ML engineer owns the feature: its quality in production, its iteration velocity, its business metrics.

This model is fast and clear. It's also hard to scale past a small number of features, because each feature requires a dedicated ML engineer.

The cross-functional feature squad. A squad of four to six engineers (one ML, one or two software, one data, one PM) owns a feature or a small cluster of related features end-to-end. The squad is permanent—not a project team that dissolves after launch. They own the feature from research through production monitoring, including on-call.

Spotify's squad model applied to AI features works like this. The squad is autonomous, with enough capability to ship and maintain the feature without external dependencies. Guilds provide knowledge sharing across squads to prevent silos without creating bottlenecks.

The hub-and-spoke Center of Excellence. A small central AI team sets governance standards, manages model infrastructure, and owns cross-cutting concerns like safety and compliance. Embedded practitioners in product lines own specific features. The center doesn't own feature shipping—the embedded practitioners do. The center owns the things that need to be consistent across features.

This model scales past what feature squads can reach, but requires disciplined separation between what the center controls (infrastructure, standards) and what the spokes own (feature outcomes).

The model that fails almost universally: a platform team that provides everything while product engineering ships features by consuming platform APIs. This looks efficient on paper and generates bottlenecks in practice. Platform becomes the constraint for every feature. Feature teams can't iterate without platform involvement. On-call accountability remains ambiguous. Training-serving skew has no owner.

The Directly Responsible Individual for AI

The concept of a single directly responsible individual (DRI) for a feature is not new. Apple's management philosophy is built around it. Many engineering organizations apply some version of it.

AI features need a DRI who owns more than the code. The AI feature DRI is responsible for the model's production behavior, the training data quality, the prompt strategy, the business metric impact, and the operational health—not as an expert in each of these, but as the person who is accountable when any of them fail.

This is a different accountability model than most engineering organizations are built for. A backend engineer owns the service. An ML engineer owns the model. A data engineer owns the pipeline. The AI feature DRI owns all of it in aggregate, and coordinates the specialists who do the individual work.

Organizations that ship AI features at velocity tend to have this accountability structure, even if they don't call it a DRI. They have one person—usually a senior ML engineer or a technical PM with strong ML fluency—who is the answer to "who do we call when the feature breaks."

Org charts that make this person unclear are the org charts that produce $7 million abandoned pilots.

What to Change This Week

If you're an engineering leader looking at an AI initiative that's stalling, the answer is almost never to add process or create a new governance committee. It's to assign clear ownership.

Look at your current initiative and ask:

• Who gets paged at 2am if the feature degrades?
• Who decides when model quality is good enough to ship?
• Who owns the bridge between model accuracy and business metrics?
• Who can change a prompt without waiting for an engineering cycle?

If the answer to any of these is "we'd need to coordinate across teams," you have an accountability gap. Close it by assigning a DRI with the scope to own the full answer, or by restructuring the team to put all the necessary capability in one place.

The technology for AI features has largely converged. What separates organizations that ship from organizations that pilot is whether the org chart assigns ownership clearly enough for one team to see a feature all the way through.