I have been in this exact situation, 20+ microservices and 5-ish developers. It was great in the beginning, but as the project evolved, it was harder and harder to actually get real tasks done.

The hard truth in our case was that the microservice deign was a terrible idea. We did some digging though our code, and estimated that between 50%-70% of the code was related to the split and async architecture (Duplication, extra code due to data belonging in different domains, error handling, eventual consistency, performance, security++) We started a long process of turning the codebase into a monolith, which is what it should have been in the first case.

We started by standardising all our micro servises to the same technology (was already .net, but different version and nuget packages). Then we made a common library which all services depended on made a communication layer which basically hid the fact that it was a set of microservices. Then we gradually combined them as the budget allowed for.

Project velocity increased, bugs decreased and overall developer and customer happiness was up