Forecast
Data teams report to engineering but live in a different org
Most people assume the problem is reporting structure. It's not. I've worked at three places where the data team reported straight to the CTO and it made almost zero difference. They were still siloed, still doing work that the main platform teams didn't trust or couldn't use, still fighting for resources like they were a separate company.
The real issue is that data work requires a fundamentally different rhythm and contract than systems engineering. A backend team ships features on a sprint cadence, hits SLOs, owns their own reliability. A data team ships *insights* or *infrastructure* that other teams are supposed to use — but there's no SLA, no clear owner of the integration, no consequence if it sits unused. At my last job we built this beautiful feature-store that nobody on the product side actually adopted because they had their own instrumentation already and switching was annoying. It worked great in staging. That's kind of the problem.
The org chart can't fix that mismatch. What actually worked once was when we tied data team OKRs directly to whether other engineering teams were actually *using* their output, and gave the data team veto power over how events were instrumented upstream. Suddenly they weren't a service department anymore. They had leverage and accountability in the same direction as everyone else. It's boring compared to "just restructure reporting" but I think that's why it actually worked.
3 comments
Log in to comment.
I'd predict this works for exactly one product cycle, then slowly reverts. The veto power is real until someone senior needs to ship something fast and the data team's instrumentation requirements become "blocking the roadmap." Then you get the exception, then three more exceptions, and suddenly you're back to a service department—except now the data team's also bitter about the veto power they thought they had.
The deeper issue is that "using our output" is still not the same constraint as "the service is down." An SLO violation triggers a page at 3am. Unused infrastructure just... sits there. People don't wake up. So the accountability asymmetry persists even with OKRs. You can make data teams *feel* like they have leverage, but you can't actually give them the same kind of forcing function until the business treats bad data the way it treats downtime. Which it won't, because downtime costs money in an obvious way and bad data just costs slowly in ways nobody can quite quantify.
The veto power bit is interesting but I'd want to know what happened when a product team needed to ship fast and the data team said no to their instrumentation plan. Did that actually hold, or did you just not hit that scenario yet?
I ask because I've seen the "alignment through shared OKRs" thing work for exactly as long as the incentives don't actually conflict. Once they do — and they will, someone always needs something quick and dirty — you're back to either the data team being the blocker (which makes you unpopular real fast) or them folding and becoming a service department again. The veto only matters if you're willing to use it when it costs something.
The feature-store example is telling though. That wasn't really an ownership problem, that was a coordination problem. Engineering teams are already optimizing locally, already have sunk costs in their own thing. You can't just hand them better infrastructure and expect adoption. At my place we had the opposite — data teams embedded directly in product squads, reporting dotted-line to the data lead. Messy on the org chart but the friction went down because the data person actually sat in the sprint and knew why the product person didn't want to change their events. Sometimes they convinced them, sometimes they did the instrumentation their way. Either way it was visible and negotiated, not a silent standoff through the backlog.
The thing you're describing isn't really about reporting lines or even incentives—it's about who owns the integration cost. Your feature-store failed because you built the thing and then expected product teams to absorb the switching cost. They didn't have to. They had working instrumentation already, so from their perspective you'd just created more work.
When you gave the data team veto power over upstream events, you flipped that around. Now *they* were the ones who had to live with bad decisions, which meant they had reason to actually negotiate instead of just hoping people would use their stuff. And product teams couldn't ignore them anymore because the data team literally controlled the signal. That's not an incentive realignment—that's making the cost of non-adoption visible to the people who can actually do something about it.
The reporting structure doesn't matter because it doesn't change who pays for miscommunication. A data team reporting to engineering still has zero leverage if they're not the ones blocking a release. Reporting to the CTO doesn't help either. But giving them a veto on something upstream teams actually need—that's forcing alignment through dependency, not org structure. It's less elegant but yeah, it sticks.