Team structure is a design problem. Developers can be quite good at it, once they start to look at it that way. Designing the team structure around the architecture has a lot of benefits. However, if you have a hairball interdependent architecture, you can't build a good team structure around it. Trying to throw more people at the problem and artificially carve it apart is often where software organizations fail.
Trying to go faster and throw more people at it often results in going *slower*. Teams get stuck in a trap of trying to police the code with reviews and there's no way to keep up. The best resources can no longer be productive because they spend all their time reacting to the system that is busting at the seams. Until the team learns a way to design the system in a way that *communication* can be scaled, leaders need to keep their foot off the accelerator pedal. We need the time to invest in that critical learning.
I don't think it's a hands off, let the team figure it out kind of problem. Organizational design is challenging problem and we need leadership to help figure it out. But we need leaders that listen to their engineers, that know what to look for, and have an appreciation for the challenges of our craft.