I've worked at both Microsoft and Amazon, and they have opposite strategies for integrating large code bases. Microsoft prefers putting everything into one giant project and having different teams touch different parts of it (there are lots of advantages in this, incidentally, especially in terms of servicing). Amazon goes the opposite way, by essentially using package management to keep track of and manage dependencies between a huge number of smaller projects. Amazon's solution works well for them, partly because it matches their service oriented architecture. But at the same time, it's the only thing of its sort I've ever seen that was actually built to a sufficient level of quality. And it represents a tremendous investment of dev work over a more than a decade.
Microsoft is capable of doing that kind of work (and they sort of are with some of the azure stuff they're working on) but it's a non-trivial project that requires a tremendous amount of investment of time and resources. And that's just to get to square one, let alone something that is competitive with their other infrastructure (keep in mind that microsoft also has tremendous investments in build and CI infrastructure). That's a very hard sell, especially from a risk management perspective.
In Microsoft, it really depends on which org you're in, and which product you're working on. Older codebases (Windows, Office) tend to be monorepos. Newer ones are generally less so. And some of the older ones have been migrating slowly via componentization (VS).
Microsoft is capable of doing that kind of work (and they sort of are with some of the azure stuff they're working on) but it's a non-trivial project that requires a tremendous amount of investment of time and resources. And that's just to get to square one, let alone something that is competitive with their other infrastructure (keep in mind that microsoft also has tremendous investments in build and CI infrastructure). That's a very hard sell, especially from a risk management perspective.