Creating levels for DesignOps
Needing great operations for a design team isn’t anything new. In fact, I’d argue that DesignOps has been around for a very long time in one form or another, but now more than ever DesignOps is a term that seems to get thrown around quite often. With it’s growing popularity, I have observed companies use and mold the role in different ways which has led me through the process of defining the key areas my team would be responsible for and the career levels that go alongside that.
I’ve been honored to be able to work for amazing design teams at companies such as Facebook, Intuit, and most recently Slack. Taking my own experiences from each company, and by learning from others in the industry, I embarked on a journey with Amanda Weisfeld (Group Manager of DesignOps at Intuit) to put together levels and expectations that we use with our teams to help measure their success, help them grow, and understand what is expected from them at each level.
I could have gone overboard with a 40-page article on how Amanda and I landed on the themes below, but I don’t want to bore you with the details. I’m going to spare you from reading a whole novel, and instead, below are the four key areas and the subcategories within each theme we have outlined.
As Amanda and I have been working through these levels we wanted to address that we are design operations and not only an operations team that happens to manage design. We asked ourselves, what sets us apart from business operations, TPMs, PMO, etc. and we found that the biggest differentiator is that individuals on our DesignOps teams need to have a clear understanding of design. In the same way that a TPM usually has some experience with coding, DesignOps should be the same but with design, and this is why we specifically added a section around design and product acumen.
We understand that this is not the only approach one can take to create levels, matrices, profiles, etc, but we went with this because we believed it was broad enough to work for a lot of companies, yet specific enough to work for career guidance.
Four key themes
Business Operations
This section covers all things that are necessary for running an efficient design team — many of these things are what I consider ‘run the business’ type tasks. Design program management is an area many people focus on, but we felt that only focusing on program management was too narrow to what DesignOps can offer. We broke this section out into operations design, strategic intelligence, and project/program management.
Influence & leadership
Building relationships and being able to lead without authority are key skills our teams need to have. It is an art to be able to influence an organization and bring about change, so we narrowed down the sub-categories to be inquiry & advocacy, relationships, strategy/business impact, and ability to scale.
*I cannot share the level details for a few of these sub-sections as they are exclusive to my previous employers.
Teamwork & culture
We wanted to make sure that this area was not only tactical around event planning and logistics, but also included strategic capabilities around the attraction of talent and creating learning and development opportunities for the team.
Design & product acumen
We narrowed in on core design and product skills that our teams need in order to be the best partners to the design team: design systems, design process, user experience (UX), and design research. Without these skills, our team would not be differentiated from traditional operations or program management teams, and these technical skills allow us to fully scope, enable, and measure our design teams' success.
My final thought
Recently, Amanda and I co-ran a workshop at the DesignOps Summit by Rosenfeld where our goal was to help attendees understand how to approach and create levels for their DesignOps teams and to create a baseline in the industry. It was our very first time running a large workshop and it was definitely an eye-opening experience. One of my main takeaways is that every organization operates and values things differently. For example, some value and prioritize design in all they do, others put more emphasis on operations, etc. This means levels, expectations, and requirements can vary drastically by company. What I found very useful in my own team’s levels, others thought were completely unrelated or not necessary. I realized that while we may not be able to create a consensus of what DesignOps means across the industry, in my opinion, the above framework has worked quite well for more mature design teams (especially those in tech) and I’m hoping that many of you can use the above as a baseline and tailor it to your specific organization’s needs.
