Caveat: I have not implemented microservices, but have plenty of experience with monoliths. "With well-defined interfaces and properly-sectioned functional com

Caveat: I have not implemented microservices, but have plenty of experience with monoliths. "With well-defined interfaces and properly-sectioned functional components teams can work just as independently on a monolithic application as they can on a microservice application" Basically if you build a monolith such that it is not a monolith things are ok. This doesn't happen in my experience. Speaking first hand, working with 40 engineers on a 500k+ line codebase. The monolith is as robust as it's weakest component. There are secondary organizational effects that come into play as well with monolith architecture that need to be mitigated. Because there's a single monolithic platform, the org believes it can throw any set of engineers at a problem in the monolith and get the same result. This largely gets down to what philosophies you buy into, but I personally believe long lived teams with long lived missions are better capable to innovate (team builds depth of expertise in a capability vs breadth). There are plenty of ways to do anything wrong of course. More so, as the team scales to more engineers, the monolithic architecture re-enforces the monolithic engineering org which means an increase in communication overhead. My experience is that by creating a monolith you create one way to do things that leaves the organization less adaptable to change to implementing a new technology or pattern.