It is really difficult to do, a few thoughts from previous places I've worked at...
I don't know anything about your technical stack, but I'm going to assume they're all solved for. The easiest is if your codebase is all in a monorepo and all uses the same stack.
It gets a lot harder if you have lots of projects, and you have to build a library that all the other teams have to import.
One way to make this easier, is to make your component library code public, so that a whole class of permissions based issues are avoided.
The rest of the problems, I think are cutural, not technical.
Find an "anchor tenant", that is a fairly big team that own an important product, get that team on board and build something for them. Having a big, high profile team use your library will give smaller teams the confidence to use your library. This is basically using conway's law to your advantage.
Geography plays an interesting role, a place I worked at had 2 major engineering offices in different cities. Each office had developed its own framework, and teams used the framework in the city that they were based in.
Graduates played a valuable role, our grads rotated teams every 6 months for 2 years. They played a huge role in encouraging adoption of libraries, as they'd take learned knowledge from one team to another.
I don't know anything about your technical stack, but I'm going to assume they're all solved for. The easiest is if your codebase is all in a monorepo and all uses the same stack.
It gets a lot harder if you have lots of projects, and you have to build a library that all the other teams have to import.
One way to make this easier, is to make your component library code public, so that a whole class of permissions based issues are avoided.
The rest of the problems, I think are cutural, not technical.
Find an "anchor tenant", that is a fairly big team that own an important product, get that team on board and build something for them. Having a big, high profile team use your library will give smaller teams the confidence to use your library. This is basically using conway's law to your advantage.
Geography plays an interesting role, a place I worked at had 2 major engineering offices in different cities. Each office had developed its own framework, and teams used the framework in the city that they were based in.
Graduates played a valuable role, our grads rotated teams every 6 months for 2 years. They played a huge role in encouraging adoption of libraries, as they'd take learned knowledge from one team to another.