Team Structure

[00:00:00]
>> So are three different team structures that ideally would work. The first is a centralized model, so this is where you have one core team building the design system. It's their full-time job, they build it, they have complete veto power over the system. So if someone comes in and they say, hey, I would like this component.

[00:00:16]
They can say, yeah, let's do it, or they can say, no, we're not doing this. So that's their full-time job, and then the product teams would simply consume that. The second is a distributed model. This is very popular for companies who can't afford to put full-time talent on building a design system.

[00:00:33]
And so this is where the product teams who are consuming the system are also building it. This is really great in the sense that it gives the teams a sense of ownership. People are really excited about stuff when they're the ones building it. It's also influenced by many vantage points, which is really great.

[00:00:50]
Innovation is a great thing, and diversity is a great thing. And then lastly, less downtime. So if we have two developers on vacation, the system can still evolve because we have lots of contributors. And the hybrid model is a hybrid, it combines both of these ideas. Where you have a core centralized team who is responsible for kinda driving the system as a whole.

[00:01:11]
But they still accept contributions from the larger ecosystem. I'm gonna say ecosystem, I mean internal ecosystem. So generally, you wouldn't just open source your your system in general, and get community contributions. But when I say open source, I mean internally to your company.