With a lot of small teams, you have each team producing components which are relatively good individually thanks to easy, flat, one to one communication and continuity of means and responsibility. The alternative is some degree of siloing which tends to cause significant overhead which can even result in an organization being completely blocked.
But it's not a perfect approach either. It's really hard to maintain consistency and you tend to have some degree of duplicated effort. This explains partly why AWS is so inconsistent in term of API and also why the console is so slow (and just unusable garbage past a certain size).
And it's not like there is no gradation in between individual teams acting alone and big silos. You could pretty much have something that tries to mix the better of both view, with some kind of lose central authority that is here to enforce stability, SLA, overall architecture and consistency of interfaces (both API and UI) but doesn't dictate which tools mut be used.
With a lot of small teams, you have each team producing components which are relatively good individually thanks to easy, flat, one to one communication and continuity of means and responsibility. The alternative is some degree of siloing which tends to cause significant overhead which can even result in an organization being completely blocked.
But it's not a perfect approach either. It's really hard to maintain consistency and you tend to have some degree of duplicated effort. This explains partly why AWS is so inconsistent in term of API and also why the console is so slow (and just unusable garbage past a certain size).
And it's not like there is no gradation in between individual teams acting alone and big silos. You could pretty much have something that tries to mix the better of both view, with some kind of lose central authority that is here to enforce stability, SLA, overall architecture and consistency of interfaces (both API and UI) but doesn't dictate which tools mut be used.