If a library update requires all teams using the library to start using the new version simultaneously, then you're pretty tightly coupled. Not a good thing.

If a library update requires all teams using the library to start using the new version simultaneously, then you're pretty tightly coupled. Not a good thing. But if different services can interoperate while running different versions of the library, then it's less challenging. Combine that with a reasonable deprecation schedule on old versions of the library and let teams upgrade when they're ready. Now you have the best of both worlds - a library that keeps moving forward with a known window (per the deprecation schedule) when they can completely drop old functionality, all while other teams are happily using the library. Ofcourse, a number of things needed to pull this off: * independent deployments so services don't automatically share the same library versions * communication tools so library owners can publish a deprecation schedule and the right people are notified effectively * verification mechanisms so library owners can make sure everybody has upgraded before pushing out breaking changes