Building Your DesignOps Org — Part 2

From plugging the holes to maturing your team: a two-part series

There’s something so satisfying about seeing all the pieces of a puzzle come together. For me, that puzzle has been building our DesignOps team. It’s been a little over a year since our first hire, and the vision is happening. It’s really happening! Squee!

In my last post I shared how I built my team, from headcount to getting started with foundational design team needs; today I’ll share how we’ve been working toward simultaneously maturing DesignOps as an organization, and the teams we support.

Note that this is still a work in progress for our teams, and no — we are not at perfect maturity. We also totally did not get this right on our first go. This is the “learn from my mistakes” version based on how we began, reassessed, and changed course. And we still have lots of work to do.

The Design / DesignOps Maturity Link

The health and maturity of a design team and its DesignOps partners are inextricably linked. If it were a dependency diagram, it would just be an infinity swirl that would give you a headache.

The healthier a DesignOps team is, the healthier and more mature the supported design teams are. The healthier a design team is, the more opportunity there is for DesignOps to expand their scope.

When a DesignOps team has their act together, design has the space to mature in deeper, more meaningful ways. They can grow as designers, no longer burdened with operations and the mind space it takes up. Leaders can focus on cultivating talent and building their teams’ skills. Designers are “unblocked and unlocked” (to borrow from Kyle Caruso at Lyft).

But it’s only when a design team reaches a certain level of maturity that they’re ready to accept and fully benefit from all DesignOps can offer. Not that they wouldn’t benefit from DesignOps in some capacity, it just might be at a smaller scale and scope. The better design operates, the more DesignOps can do to truly elevate them.

And yes, some design teams these days are formed with DesignOps in mind from the outset, and that is not only refreshing and personally gratifying — it’s also a signal that the team started out at a higher maturity level. Bravo to them! But it’s not the norm and that’s why it’s critical to understand what your team’s maturity level is today, and where you want to go in the near and long-term.

Assess Your Maturity

How well do people honestly assess their own team’s maturity? Turns out, for most people, we have a skewed view of how well we’re operating.

We did an exercise last year asking the broad question, “how mature is the design team today on a scale of 1–5,” and found that many folks rated the team as 3 or 4 out of 5. Very confident. But when we assessed specific elements of maturity with more defined scales, that number went down to a 2… sometimes even 1. Yikes.

There’s a Design Maturity Model from InVision with a fantastic appendix that essentially serves as a maturity checklist. It’s especially helpful if you’re not sure how to start thinking about the things that make a team “mature” or to use as a discussion starting point with design leaders to understand their priorities. Sparkbox also has a design-systems-specific “quiz” to assess maturity. For an in-depth DesignOps maturity model to diver deeper on, Nielsen Norman Group has a great list from a July 2000 study on DesignOps maturity.

If you want to save yourself some time, copy this Google Sheets version and modify it to fit your team’s needs.

Take your design team through the maturity checklist and ask everyone to honestly assess how consistently they/their team do each item.

1. We don’t do this
2. We rarely do this
3. We sometimes do this
4. We usually do this
5. We always do this

If you have a large team, you can do this with leaders. If the team is smaller (or you want to do this exercise for subsets of a large design team), include the whole crew.

Learn from our mistakes: It’s a big list, so you might want to spread this conversation out over a few sessions, break up the list and assign pieces to groups, or do this asynchronously with a duplicate sheet per person to avoid rating fatigue. It got pretty taxing by the end.

Take a moment to celebrate the things that rated higher. Got a few 4s and 5s on the list? Amazing. Mostly 1s with a few 2s and 3s? Those are wins, too. Part of maturity is to keep (purposefully) doing the things that are working.

Mind the Gaps

Once you have a more accurate view of where the team is today, look at each item and determine with DesignOps and design leadership:

• Which items are most critical to your design team’s success?
• Where are the biggest opportunities for maturity?
• What ratings can you reasonably aim for?
• How are you going to get there?

