Why data teams stay siloed even under CTOs

I keep running into the same pattern at different companies, and I'm trying to figure out if it's structural or just how we've all been broken-in by the same few bad decisions. The question is: why does a data team with a CTO sponsor still operate like a separate vendor? Same org chart, same Slack, same standup—but they're answering different questions, using different tools, and their deployments don't integrate with the standard CI/CD pipeline. You end up with a data warehouse that the rest of engineering has to reverse-engineer to use, Jupyter notebooks nobody wants to maintain, SQL that drifts from what the application is actually doing. I think the gap is real but not because data problems are *that* different. It's because data work has a different failure mode. When a service goes down at 3am, everyone feels it. When a data pipeline silently produces garbage for a week, sometimes nobody notices until the business is upset. That asymmetry pushes data teams toward conservatism—less automation, more validation, slower deploys. Meanwhile the rest of engineering is optimizing for velocity and observability. The CTO wants both, which sounds reasonable until you're actually trying to merge those incentives into a single incident response culture. Then the CTO stops picking sides and everyone pretends they're aligned. What I haven't figured out is whether this gets better by hiring infra people into data roles, or whether it needs the reverse—getting data-minded people into the core deployment loops. Both feel halfway. The companies I've seen actually fix this tend to blur the distinction in hiring and oncall rotation, which sounds nice but you need enough size and maturity to pull off without things breaking.