For a long time, I've believed that successful design systems are built by separate DS teams, not a hodgepodge of volunteers straddling multiple projects.

🧵 A major reason design systems need dedicated resources is because I think it's almost impossible to get component and tooling APIs right without dogfooding.

I think that a design system is more about applying constraints and processes to the design and development project than it is about outputs and artifacts. But that doesn't mean those outputs aren't important, or that there aren't certain artifacts that design systems tend to create.

I've got my ☕ and it's a beautiful morning. Let's talk about how to actually hire the first two engineers for your #designsystems team.

https://twitter.com/MCapoz/status/1357343660472377348

As a reminder, the two types of engineers I'd hire are:

1. A senior frontend engineer who has focused on design systems before
2. A senior frontend infrastructure engineer

Yesterday, I tweeted about the two first eng hires I would make if I were starting a new #designsystems team.

Today, I want to dive deeper into the type of work each of those engineers does, and how to discover what kind of eng you're talking to in an interview.

https://twitter.com/MCapoz/status/1356982047085101061

The two types of engineers are:

1. A senior engineer who specializes in CSS, component architecture, and design tokens.

2. A senior "frontend infrastructure" engineer, who specializes in versioning and publishing, bundlers, and automation.