How to get your DesignOps team up and running

When it comes to organizational structures (aka, groups of people working together), there are two things I dislike:

1. Change
2. The way things are

🤔 Strange but true, right? Change can be as hard as staying the same. This has never been more true in my life until I had children. Before kids, I loved sleeping in, or even just sleeping later. But it’s hard to stay in bed when your newborn wails for your loving attention (parents, amirite?). His provocation caused me to change.

When it comes to the idea of DesignOps, what’s been your provocation to change? Has it been product design industry leaders speaking about it at a conference? An a-ha moment found in a Medium article? Or a self-realization that things at work just can’t continue without a rethinking of how we’re working?

Some teams start with a good provocation. A grain of sand can either be an irritant to get rid of or become a pearl in the right conditions. What’s provoking your teams to build a strong DesignOps practice?

Back to my opener, “change” and “the way things are” are usually good places to start — which one is more painful? Usually, we don’t change until the pain of staying the same is greater than the pain of change. When it’s time to change and build a DesignOps practice, discipline, team, group, method, etc., consider these things: 

• What can you automate with systems? 
• How you approach Design 
• Who you build with

Automate the important, but craft the critical

I think automation gets a bad reputation for threatening our future jobs. But, to me, automating important things is a way of life.

When’s the last time you wrote a check to pay a bill? I don’t even know where our checkbook is. I wonder if you’ve ever had a checkbook! I feel fortunate to live in 2020 where I can automate a bill to be paid without my intervention. I’m freed up to think/do/play other things instead of sitting and writing checks to my mobile phone company or internet provider. Those services are important, so I automate them. 

Automation gets a bad reputation for threatening our future jobs. But, to me, automating important things is a way of life.

When you’re building a skeleton DesignOps team, automation is critical for getting work done. You don’t have enough minutes in the day to keep everything in view. A good friend and mentor (Jon Zweifler) once told me: “You need to learn how to care less without being careless.” Enter: Automation of the important so I can focus on the critical.

When you’re looking at an org chart that has a design team in the single digits (or an org chart of “just you”), fear not. I’m with you and have been there myself. Know this: there’s more of you out there than you think. 🙌

If your team is small, your first efforts should be automating the important so you can spend time crafting the critical. No one wants to repetitively design the same rounded rectangle button, but it is important.

Enter: Design systems. I know they’re not brand-new — and everyone in design wants a solid and growing design system. But what I’m suggesting is moving beyond making a design system to have and set on a shelf. Instead, I suggest you move into the full automation of the important so you can focus on what you actually love: crafting critical experiences.

The design system carries the burden of the boring, so that designers and developers don’t have to.

Josh Clark | Founder, Big Medium

Josh Clark nails this in Design Systems are Boring: “When the design system is boring, it frees designers and developers to do the new stuff, to solve new problems. The design system carries the burden of the boring, so that designers and developers don’t have to.” I also highly recommend looking at Dan Mall’s thoughts on design system scorecards — they’ve helped me countless times to think practically and cut through the emotion to land on rational design choices.

In order to get your DesignOps to cruising altitude (so the drink cart can come around), invest in toolsets and mindsets that help your automation happen at scale. At Abstract, we believe in compressing the time it takes from your first idea to delivered product. By using a strong toolset of drawing tools, version control, and a common platform for design + development, you will start seeing efficiencies for the important stuff.

In order to get your DesignOps to cruising altitude (so the drink cart can come around), invest in toolsets and mindsets that help your automation happen at scale.

But starting a DesignOps function takes a mindset investment, too. You want to spend your time thinking about the whole Design, not just the component design. Which leads me to my next point:

Use your Design skills, not just your design skills

You got into design because you have great taste. Take a pause and make sure you’re reminded of your origin story — Ira Glass’s thoughts on Taste have inspired me in countless dry spells.

But I totally get it: The process of making and delivering can be a race that you never intended to be in. Another Jira ticket, another last-minute product shift, another TPS report, another user research finding, another unexpected epiphany from your design leader… the list can go on. All of this process stuff can bring you down.

