> Microservices was always a solution to the organisational problem of getting more developers working on a system at once
In other words, it's a great way to ship your org chart.
I've only ever seen a handful of examples where the microservice boundaries were set regardless on how the actual teams are organized in the reporting structure.
You'll ship your org chart whether you try to or not. There are two questions: a) will you architect your software to make this process (relatively) efficient? and b) to what degree are you willing to change your org chat to improve your architectural boundaries?
I think one can control the degree to which software architecture reflects the org chart. To take an extreme example, Chrome is primarily a single, giant (~200 MB) binary. I'm sure the layout of the source repositories reflects the Chrome org chart. But thankfully, they always had the engineering discipline to produce the architecture that was best for performance (a monolith, albeit a multi-process one) without letting it get out of control.
In other words, it's a great way to ship your org chart.
I've only ever seen a handful of examples where the microservice boundaries were set regardless on how the actual teams are organized in the reporting structure.