We split our app into services but kept our old team structure—front-end team, back-end team, QA team. Disaster. The back-end team "owned" all eight services, which meant nobody really owned any of them. When the inventory service had bugs, everyone pointed fingers.
I watched our velocity crater in Q2 2024. Every feature crossed service boundaries. The teams had to coordinate constantly. Slack threads with 47 messages just to agree who would fix a bug. Standups turned into hour-long coordination meetings.
Our VP of Engineering finally forced the issue: each service needed an owner. We reorganized into vertical teams—Payments team owned the entire payment stack, Catalog team owned product data, etc. Suddenly people gave a damn about code quality because it was their service.
The weirdest change? We hired differently. The Payments team needed someone who understood fraud detection, PCI compliance, and payment gateways—not just "a backend engineer." They hired someone from Stripe. The Recommendations team brought in a data scientist. Our teams stopped looking like generic engineering pods and started looking like specialized units.
Last month I was talking to a friend at a company still running a monolith. They've got 30 engineers all working on the same codebase. I don't know how they coordinate changes. But I also remember when we tried the same with microservices—it didn't work either. The architecture forces organizational changes whether you're ready or not.