It’s this last question that’s often the hardest. Maybe you know you need to start capturing design metrics, but don’t know how. Perhaps you need a better hiring strategy, but aren’t sure where to start. Like lots of initiatives, the first step may simply be exploration. Then, once you have a better sense of the issue, you can ideate, design, and execute. Hey, this sounds familiar. Almost as if you could…

Treat Maturity Like a Design Project

Give it the same gravitas, process, and attention that you would any other project. Allocate time for it, assign people to it, create accountabilities. Define your deliverables and stakeholders.

On our team, it looked roughly like this…

Find Themes

With so many specific elements of maturity to consider, it would be (even more) overwhelming to address each one individually. That’s why we looked for natural groupings like measuring success, whole-team unity, hiring, and scalability so we could think more strategically about not just treating the symptoms, but the underlying needs. These were our themes. If you can, give each theme an overall rating using the scale above.

Develop Goals

Write out your intention for each theme based on the gaps you found. These are your goals. Documenting your intentions gets everyone aligned on what needs to happen. You don’t want to be at odds with design leadership about which items to tackle or how they’re prioritized. Creating a brief one-page document for each thematic goal that covers the details keeps the whole team in sync.

There are a lot of rules out there about writing goals; to me, the purpose of this exercise is to get clear on what your ideal outcome is. So don’t stress about following intense goal-writing formats. Just write it in plain language: what do you want to accomplish?

For each thematic goal, write up why this is important, who this will impact, what you plan to do, how you plan to do it, and when you plan to do it by. Include your current and ideal rating. Map your intentions back to your company’s business goals, if possible. Capture how you’ll know you’ve been successful. It’s like a design brief… emphasis here is “brief.” Brief, brief, brief.

If you’re not yet sure about the how, that’s ok. Get some ideas flowing and keep moving. Otherwise you’re likely to get stuck here and the whole exercise will stall.

Once everyone agrees on the brief (brief!), it’s time to figure out what you can actually, reasonably do.

Prioritize Goals

With unlimited resources, you could elevate any team in no time at all. But most of us are constricted by competing efforts and capacity, so you have to prioritize and roadmap those goals.

It will be tempting to tackle everything at once. Resist that temptation with everything you’ve got.

Learn from our mistakes: When our team did this exercise we tried to address far too many issues simultaneously. It was chaotic, stressful, and overwhelming. Follow good organizational change practices, and be realistic about what you and your teams can do.

Again looking at themes, determine which are the ones your team needs most, today.

For us, it was metrics and measurements (how we know our work is meaningful), fine-tuning process (how we know what to do, and how others know what to expect of us), and team cohesiveness (how we establish ourselves as a singular design team). For you it might be hiring, team morale, creating career paths, standardizing templates… every team has a different foundation to build. Keep in mind, it’s not always as simple as looking at the lowest-rated items.

If you need help prioritizing, go back to the listening tours you did in Part 1 of this series and pull out the pain points. Those issues likely point to which areas to address first.

It might also help to think of maturity projects in two buckets:

1. Things you can do internally (within design) that won’t rely on another team for buy-in or resources
2. Things you need external (outside design) buy-in or resources to accomplish

You might pick one or two themes from each bucket and start there to avoid being overwhelmed.

Plan and Execute

Since you’re treating maturity like any other project, you’re gonna make a plan. Assign people. Set milestones. Create accountability. If you want to get anywhere with these goals, you need dedicated time to work on them.

The as-we-have-time approach will result in microscopic progress, at best.

Work your goals into your team planning (assuming you have planning — if not, hey, that’s a good place to start your team maturity). Set guidelines for prioritizing these goals with other work, and blend it into resourcing for other projects.

Document your tasks just like you do for other work, and set up the same communication cadence. If you use Jira for projects, use Jira for maturity goals. If you do weekly check-ins for projects, do weekly check-ins for maturity goals. It’s so easy for this work to fall off the radar or get pushed aside. Make it part of the regular project rhythm.

Be ready to iterate and reassess often. Be experimental. Try different solutions on different sub-teams and see what works best. There’s no single right answer.

