I would agree with you that it could be useful for organizational problems but I would resist this as long as possible. In any case, I prefer to not split engin

I would agree with you that it could be useful for organizational problems but I would resist this as long as possible. In any case, I prefer to not split engineering teams but for practical reasons (e.g. keeping onboarding times into the team reasonable) you are quite forced to do so. Once your team loses the rapid feedback of "did this break user-facing functionality yes/no?" your reliability and speed of shipping features deteriorates rapidly as now most engineers will start to fear shipping to production. Ideally, you break the team into subteams and follow the natural fault-lines in the codebase. Most codebases have areas that do not interact much (or not at all) with each other and they lend themselves well to assigning to a specific subteam. I'm sure there's a point where this breaks also but I haven't reached it yet.