Ask HN: Resources to approach splitting a large web app across multiple teams

[hi_its_trevor]

We've pushed our team sizes to the max and we have to hire more. The only reasonable step I see is splitting the app across two teams.

This must be the norm for large apps at large companies (I've never worked for one.) My current strategy is based on keeping one team over a core set of functionality. Then dividing the rest of the Views/Services based on feature set across the teams.

Any resources on this problem would be appreciated.

[cratermoon]

https://melconway.com/Home/Committees_Paper.html

[vaidhy]

TLDR; Any decision you take will be criticized and will be pointed out as the reason things went bad :).

I think it is a question of trade-off and what works well within your company culture.

You can do what you suggested, but your core team will become the bottle-neck. Your features team will feel left out and unhappy that they are not doing the "important" work. This has been the Microsoft approach.

You can also have every team get a copy of the core and run the entire stack. If there is consolidation needed, you let them evolve. DRY goes out of the window and everyone else will wonder if you are nuts. People who like efficient planning would hate you and you are likely to incur higher operational costs. This follows a philosophy of "two is better than none". Thia has been the Amazon approach.

There are some intermediate ones, but irrespective of these approaches, your velocity will slow down significantly (like 10x) since teams need to coordinate with each other as opposed to people coordinating within the team. You would need additional layers of product and program managers. Planning is now much harder. This is part of growing up and this transition is really, really hard.

My personal preference would be to make core a technology decision and choice and not code. Get rid everything that is custom developed, if it can be replaced by an industry standard, well established framework, even if the framework gives you features and bloat that you think you do not need. Keep the core light and manage it as would manage an infra team. Then the services team can own features that go deeper into the stack and mostly be self-sufficient.