December 10, 2023

How Much of a Rule Breaker are You?

The Question: Episode 5 Wrap-up

On Thursday, December 7 of 2023 we held the Episode 5 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.

Review the FigJam file and the raw data from the Episode 5 deep dive. Major thanks to my friend and design system leader, Dan Mall, for co hosting this deep dive!

For the week’s question, I provided this context:

This week, we’re investigating a pattern that our friend Dan Mall recognized in some of his conversations: How much of a rascal are you?

In his article, Dan shares this advice:

“…how do you change something if you don’t have the approval to do it? Do it anyway, but don’t tell anyone you’re doing it. Only share the results when your work is done.”

The first part of this week’s question is about whether you agree or not. The second part is a collection of your stories supporting your choice. :)

Let’s dive in!

Is it ok to break your organization’s existing rules and policies in an attempt to establish a design system?

Based on your previous answer, tell me a story about a time on your design system journey when you made the choice to either break your organization’s existing rules or to honor those existing rules—and then tell me what happened.

The Question was shared via email (to 183 people), on LinkedIn, and X and I received 40 responses this week.

The Answers

In answer to the first question, most folks responded that they were willing to break the rules:

In response to the question, “Is it ok to break your organization's existing rules and policies in an attempt to establish a design system?”: a large majority of respondents said yes.

Although there is a lot of nuance in this question (as many folks pointed out), I wanted to force respondents to make a choice to see which side of this complex question people landed on. Despite many “yes” answers, there was also a healthy recognition this is not a binary topic. If I had offered a third answer of “It Depends”, we can safely assume a large number of folks would have chosen this option.

In the second question, I asked people to share a story related to their yes or no answer. There are some great ones—people took the time to share very valid reasoning and explanations of their stories. If you have a moment to review the raw data, it’s absolutely worth a read.

As part of my synthesis, I asked ChatGPT to provide an overview and summary of the stories shared by those that answered “yes”. Here’s what it offered:

The patterns in these stories suggest a few recurring themes:

1. Necessity-driven Rule Breaking: Often, breaking rules is a response to a necessity or a need to drive progress. Whether it’s a lack of resources, rigid policies, or cultural barriers, these individuals faced situations where adhering strictly to established rules hindered progress.

2. Autonomy and Initiative: People taking the initiative and pushing boundaries within their organizations played a significant role. They saw the potential for improvement, took charge, and initiated changes despite organizational resistance.

3. Advocacy and Collaboration: Collaboration and advocacy were key strategies. Some individuals worked to build alliances, others collaborated across teams, and a few went ahead with changes, subsequently showcasing the results to gain support or forgiveness.

4. Incremental Steps and Tangible Results: Many stories involve taking small, incremental steps or showing tangible results before asking for forgiveness. This approach helped demonstrate the value and potential of the changes made.

5. Cultural Shifts and Change Management: Some stories focus on changing ingrained cultural norms, be it the separation of teams, tooling preferences, or siloed workflows. Breaking rules here meant challenging long-held beliefs or practices to pave the way for a more collaborative and efficient environment.

6. Balancing Risks and Rewards: Individuals weighed the risks and rewards of rule-breaking carefully, ensuring that the potential benefits outweighed the potential consequences.

This fairly accurately captures a lot of the justifications respondents offered as to why they had chosen to break a rule or policy. The reality we discussed on the deep dive was that there is a lot of variety in the kinds of rules that can be broken. Additionally, there are a lot of different potential consequences which map to that spectrum of rules. As with any decision, work is needed to consider the potential benefit and the potential consequences. One attendee expressed this succinctly by saying, “there is a seek-to-understand moment that happens just before you break a rule”. Another attendee said, “it really just depends on who you’re going to piss off”.

Stories from the Rascals

Here are a few stories shared by folks who said they would break the rules:

“The design system was built using Sketch. As components grew, Sketch slowed to a crawl. Manager was against rebuilding and switching to Figma to improve performance. Against the manager’s instructions, I rebuilt all Sketch components in Figma in one week and presented as ‘an experiment’. Team was thrilled at the improvement and we switched over to Figma. Manager not so thrilled. ;-)”

“When I joined the org, it was an unwritten rule that design sat in one building, and developers in another…I think it’s the unwritten rules and policies that are harder to challenge because they’re more engrained in the culture. Designs were launched over the void (a 5 minute walk across the parking lot), and we anxiously refreshed our browsers to see what transpired. It was like framing up the perfect scene and waiting for the Polaroid to develop. [I believed] we could do better. So I started spending more time in the development building, trying to establish trust in the design team, and also finding an advocate or two that was willing to give the design system another go (there had been a few attempts before I joined). Eventually, our design team had permanent spots alongside our development counterparts. The design system was advocated for throughout the org, and the culture had shifted to be more collaborative.”

