Mechanism
The org chart doesn't actually separate them; the incentives do
Most people assume data teams end up isolated because they report to the wrong person or sit in the wrong office. But I've seen data teams report directly to CTOs and still be completely siloed. The real problem is that data work doesn't have a forcing function the way product engineering does. When you build a feature, someone ships it, someone deploys it, someone on-calls it. Feedback loops are tight. Data work lives in this strange middle ground where the output is often "insights" or "dashboards" or "improved models," which can float around indefinitely without anyone actually changing their behavior based on it. So data teams optimize for what they can control—rigor, thoroughness, technical correctness—and engineering teams optimize for what they control: shipping. They're not actually misaligned; they're just solving different problems.
The second thing people miss is that data work usually requires context that engineering doesn't have and isn't incentivized to build. My last job, we had a data team trying to optimize our recommendation model. Great engineers, solid ML background. But they were working from event logs and the product specification document. They didn't know that the PM had changed the ranking criteria three weeks ago and hadn't updated the spec. They didn't know that mobile was dropping 40% of events because of a logging bug that hadn't been prioritized. They kept producing beautiful analyses on top of incomplete information. The fix wasn't better organizational structure—it was the data team owning a service that other teams depended on, so debugging became a joint problem.
That's the pattern that actually works, when I've seen it work: make the data team's output a hard dependency. They don't own insights that people might read. They own the canonical event schema, or the feature store, or the metrics definitions that everyone else's dashboards run against. When engineering breaks something, it breaks the pipeline and the data team knows immediately. Suddenly you want to be in the same room.
3 comments
Log in to comment.
You're describing what happens when you confuse alignment with proximity. The org chart is just theatre; what matters is whether someone's oncall when things break.
The thing that stuck with me from your example is that the data team had all the tools to find those problems—they could've queried the logs, traced the event schema, found the 40% dropout. They just had no incentive to. And why would they? If your job is "produce accurate analysis" and no one's paging you at 2am saying "the insights you published yesterday broke our revenue model," then thoroughness looks like obsessing over statistical rigor on incomplete data. You're doing your job perfectly. The system is just broken.
Making data a hard dependency is the only thing I've seen that actually forces the friction to surface instead of hiding it in passive-aggressive Slack threads. We did this with metrics definitions a couple years ago—marketing, product, and data all had to agree on what "conversion" meant before anything could be measured. First week was hell. Everyone's favorite pet metric got real suddenly. But after that, when someone wanted to change how we counted something, three different teams showed up with questions, not to be difficult but because now they actually owned the consequence. The data team went from "we'll produce whatever you want" to "if you change this, here's what breaks," which sounds worse but it's actually the moment communication starts.
The dependency angle is sharp, but I'd push back slightly on how clean the fix actually is. Yeah, making data a hard dependency creates forcing functions—I've seen that work too. But you're describing the version where the data team owns infrastructure that has obvious blast radius. That's maybe 30% of data work at most companies.
What about the team that owns "did this experiment move the needle" or "which cohorts are churning"? You can make their output a hard dependency by saying "all major decisions require a data review" but then you're just creating a gate, not aligning incentives. The PM still ships if they disagree with the analysis. The engineer still prioritizes features that feel right. You've just made the data team slower and more frustrated, which I've definitely seen happen.
The real thing your example highlights—the PM changing ranking criteria without telling anyone—that's not actually solvable by org structure or making data a dependency. That's a communication debt that exists across the whole team. The data team could own the metrics definition and still not know about that change if it happened in Slack. The thing that actually fixes it is someone (probably a tech lead or EM) paying the cost to keep context synchronized, and that's unglamorous work that doesn't show up in anyone's OKRs.
So yeah, hard dependencies help. But they only work when the dependency is real and visible. Everything else falls back to the human problem, which is way harder.
Yeah, this tracks with what happened when we tried to fix our metrics infrastructure three years ago. We had this whole reorganization thing—moved the data folks under the VP of Engineering, thought that would fix it. Nothing changed. Then we had an incident where someone's bad join logic quietly corrupted our revenue numbers for two weeks, and nobody caught it until finance got suspicious. Post-mortem was brutal but useful: turns out the "insights" people were producing weren't actually wrong, but they had no skin in the game when they were wrong. No alert, no on-call, no someone waking up at 2am.
What actually moved the needle was making the metrics pipeline itself owned infrastructure. Not "data team provides metrics," but "here is the schema, here is the canonical definition of 'daily active user,' and if your dashboard is calculating it differently you're doing it wrong." Suddenly data and product had something to debug together instead of something to debate. The data team cared about latency and correctness because downtime hit everyone. Engineering cared about the event schema because breaking it meant their deploys wouldn't land.
The thing I'd push back on gently: owning a hard dependency helps, but it's not magical if you don't also fix the async communication problem. We still had weeks where the data team was optimizing a feature flag logic that had already been replaced in production. The dependency made things more visible, but visibility without synchronous coordination still leaves you with clean technical work on top of stale assumptions.