I work at a very large company where each team builds and deploys its own production artifacts, but we always build everything off of head rather than choosing versions of each dependency and upgrading on our own schedule. The choose-your-own-adventure approach seems like it might be nice until you write (e.g) a critical security patch and you have to go nag N teams to upgrade their version of your library. With our system it goes out in everyone's daily or weekly release.

The system only works because of very good integration testing infrastructure and a culture of being able to roll back almost any change that broke you.

Absolutely, "go nag N teams" is a huge problem in a microservices environment. It's mitigated somewhat by building all the services from a monorepo.

That makes sense.

If for some reason the more traditional versioned release dependency approach made more sense for other reasons (as the GP suggested they were using it) -- it shouldn't be too hard to write automated tooling to go tell everyone to upgrade for a security release, or even make PR's dependabot-style; if an org already has "very good integration testing infrastructure", adding that tooling for security updates of dependencies is perhaps within the capacities.