Ask HN: How are large software teams split up?

Common wisdom for management is to have teams in the 5-12 range. What happens to software teams that grow beyond this size? How are organizations like this structured?

For example, you've grown organically to about 20 engineers involved in a single shipping software product. You plan to grow the team to 50, so you know you'll need a handful of teams. There are no clear architectural boundaries (client/server) that make the decision obvious. Most new features that need to be built require touching many parts of the code (frontend, backend, integrations, documentation). You only know you need to grow the engineering team because there's a never-ending list of features & enhancements you'd like to make.

For the AWS development teams, for example, it seems obvious there would be division around products - this team looks after S3, that team looks after DynamoDB. But what happens if the S3 team is itself 30 developers and needs to be divided up? How do you decide which team owns what?

I'd appreciate any real-world examples of insights on this. Not so much what the teams do (we all do standups, etc.), but how they drew the boundaries in the first place. Deciding 5-12 people teams is the optimum size feels like deciding the ideal electorate constituency is 100,000 people; the devil is actually drawing the boundaries on the map.