The plan that came to mind would have the following stages:

1. Deploy components - Deploy the component library in as many apps as we can, and replace existing components with the new ones.
2. Design System as a Highway - The library and implementations would function like an interstate highway where any component that needed to live in multiple apps would benefit from starting on our infrastructure. A nice selling point for a micro-frontend architecture
3. Tastefully grow the library - not everything could be a component. We started with form inputs and some display elements (labels, errors, flash) and avoided anything that was too context-specific in the beginning.
4. Semi-weekly chats - we were building something that in the absence of input would not get adopted. We instead leaned in on knowing this, and to reduce any anxiety around the components built, we had regular feedback meetings.
5. Market it - We took any opportunity to mention the components as a solution or show new ones as a demo. Whether in meetings or on Slack channels, we were doing what the previous libraries had not done before.

At this time we had a storybook-like page with documentation, comments in the code, and examples in the wild. There was one more thing that was missing.

The developers needed to know how we went about our process, not just what the output was; how we came up with the components, where everything fit in. Halloween was coming up, and the idea of an open house came about. We would show the developers, our internal process and why we where excited to build this.

It was a success and led to teams consulting with us whether we had a component available for something they were working on. When we didn't, and it fit the criteria of a reusable component, we would have one availble pretty quickly, to create rapport.

We became the go-to place for developers who had UI requests, for cross-app components, and ideas to add a feature with a reusable component. If it didn't exist, we could build it, deploy across apps and let the developer work on server-side solutions. Turnarounds became quick, and we saw developers use the components with confidence. Our work got a shout out from the business stakeholders a few times, as the apps looked and felt consistent in their demos!