[hmeh]

If you don't disagree, then I assume you have a strong understanding of structural design. I assume that you recognize that Conway's law is more of a curse, and a warning than it is something to embrace. I assume that you recognize that the only possible way to "embrace conway's law" and simultaneously recognize structural design would be to constantly be firing or otherwise disbanding entire teams as components get completed (components that likely won't need to be touched frequently because they were designed for a single reason to change). I assume all of that makes perfect sense to you. Yes?

[guhcampos]

No, not at all. I see why you think of it as a curse, I don't enjoy it as a resulta, but it's an observation of a pervasive pattern, not a design decision. It emerges from the way humans communicate and organize themselves.

You can either fight it agressivelly and try to minimize it, or you can "embrqce" it and try to adapt. I could force it into a disability analogy:

if you become suddenly deaf, you can agressivelly try to reverse it by all medical means possible, and you might succeed. Or you might not, then it would be better for you to accept the fact you are deaf and design your life around this disability as a means to adapt yourself to it.

That's how I see microsservices, too: accepting that large enough organizations cannot communicate as effectivelly and efficiently as small ones, therefore designing systems to minimize the impacts of these communication failures.

[hmeh]

The difference, though, is that microservices was more about the focus on the micro. That was, small things. Not per-team things. It was about trying to break things down into the smallest possible piece (while simultaneously ignoring software design IMO). A single team could end up with 5 microservices. A single microservice may not need to be touched after it's deployed. It's true that this can facilitate multiple teams, and you say this when people emphasized the technology soup approach to microservices: finally, you can combine Go, Rust, Java, Ruby, TypeScript, and even COBOL!

By the way, the entire premise that you should organize your software based on the way teams are organized is the flawed thing. Natural designs emerge when designing software. If you must have multiple teams, it may make sense to distribute some of those partitions that emerge across those teams. Or it may not. What absolutely does not make sense is creating partitions to account for your multiple teams. That's design-by-making-stuff-up and it's as doomed to failure as the REST-based-microservices fad.