Two things here. One is that it often looks like the tail wagging the dog. Microservices are often introduced to manage and support development teams that grew too large. Unfortunately the correct course of action in such cases is layoffs not microservices.
Two. In my experience the places I worked at where microservices were extensively used had even more issues of employees stepping on each other as compatibility issues and upgrade sequence between services were a frequent concern and the independent testing was a total myth as most teams did not provide good mocks for their API surfaces. Meanwhile troubleshooting such distributed systems was _very_ real and very hard.
As for the second: yes, you can mess it up, a solution like that requires both discipline and someone in charge of architecture with the power to enforce the rules. If everybody runs off to create their own little kingdom and APIs then it's just going to make matters worse. Sometimes much worse.
But here is an idea: if you run a typical web company you already have a couple of ways in which you can slice up your monolith:
The hot path, all that which is visible to the unwashed masses and the internal software that your various employees use to deal with order flow, support requests and so on (assuming that you built those rather than bought them, as you probably should have).
The part that is visible to everybody on the web can in turn be split up into content delivery, pages that are visible to non-logged in users and pages that are visible to users. Possibly you have a mobile phone application. Maybe your back-end has certain features that can be easily parted out and made to operate stand alone. Before long you'll have somewhere between 5 and 10 cleanly separated chunks, each of which can be worked on in isolation because the only thing all these have in common is the persistence layer, which can serve as a single source of truth. Everything else can be made as stateless as possible.
Such a solution would serve the vast bulk of the e-commerce and SPA solutions out there and would scale to very large size without breaking a sweat. Then, if it becomes necessary to break things up further this should be done with the realization that those parts will need to continue to function as a whole and that architecture will have to take a front seat if it is to work at all, which means the company will have to hire a capable systems architect who can balance the extra complexity with the flexibility required. This is not a trivial thing to do and messing it up will come with a hefty price tag.
If your team was bad at systems architecture before attempting such a project then they will do much worse than before. But this is akin to saying that cooks should not use sharp knives because they can cut themselves. Yes they can. But expert cooks would much rather use sharp knives than blunt ones even if they run the risk of cutting themselves.
A team of also-rans that go for a services oriented solution in a cargo cult fashion is going to get bogged down by complexity. That's no change from them getting bogged down by using a monolith that turned into a bowl of spaghetti.
I've seen microservices applied in ways that made my hair stand on end, every shitty little function was its own service and had its own API. Utter madness. But I've also seen a monolith with several major functional blocks cut up on sensible lines and then dealt with by a much larger number of teams than before with success. Like everything else: if you are doing it wrong no amount of magic is going to help you, you first need to know what it is that you are doing.
My best advice if this sounds familiar is that you should up the hiring bar, considerably so. But that will also require paying more per person and companies that have a problem with the former usually also have a problem with the latter.
Unfortunately “beginner experts” tends to pick the most complex tool possible to solve a problem, because they think it somehow demonstrate how skilled/smart they are. Which always amuses the more experienced developers. It’s like watching a train wreck in slow motion :)
I am looking forward to reading the future “we picked microservices because we thought we were clever and it turned into a cluster f*” stories.
The whole idea that you take a monolith and then explode it into 50 or even 100 pieces with all the added complexity that involves without thinking about it beforehand and aiming for specific goals is obviously broken and that's not what I'm advocating for. But when properly used you can design your services in such a way that those problems do not arise. Some eco-systems, notably Erlang have elevated this concept to first class status and from personal experience and looking at some companies that did it properly I can tell you that it works, and that it works very well.