When you’ve accomplished a milestone, celebrate! Do a retro and talk about what you learned so you can apply it to other goals (or improve wherever you are on that goal’s plan).

Support Maturity as a Leader

If you’re leading a DesignOps team (or a design team), your role here is important. Depending on the level of ownership your team feels, they’ll either be looking to you to tell them what the goals and priorities should be, or they’ll be coming to you with 1,001 ideas. Both scenarios are ok. Either way, it’s your job to facilitate the team’s understanding of what’s important, why, and what you expect to see.

Stay Human Focused

At the end of the day, a more mature team delivers better products and services, yes. It also delivers happier people who are more likely to stay in their role, refer friends to join the organization, and rate you and the company higher in those annual surveys. People really are at the center of everything we do as leaders. Keep them top of mind as you think about maturing DesignOps and design as a whole.

Remember that the people aren’t being assessed for maturity. The organization is.

Maturity conversations can put people on the defensive. Be upfront about what needs to happen for the team to really shine, but be sensitive to the fact that telling people they’re “immature” isn’t a great feeling. Depending on your team’s culture, you might use terms like “leveling up” or “evolving” if you think they’ll bristle at “maturity.”

Set Expectations

If you want a project to succeed, you need clear requirements. If you want your teams to mature, you need to set expectations for what that means to you, and what you want to see from each defined goal.

Give your team the right balance of vision and direction so that they can execute on each goal effectively. Pre-prioritize the list of maturity elements to rate against. Provide a template for the brief (or delegate that to someone who loves making templates), be crystal clear about what should come out of each meeting and deliverable (just like a design project!), and give ideal timelines while checking in with folks often to be sure they’re not over-allocated.

Learn from our mistakes: I tend to fall in the “I hired you and therefore trust you to do your job” camp, and as such can sometimes misjudge how much direction someone needs. Provide enough direction and guardrails to move forward without being overly prescriptive.

Be Realistic

It’s fine to have your own list of 35 things you want the team to accomplish. Vision! But be real about where your team is today, your resources, and your company’s appetite for spending time on work that doesn’t immediately generate revenue.

If you think that the work to support maturity goals will have a noticeable impact on ability to turn around design deliverables, connect with your stakeholders and set expectations there. You may need to do some negotiating and tradeoffs to balance “regular” and maturity projects.

Recognize Done

Celebrate! Whether it went the way you expected or not, you and your teams did something new and that’s hard. Yay, you. Celebrate your team’s efforts in whatever way works for your folks.

Maturing never really stops.

We’re always going to be looking for new ways to expand our reach, improve our processes, and support our team’s growth in exciting ways. But you have to create some semblance of “done” for each goal. In the case of metrics and measurements, “done” for us is when each team has some way of measuring value in a way that’s meaningful to them. Yes, they’ll keep refining. Yes, those will change over time. But we have to be able to recognize when we’ve hit the target.

Was your aim to get from a 2 (we rarely do this) to a 4 (we usually do this) in a particular area? And did you do that? Woohoo! You’re done for now. Next time you do your assessment you’ll aim for a 5.

Keep the Maturity Momentum Going

Sometimes when we make improvements they become the norm and we forget where we came from. People get “improvement amnesia” as you raise the bar. So do all the reminders. Keep talking about progress with the whole team, and make communications wide and frequent. Be super transparent, and make that progress as visible and in-your-face as possible.

As your team matures, you’ll start to see a curve in people’s expectations of growth and evolution, from design, DesignOps, and organizational partners. They’ll become more sophisticated, moving from foundational needs to complex asks. They might even be beyond the original vision. This is a great sign.

Keep up the momentum with a regular cadence of maturity assessments — once or twice a year, go back through the list and reassess yourselves. Celebrate the big changes, and notice where you need to focus next. Maybe even invite people from outside design to participate.

No matter where you fall on the maturity scale today, small changes can make a big impact. Just remember: treat it like a design project, prioritize, and focus on the humans doing the work.

Maturity doesn’t happen overnight. But with focus and patience, your DesignOps and design teams can become the well-oiled machine that DesignOps dreams are made of.