We didn’t have enough resources assigned to the design system: PMs and execs had to focus 100% of their time on product on paper. So we did an underground/part-time plan: we talked to a lot of people, gave them access, and guided them along. Unofficially. And we had little architecture meetings in the form of ““would you like the design system be this way or that way”” and made those changes. We got people to start talking and creating the build system. So, before the project actually kicked off, we had a decent amount of structure in place.”

“I made an agreement with the engineering team to develop a design system. We basically didn’t discuss it outside of our teams. The founders [of the company] would not have been bought into the work given they only valued short term, fast gains. They also had marketing backgrounds and didn’t really understand engineering. So, we moved forward by attaching a little design system to every story that went through our roadmap. We got a lot done in a short amount of time this way without disrupting normal workflows. We also reduced time to launch for product launches by 40% for our marketing team.”

Even just in these few, you can see the spectrum of severity each presents.

Stories from the Rule Followers

Here are a few stories from those who those who said they wouldn’t break the rules:

“Leaning into the rules will help build relationships with the leaders you need on your side to hold your org accountable. I exist in the design org but I needed to make changes in the tech org. If I went on my own it would have been seen as a major over step and would have cost me the trust of the engineering community. Instead I created a deck that stated my case with proof and resources and shared it with my leadership team. They then went an influenced to make change happen. I think to assume that change can only be done by YOU is an arrogant and often costly mistake. Please reference Michael Bloombergs presidential run as a perfect example of this hubris.”

“I usually try not to break the rules of an organization, but rather do a little bit of what I want to change in my spare time and then present the benefits to my team. In this case, if my idea looks good, I usually get more support from my colleagues, which sometimes leads to positive changes and official resources for my idea. But, if I have the chance to hide my idea behind current tasks and do it within the already planned features, then I use it. I just add extra time to each task, and no one even knows how much I care about the product or how much money the organization has to spend because of my care.”

“Leadership level across the organization was not aligned for a new way of working. I tried, and it ended up that no team got time to work on this as they each have siloed goals and objectives assigned which tie to teams incentive and performance. ‘Help me help you’ is not applicable when teams are on different timelines and priorities.”

ChatGPT offered this overview of the “no” stories:

“Many individuals acknowledge the importance of working within established structures and protocols, seeking alignment and buy-in from leadership or attempting to persuade through evidence-based arguments. There’s an understanding that breaking rules might lead to mistrust, hindering the adoption and success of a design system within the organization. Some find ways to advocate for change within the confines of existing processes, leveraging support from colleagues or higher-ups to drive necessary modifications.”

I found this to be representative of the sentiment expressed in the deep dive conversation as well. One attendee expressed their hesitation in this way:

“If we break the rules now in an attempt to establish the design system, how can we expect our subscribers to follow the rules we put in place later?”

What did we learn?

Dan shared a great analogy for the rules and policies of an organization. Paraphrasing, he explained that many of those rules and policies are similar to a dictionary. While we tend to turn to a dictionary as as set of rules which shouldn’t be broken, in real life, cultures are constantly inventing new words and phrases or finding new ways to redefine existing words. In reality, a dictionary is a living representation of the culture—in order to stay relevant, it must grow and adapt to the reality of language within that culture. Many of our organization’s rules and policies are the same. For them to remain relevenat we have to be willing to challenge them as our approaches to the work shift.

This perspective resonated with a lot of attendees. In fact, one attendee said that they wanted to find more ways to enable the users of their system to break the rules. Perhaps this was a recognition that innovation often comes from that challenge to the status quo.

This line of thinking aligns with a lot of the research I’ve been doing into how an organization’s culture impacts the potential paths of maturity for a design system.

The Competing Values Framework offers a way to categorize organizational culture across four quadrants: Collaborate, Control, Create, and Compete.

We had a brief conversation about how the top of the “Competing Values Framework” represents organizations that are more flexible—willing to change and adapt as needed. Perhaps in these cultures, rule breaking is permitted as a way to push the organization forward.

In Conclusion

This deep dive was certainly theraputic. The topic of breaking rules can be anxiety-inducing in many, but it was nice to hear that others are struggling with finding the balance here as well. The truth is, design system work is asking everyone to change how they think and operate. In one sense it is breaking the existing norms to establsih a system in an organization where one doesn’t exist.

Additional resources

• Stables and Volatiles (by Michael Lopp)
• Recoding America (by Jennifer Pahlka)
• Rebels at Work (by Lois Kelly & Carmen Medina)
• Descriptive vs Prescriptive Defining (ht to Jesse)
• Hacking Gesalt (via Pinterest Design System Team)

Thank you

Many thanks to all who participated.

If you missed out this week, sign up for The Question and be ready to answer next time.

Writing Design Systems The Question