Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams which works with only a fraction of the effort. In case
the group of people accessing a common library is small (5 to 6 persons at most)
you have shared code ownership for the team
you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used
then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic rules:
"small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.
ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics
if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need
more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.
The larger the team gets which works with these inhouse libs, the more management effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "commom library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.