Collaborative vs. Controlling

[00:00:00]
>> For the past year, a lot of the interviews that I've done have been focused on that. And what I've learned is that almost every single design system subculture that I've been able to talk with, has identified one of the left side, right? One of the left side, they're internally oriented.

[00:00:17]
And that's that makes sense when you think about it, right, because the design system is an internal thing, right? It's most of the time, not always, but most of the time, it's something we use internally, so we make decisions here internally, right? We're thinking about the impact that has on our organization, not the market.

[00:00:35]
So that means most design systems subcultures are either collaborative or control. That first type, the designs of the design system subcultures falls into that top left which we called collaborative. They're also focused on the long-term success of the system and the company. I hear them say things kind of like this.

[00:00:59]
I believe the scope of my work cannot be accomplished in any way other than to partner with teams who have caught this vision. Okay, so that's kind of one mentality that I hear from a design system lead. And that cross-team collaborative perspective means the systems they build tend to be enabling instead of restrictive.

[00:01:19]
And the other type, the other primary type of design system culture is found in that lower left quadrant. And we know they value doing things right, they're focused on incremental improvements over time. And these cultures are driven by inconsistency in their products many times. So, here's the kind of things that I might hear them say.

[00:01:39]
My product team's having created consistency, so I'm here to make sure that they do, [LAUGH] right? So, it's a very different perspective, right? And neither of these is actually right, neither of these is wrong, they're just different, but there are healthy and unhealthy versions of each. So the spectrum from collaborative to controlling along that left side, I've turned it on its side here.

[00:02:04]
But that helps us understand how these two cultural types can sort of identify what's really healthy behavior, and at the extreme ends of this is where we find unhealthy behaviors. So let's take a look at just a few characteristics of design system teams, and I'll show you how they fall either into the healthy or unhealthy spectrum.

[00:02:26]
And you can follow along with this and imagine how is it that your system team is operating and see sort of where you fit here. So let's start with the idea of prioritization. So in other words, just like how does your design system team make decisions about what to prioritize in the system itself?

[00:02:50]
Well, on the healthy collaborative quadrant, what we find is that they are primarily basing their prioritization on the needs of their subscribers, right? So this is what we've talked about with engaging. They're getting to know those folks, they're learning from them, and they're making decisions about what should go into the system based on the needs of those subscribers.

[00:03:09]
Primarily, on the controlling side, it's more about leadership, right? So this is based on the organizational needs. So maybe they're being told like, hey, look, we gotta address these problems, so now that is filtering into their decision making. They're saying the organization needs this, I'm gonna mostly make my priority decisions based on that bigger picture need rather than on the needs of individual independent subscribers.

[00:03:34]
Now you can take either of these things too far. So on the collaborative side if we go too far, that's where you're trying to prioritize everybody's needs, right, that means you're gonna serve nobody. Well, it's impossible to do that. And the opposite is true on the unhealthy side of control.

[00:03:51]
This is where you're ignoring input from your subscribers, and you're also gonna serve nobody well, because you're essentially guessing at what you're building, right? So those two extreme ends represent the unhealthy versions of a collaborative and a controlling subculture. So let's look at another characteristic. Let's talk about adoption.

[00:04:12]
We spent a lot of time talking about how we can define adoption groups, established the adoption path, the metrics, all of that stuff. But let's think a little bit about how do we drive adoption of a design system? So on the healthy collaborative side, we see this primarily driven by relationship.

[00:04:33]
In other words, you're getting to know the people, the people that you want to use the system, and you sit down with them, and you may be having a cup of coffee, and you're just talking them through what it's gonna be like. It's really like we do this together.

[00:04:44]
On the controlling side, it's primarily driven by incentive. And what I mean by that is the design system team is often talking to the bosses of the people that want to use the system and they say, let's make this part of their goals, right? So now we say, hey, if you want to do well as your job, as a product designer, you need to be using the design system, right?

[00:05:03]
That's top-down saying this is incentive driven. Now we can take either of these too far again. So on the adoption side, an unhealthy characteristic for adoption on the collaborative side is that it's unsustainable over support through the adoption process. This is interesting, it's like what I think I'm getting at here is that you can't do it for them.

[00:05:29]
This is kind of the whole teach somebody to fish versus giving them a fish or whatever. All we're trying to do here is establish how we will interact with each other from this point forward. So if you come in right away, and you just do it for them, you're setting their expectations for what it's gonna be like to work with your design system team from that point forward.

[00:05:49]
And that's not sustainable. [LAUGH] So what you need to do is balance that, right? You can be driven by relationship, but they still have to do some of that work themselves. And the opposite side, we can have an unhealthy version of adaption control where it's non-support, right? So essentially, we're saying, look, all the information you need is in the doc site, go figure it out, right, also not healthy.

[00:06:12]
[LAUGH] So we need to balance these things, right? We got to come in from those extremes to find the healthy part of the spectrum. So another characteristic we could consider is the idea of extension. And when I say that, what I mean is the system's not gonna do everything perfectly.

[00:06:26]
So when a subscriber gets, maybe they're pulling in a new component and they recognize it actually needs to do something a little bit beyond what you do. So they're gonna extend it in some way, they're gonna make a change to the system. So how are they supposed to proceed?

[00:06:40]
So on the healthy collaborative side, there's an intentional flexibility kinda built into the system, right, extension of the system is encouraged. In fact, we've documented how that should happen, and we have processes for bringing that work back in, perhaps. On the healthy control side, it's necessarily restrictive. In other words, extension of the system is discouraged, right?

[00:07:05]
So we're saying what we need from you is to use the system. If there's something you really needed to do that it doesn't, come talk to us and we'll make a plan. We'll create an exception for you, but the hope is that you can use what's there. The very different perspectives, both of those can be healthy, right?

[00:07:23]
If we take the collaborative too far, we get this extreme flexibility, right, where extension of the system is overused, and teams are just pulling stuff in and changing it without thinking about the implications of that. And on the opposite side, an extreme restriction where it's literally just forbidden, you cannot do it, period.

[00:07:41]
Figure out how to do this. So again, those extreme ends are unhealthy, but there is a healthy balance in the center here. And we'll just discuss one more characteristic which is just change management. So it's like we're asking folks to make a lot of changes over time, and so how do you navigate that change is kind of what we're getting at here.

[00:08:07]
So on the healthy collaborative side, if the system is primarily is adapting to the workflows of your subscribers, that can be okay, right? You're driving a lot of your decisions here, you're primarily thinking about the workflows that they need, making it simple for them to make that shift, that change.

[00:08:23]
On the control side, your subscribers are being asked to adapt to the approach of the system. So it's a little bit more restrictive and it's saying this is the way we want to work. We're looking for less autonomy in our product teams, and instead, we want to encourage more consistency in our behaviors, right?

[00:08:39]
Both of those can be healthy. On the extreme ends, of course, you can have, too much accommodation for subscriber workflows, which leads you to this decision paralysis. We can't get anything launched because we're trying to plan for everybody here. I don't wanna make it hard for anyone, it's just a really tricky situation.

[00:08:59]
The unhealthy control is where we just have, again, zero lack of accommodation for the subscriber workflows. Which honestly means they just don't wanna use it and it requires you to end up reworking a lot of what you do. [LAUGH] So again, what we're looking for is the balance, right?

[00:09:15]
So the competing values framework is nice because it gives us an overview of the kinds of organizational cultures that we can expect to see. And we know now that most of our design system teams fall on that left side, so they're internally oriented.