When during a job interview they ask me what was the size of my team, I invariably say something between 2 and 5, and comment that a larger team cannot be efficient. At least, in my practice a larger team was never efficient as a team, and I helped split teams as they grew past this threshold.
3 is risky. One person has a baby and goes on leave, or gets long Covid, or is poached by a FAANG. Until a replacement can be found, the team of 3 turns into a rather overwhelmed team of 2, each spending 50% time on call. And if either of them goes on vacation to recharge, the remaining one is left with an unbearable workload.
We have 33-50% on call and noone complains because not a lot is happening.
You certainly want more than one of those teams to be able to support each piece of your software. You also want to be able to move people quickly from a team to a close one, so from the training point of view you also want them to know both codebases.
If you draw a dot for each member of a team and then a line from each dot to each other dot, you can see the "lines of communication".
With 3 members, there are 3 lines of communication (loc)
4 members, 6 loc
6 members, 15 loc
10 members, 45 loc
14 members, 91 loc
Communication breaks down as more people are involved.
https://en.wikipedia.org/wiki/Metcalfe%27s_law
As you get more and more lines of communication you end up having to break them and create a hierarchy.
This is the same as the number of undirected edges in a N clique graph with no self edges.
I would not even wait for problems to emerge. Just split big teams on principle. Minimum size of 3. Maximum size of 7. One eight person team then becomes two teams of 3,4,or 5 people. Make sure each team has a tech lead that knows what they are doing.
Don't over-staff teams with managers/minders/scrum masters/whatever label you slap on junior management. This causes a big problem: managers like to hoard people to inflate their importance. You deflate their team and you deflate their ego and they'll be forever whining to "fix it" with more "resources".
Simple solution: give them more than 1 team to manage and direct them to keep their teams small. Now they count teams instead of people. Or teams and people. And you can measure their success as a function of how well their teams are performing.
Then if those teams get overloaded, you have a conversation about which new teams are going to be needed and who is going to manage them. Any new team should be bootstrapped with mostly existing people: you move people around and promote them. New people start out in existing teams. This accomplishes two important things: people have a perspective of getting promoted sideways and new people learn the ropes in a small well functioning team rather than being dumped in an overstretched team.