[kat]

You describe almost exactly how my team approaches our development. We are ~80 developers on a single web application. The core team deals with the landing page (to put it simply) and the other teams (5 to 10 devs per subTeam) deal with their own section. When we first started this project there was a UI team that was made up of one developer from each subTeam. This ensured that as UI work was done it was consistent and each subTeam knew about the available UI controls to use. Something like a datepicker took a lot of back'n'forth between everyone, but we're a few years in now and our UI controls are pretty stable. We also had a lot of decisions around "this is what a data-entry form looks like" so the basic CRUD workflow on each team is pretty similar. We also aim to all use the same 3rd party libraries (ie one dateTime library, one webpack configuration for everyone, etc). It was a lot of decision making and a lot of time spent making a shared understanding, but worth it in the long run.

What really helped was the PM team was very consistent as well. They knew how important consistency was and didn't argue if one team had already designed a save button, then they were cool with using the same button on the other sub team. Make sure you have full agreement with your PMs!

Lastly, unit test everything! The core team was frequently blocking the sub teams because they would make breaking changes. Now that our process and teams are a bit more mature it happens less, but working on the culture around this will help. Ensure that people see it as "helping out another team" rather than a "us vs them" situation. Having a CI system that runs tests on code before its checked into master is worth every second spent creating and maintaining it. And also checkin code asap, you'll have less integration issues. We also had QA that tested across the subTeam work.

I'm not sure what the name of this is, but it worked for us :)