Ask HN: How are large software teams split up?

[paulstovell]

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.

[dragosbulugean]

I've seen plenty of teams with 20-30 engineers working on the same product. At this level, what usually happens is, everyone has a specific role along with their main one, and I don't mean front-end, backend, database. More of: somebody builds internal dev tools, somebody else maintains documentation, somebody acts as a semi-architect if there's no designated one, somebody helps QA team automate their stuff, somebody participates more in higher-end meetings, etc.

This knowledge comes from a couple of teams that use my product https://archbee.io

[twunde]

Typically companies and teams are split up by either function or by product (See https://stratechery.com/2016/apples-organizational-crossroad... for some thoughts on this). Assuming that you will have 50 engineers working on one product, they will probably be working on different parts of that product. While you can do a front-end/backend split it's more common for a team to support certain functionality of the application. If you take Github as an example, they probably have a team supporting git operations, a team for Issues, a team supporting adding new security features. Similarly your product will have groups of features that one team will support whereas another team will be responsible for features C, D and E.