They don't cancel each other out exactly though, so some things are way easier (spinning up a huge computation), while some things are way harder (making a small change to shared components).
Working on shared code is so easy at Google because they have a fantastic cross-referenced code browser and search engine, ways to inspect production jobs and configs that anyone can access, and everything is open and visible.
By contrast the other large publicly-traded cloud company where I now work has the opposite culture: no code search worth using, “why are you touching my project?” culture, not enough tests to give anyone confidence in a change. The polar opposite of Google.
I believe when he said "organizational efficiency" he was not referring to technical inefficiencies, but rather chain of command, how organizations are structured, etc.
Not at Google, but that is the case in my company as well. In most of the company, doing extremely great technical work is not going to get you far.
I am guessing that your changes did not change the semantic behavior of other people's code. e.g. you were replacing one hash-map implementation with a more efficient one. That's something where obviously Google's tools do cancel out the inherent inefficiency of large organizations/code bases.
My point was that Google has the level of efficiency of a small organization, despite being a large organization. That the default for big organizations is to "just suck" as you described, makes this remarkable, but I never felt like this resulted in a superhuman level of productivity that you might expect considering how advanced the tools are.
Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need.
The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.
Often it's better to introduce a new function and migrate usages to it across multiple commits.
Either way, it's on you to fix everyone else's code, which is a different mindset from releasing a library and letting downstream users do the migration themselves when they feel like it.