Culture is a funny thing. We know what a bad one is when we experience it—and we know we want to work in a great one. But even this is subjective: One company culture can be inspiring for some and boring for others; a place of growth for some, stifling for others. And changing culture? File that under “M” for magic. At least, that’s often what it feels like.
For the last two years, I’ve been researching how an organization’s culture is linked to the success and failure of the design systems we know can be so impactful. It all starts with an understanding of the company culture where you work.
Types of Company Cultures
There has been a lot of research done on company culture. For decades, people have been trying to identify a universal cultural model that can be applied to any organization. The one that makes the most sense to me was developed by Kim Cameron and Robert Quinn back in 1999. In their work, they plot two opposing value sets on an X and Y axis offering four quadrants we can use to quickly assess a company’s culture.
From a high level, the x-axis ranges from internally oriented (the organization is focused on itself and its people) to externally oriented (the organization is driven by changes external to itself like the market or industry). The y-axis ranges from focused (the organization is opposed to change and relies on their traditions) to flexible (the organization is open to change and adaptation). Every organization has some of each of these characteristics, but they often lean heavily into one or two.
Two Primary Approaches to Design System Team Culture
Culture is formed any place where people regularly interact. That means that every team inside your company has its own subculture. Every committee, every book club, every squad. People make culture wherever they go. In the context of design systems, that means your system will also have its own subculture.
While it’s possible for a design system team to have any of these cultures, I’ve found that most design system teams operate on the internal orientation side of this model. This makes sense since most of the time design systems are for internal use—they’re an internal offering and enable product teams to work more consistently and efficiently. So that means most of the design system teams I’ve talked to have either had a collaborative or a controlling culture.
Collaborative Design System Culture
A collaborative design system culture (top left quadrant) is collaborative in nature and values doing things together. These teams often play a role in the onboarding of new product designers, developers, managers, etc. and have sophisticated mentoring programs and healthy models of contribution and governance. They are often led by people who believe the scope of their work can only be accomplished by partnering with feature and product teams across the company who believe in the vision the design system offers.
A cross-team collaboration means the systems they build are broad in their offerings and often highly flexible. These teams are trying to create design systems that will be seen as enabling instead of restrictive. With this approach, the design system team trusts in the strength of their collaborative culture (rather than procedures and policies) to create consistent output. It’s not that they don’t define processes for working together, it’s that those processes emerge in more organic ways.
Controlling Design System Culture
A controlling design system culture (lower left quadrant) is controlling in nature and values doing things right. These teams are focused on incremental improvements. These design systems are often initiated because of wildly inconsistent customer-facing products. Sometimes these are organizations that have grown by acquiring other companies and they have found the variety of processes, skill sets, and digital interfaces they are now responsible for need to be brought under control.
The underlying desire to streamline means the resulting systems are often less flexible, offering intentionally limited interface options for their subscribers. These teams tend to be very proactive in defining processes. These processes, however, are intended to keep people in check rather than facilitate collaboration. A controlling design system subculture attempts to reinforce organizational culture—and maybe even make up for its shortcomings—through hierarchy and process.
These teams take an education-heavy approach to interacting with subscriber teams, choosing less engagement with them as customers of the system. And there is often less contribution from those outside the core team, sometimes leading to a large, fully dedicated design system team.
Healthy and Unhealthy Characteristics of the Two Cultures
It is important to note that neither of these two primary design system team cultures is right or wrong. I’ve spoken to teams from both—some are doing very well and some are struggling. There is no correlation, that I’ve seen, between the success of a system and whether its culture is collaborative or controlling.
However, it’s important to recognize that there are healthy and unhealthy versions of each. In order to illustrate that, let’s look at culture as a spectrum using three characteristics of design system work: prioritization, adoption, and extension.
Cultural Characteristic: Prioritization
In a healthy collaborative culture, the design system team will often prioritize based on the needs of their subscribers. The collaborative culture approaches prioritization with a mindset similar to other early-stage product creation efforts—they learn from their users. In the case of a design system, those users are future subscribers. Interviews, observation, brainstorming, and prioritization sessions: all of these techniques (and many more) are a common part of the process for anyone building a design system in a collaborative way.
If you take prioritization in a collaborative culture too far, an unhealthy version emerges. In this situation, the design system team will try to serve everyone perfectly and in doing so will end up serving nobody well.
In a healthy controlling culture, the design system team will often prioritize based on the needs of the organization. The controlling culture approaches prioritization with higher-level business goals in mind. It’s not that they won’t perform interviews, observation, etc., but when it comes to decisions about what makes the cut, the hierarchy takes over. This means that organizational business goals will play a major factor through each level of that hierarchy, right down to design system decisions.
Yet, if you take prioritization in a controlling culture too far, an unhealthy version also emerges. In this case, it’s the absolute disregard for subscriber input. Because of this, the system will often struggle to meet the needs of the subscribers in a meaningful way and create challenges for adoption.
Cultural Characteristic: Adoption
In a healthy collaborative design system culture, adoption is often driven by relationships. When a system is relationship-driven, there’s a lot of responsibility on the design system team to connect with each subscriber. The good news is that establishing a relationship lays the groundwork for future collaboration. The challenge is the scale at which the system team can encourage and support the many teams onboarding to the system at any given time.
The unhealthy collaborative version of adoption results in an unsustainable over-support of subscribers through the adoption process. Sometimes design system teams feel the need to do the work for a subscriber, which can result in burnout and is not sustainable for a system long-term.
In healthy controlling design system culture, adoption is often driven by incentives. In a controlling design system culture, teams will go to the directors of the desired subscriber teams to establish OKRs or KPIs intended to incentivize the subscriber groups to adopt the system. This is excellent at reaching many of those potential subscribers quickly by using the established hierarchy to do so. It can feel impersonal but can work well if the system onboarding process is well-defined and well-documented.
When taken to an extreme, however, the unhealthy controlling design system culture pushes adoption toward an unsustainable lack of support for those becoming subscribers. This results in a great amount of frustration for the new subscriber teams and a feeling that the design system team is not capable of establishing long-term, sustainable processes.
Cultural Characteristic: Extension
In a healthy collaborative design system culture, extension is often encouraged. A team operating in a collaborative design system culture will often think of their job as building an intentionally flexible system. These teams recognize that whatever tools, components, or patterns they offer to the product teams in their company, they can’t possibly solve every problem for those subscribers. They see the system as the starting point—a place to get trustworthy defaults—but understand it must offer the flexibility for product teams to extend into areas the system team hasn’t accounted for.
When taken too far, an unhealthy collaborative design system culture can lead to subscriber teams abusing the flexibility offered. In this situation, subscribers default to modifying assets and components rather than looking to see if the system can solve their problem in another way. Over time, this can become wildly unsustainable.
In a healthy controlling design system culture, extension is often discouraged. A team operating in a controlling design system culture is on a mission to reign in variety. Because of this, they recognize the need for their systems to be necessarily restrictive. Sometimes this is a result of the way the product teams are staffed—a team without deep expertise in UX, UI, design, or frontend development skills. Other times, this is because of the amount of inconsistency already present in the products offered by the organization. The controlling culture’s default response to subscribers who wish to extend the system is often, “Use what we have.”
When taken too far, an unhealthy controlling design system culture may forbid extension of any kind. In situations like this, subscriber teams will often stop using the system completely rather than use an inflexible tool.
Design System Cultures are Always Subcultures
A design system team’s culture does not live in a vacuum. These teams are subcultures of the organizations where they are housed, and this can create some very specific challenges if not recognized. In fact, the success of a design system team is not tied only to the kind of culture they have. Instead, it’s about the design system subculture in relation to the organization’s culture.
Every design system team exists inside an organization with its own culture and that company culture could easily be any of the four in this model. The technical and creative work of design systems is certainly challenging, but in my observations, the most difficulty arises when the subculture of the design system team clashes with the culture of the organization in which it lives. This is like trying to swim upstream.
Pairing Cultures
The easiest way to alleviate these clashes is to swim with the current. In other words, a subculture that is the same as its parent culture is going to have fewer obstacles than one that is in opposition to it.
This is great if your company culture is on the left side, where design system cultures tend to exist. But what if it’s not? The most strain arises when your design system culture is diagonal from your company culture.
For example, if your company has a compete culture then it will be very hard to build a design system with a collaborate culture. The clash here is between speed and collaboration, between short-term wins and long-term strategy. There is nothing inherently wrong with a competitive market culture, it’s just difficult for a collaborative subculture to survive when more competitive characteristics are prioritized.
Instead, consider a more controlling design system subculture which is compatible with that competitive organizational culture. That’s because it removes the back-and-forth of collaboration from the equation and allows the team to deliver fast—which is what’s valued in the compete culture.
Likewise, if your company has a create culture, then it will be very difficult to build a design system with a control culture. In this scenario, the clash stems from the underlying belief that there is a right way to do everything (control culture) and the belief that we should disrupt the old ways (create culture). These two ideals are in direct opposition to each other, making it challenging for a system to thrive when they are at odds.
Instead, consider a more collaborative design system subculture which is compatible with that creative organizational culture. That’s because of the flexibility a collaborative approach offers which is needed in order to support the process of finding the market fit for a product. A more rigid approach won’t allow for the pivots common in those disruptive (creative) companies.
Real Impact
The way Sparkbox is able to make the most impact is to pair our experts with client teams building and subscribing to a design system. Because we’ve taken the time to research the impact of organizational culture on design system work, our team understands how to adjust the ways we work to better align with that culture. It’s hard to teach this. Instead, we demonstrate it in our day-to-day work alongside these teams.
Teams big and small have been building consistent and cohesive products very efficiently for decades, without a design system. I believe a mature and healthy system can scale existing work at any organization (including very large ones) beautifully, and it provides a fantastic path for the kind of efficient and cohesive work we all aspire to. But there’s so much more to a design system than just the technical and creative side. The work of a design system team is cultural. Until we recognize this and incorporate it into our approaches, we won’t be able to fully understand the breakdowns in our design systems. This idea—how culture and systems are inextricably linked—will give you a model for understanding what’s happening below the surface of your system program. I hope you find it truly impactful.