Compound that grind with the feeling of “We just need to make a button component” and multiply that across your whole design system. It's a recipe for 😭.

Be reminded (again), you got into this because you have great taste. You’re not a designer, you’re a Designer. Take what you know about crafting components and level it up to Design a better outcome for your team. Design the components AND the process by which you’ll make them.

Foundationally, looking at your design organization (aka, the people who make considered decisions) is often one of the first things to address in how your team can actually take action. In Peter Merholz and Kristin Skinner's Org design for Design Orgs, they write, “The leader’s success in this skill is not just in the development of a vision — the corporate world is littered with concept videos, detailed mockups, and other scenarios of possible futures. Their success is instead shown in how the vision catalyzes action, inspiring the people within a company to charge forward because they want to live in a world where that vision is made a reality.”

The leader’s success is shown in how the vision catalyzes action, inspiring people to charge forward because they want to live in a world where that vision is made a reality.

Peter Merholz and Kristin Skinner | Org design for Design Orgs

In order to take action, the team you have today might need a redesign. There are a few different design team reporting structures, and even some top brands have opened up about the makeup of their DesignOps and Design teams. But ultimately, the charter and the task-list of your team is only one piece of the puzzle. Flex your strong design skills and take a full evaluation (research) of what is working and what isn’t in your team composition. 

This is the self-care of your team that you need to take before embarking on further design decisions for your product. If you’re not well organizationally, your product design will reflect that. Reformatting and redesigning your design organization can crisp your withering design operations goals while you use your design skills to do it. It’s a win-win: You’re still designing, but you’re designing your Design before you design your design (too nuanced? Well, let’s just say you’re doing people design then). Ultimately, organizational design is all about relationships.

Which leads me to my final point:

Relationship matters more than authority

Nothing can ruin your relational credibility more than these four words: “Because I said so.” I’ve leaned on this parental crutch more than I care to admit with my kids. It’s usually said in desperation and is an underhanded way of claiming authority. It’s flimsy. It’s shallow. It’s dirty. 

When it is used to defend design decisions, it undercuts the collaborative nature of product building. It fast-tracks a broken process and ultimately a frustrated set of teams. But there is another way that builds on relationships to help bootstrap your design operations teams.

As I get older, I have a set of “I used to think…” statements. Here’s a couple:

I used to think…

• Eating pizza late at night would not give me heartburn.
• Being 40 years old is… like, really old.
• Everyone can understand what I’m thinking by the expression on my face.
• Authority was the reason for my rebellion.

I’m glad those were “I used to think…” statements. I’m 40 and super happy about it, I don’t grab a late-night pizza without knowing I’ll be staring down some heartburn, I’m working on sharing my feelings with my face (appropriately), and I now know this: People don’t rebel against authority, they rebel against a lack of relationship. 

Sometimes, building cross-functional teams can feel like an outright rebellion. Sometimes, we build the product at the expense of the relationships with our stakeholder partners. If we could flip the equation and build relationships first, our products will be better.

When we broaden what a DesignOps team could be, I’d posit that reaching to non-traditional design partners, techniques, and tools can help not only with the process but also with the relationship. 

I’ve legitimately overheard this from an engineering friend when I told him our design team was using Abstract: “Hey, you’re using a Git-based version control, too? So much respect.” By using a similar version control tool to her own coding workflow, we were able to bridge some gaps.

So how does this get done practically? The design industry seems to be coalescing around a few key concepts of DesignOps — usually there are a few questions that get to the “who” does “what” and “when.” But we’re often solving the authority problem before we solve the people opportunity. 

I’m a huge fan of what Brennan Hartich from Slack (partnering with Amanda Weisfeld from Intuit) is proposing for the people part of a DesignOps team by outlining not only what the team should do, but what a career trajectory looks like. Brennan and Amanda propose four high-level responsibility areas for DesignOps at any org: 

1. Business operations
2. Influence & leadership
3. Teamwork & culture 
4. Design & product acumen

Putting these into practice builds the structure for deepened relationships in and beyond your DesignOps team and ultimately prioritizes relationship over authority and turfism.