[bunderbunder]

This is really what it comes down to right here. The real challenge is Conway's Law. Both the software architecture and the org chart need to be designed with Conway's Law in mind. If that hasn't happened then deciding between microservices and monolith is ultimately just deciding how you will be punished for your mistake.

[roguecoder]

People misunderstanding Conway's Law is a big part of the problem for sure. The law says nothing about team boundaries: it talks about communication pathways.

The paranoid socialist in me thinks big companies like team-sized microservices because it lets them prevent workers from talking to each other without completely ruling out producing running software.

When companies instead encourage forums for communication across team boundaries, it unlocks completely different architectural patterns.

[bunderbunder]

If team boundaries aren't a major influence on your communication pathways, what on earth do you even mean by "team"?

[roguecoder]

The most common alternative to organizing teams by service boundaries is to organize teams around the business problems to be solved. That is a lot easier to budget for than trying to staff by microservice boundary, doesn't have the coordination and planning overhead, and it means you aren't reliant on up-front planning to get to a functional solution or design.

In high-uncertainty greenfield development, Explore projects or Lean Startup-style experimentation, having developer be close to the users they are serving is very efficient.

It also lets those companies reteam frequently, without needing to change the software to match the new team boundaries, which is very helpful when growing the team.