You doubled your data team. Delivery got worse. Fred Brooks explained why in 1975.
The formula is simple: n(n-1)/2. A team of 3 has 3 communication paths. A team of 6 has 15. A team of 10 has 45. Every new hire adds communication overhead that eats into the time they were supposed to free up.
I see this at almost every client that scales past 5 data engineers. Suddenly there are more alignment meetings than coding hours. Standups take 30 minutes. PRs sit in review because nobody knows who should look at what.
The reflex is to add process. More Jira tickets, more documentation requirements, more weekly syncs. That makes it worse. You’re adding coordination cost on top of communication cost.
Design your teams so they can ship independently. Give each sub-team a domain they fully own - repo, pipeline, deploy. Define the handoff between teams as a contract, not a conversation. If a schema change requires a meeting, your boundary is wrong. One client split their 8-person team into two squads of 4. Same headcount, half the communication paths, and PRs stopped sitting in limbo for three days.
I’ve changed my mind on this over the years. I used to think shared ownership meant better carried solutions. Now I think it means slower delivery and diffused accountability.
How many communication paths does your data team actually have? (Hint: n(n-1)/2.)