They reorganized the data team three times in two years. Each time, things got worse.
The first reorg: centralized everything. “One data team to rule them all.” Six months in, the central team became a bottleneck. Every request took three weeks.
The second reorg: fully decentralized. Data engineers embedded in each product team. Six months later, four different definitions of “active user” and no shared infrastructure.
The third reorg: a new VP of Data with a new vision. The team spent more time learning new processes than building anything.
Here’s what I’ve learned watching this pattern repeat:
The problem is rarely the structure. Centralized works. Decentralized works. Federated works.
Most reorg failures trace back to conflicting incentives, not wrong org charts. If success metrics pit teams against each other, reorganizing just relocates the tension.
Before restructuring, answer these questions: Are teams rewarded for the same outcomes? Does helping another team hurt your metrics? Is “platform work” visible in performance reviews?
If you can’t answer those clearly, the reorg won’t help. If you can answer them clearly, you might not need the reorg at all.
If you’ve survived a data team reorg, what actually helped vs. what made things worse?