I had an interesting talk about software architecture the other day and noted that the term "dependency" is used for very similar things that happen at different levels.
For instance a "dependency" exists in project planning in that some tasks require others to be completed; thus over time scales of weeks and months that kind of dependency has to be managed.
Then at runtime a framework like Spring "resolves dependencies" to initialize objects. You could look at it as a backwards or forwards chaining problem, but either way it knows that "A depends on B" so it initializes B first. A and B are software objects instances in this case. The timescale is usually less than a second here.
Then there is the dependency resolution done by Maven at build time, which might take a few minutes. There A and B are software packages that mainly contain software object definitions.
These different levels of dependency are somewhat but not perfectly parallel to each other -- e.g. the Conway's law that you mention.
Aside from that I think you have to be aggressive about managing the "little things". If you go full polyglot and
let coders pick any version of any language that they want you are not going to realize the productivity and quality gains that you can get from microservices. For instance years ago we had a JDK 7 client and JDK 6 server and found that a set of JAXB classes we made weren't portable. It took us a few days to understand the problem, but it would have taken many more days to convince management that if they want ultra-fast software development we have to have less problems like that.
You have to standardize as much as you can about build process and libraries that people use. I've found that this kind of functionality frequently gets re-developed:
https://www.envoyproxy.io/
If you can standardize on a limited selection of "middleware" you may come out ahead with microservices, but having five different ways to do the same thing will end in tears.
