Building DesignOps As A Team Of 1

Changying 'Z' Zheng at UXDX Community: USA West. Video: https://www.youtube.com/watch?v=teo7ytGjW-g

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How I became the DesignOps team of one

[00:00:00] Thank you for tuning in to hear me talk about building DesignOps as a team of one. I am Z, and I am the principal design ops manager at Cloudflare. Currently I'm empowering 30-ish design team members. In the past, a lot of people have asked me this question: how did you become the design ops team of one? And how can I be in the design ops space? How can I become a design ops practitioner?

[00:00:39] The answer is not going to be straightforward. Looking back at my career path, I've done a lot of different things. I was an individual contributor for a long time. I was a design manager. I was a player coach in this hybrid mode. I was in many different sectors. I was in higher ed for a few years. I worked for a startup. I worked for a food business before, and recently I've been in the enterprise space. So my journey is going to be very different from your journey. But what is important for me is that everything I did influenced how I approach things, and shaped who I am today.

[00:01:31] Let's take a look at how I became the design ops team of one at Cloudflare. At the time, I was very intrigued by this job posting hiring a practice lead. I was intrigued by Cloudflare's mission, to help build a better internet, and the many, many passion projects that Cloudflare was doing. Examples were 1.1.1.1, a free app to make the internet safer, and also Project Galileo, and the company partnering with pass forward[?]. These are great, great passion projects that attracted me to the group. So I started to talk to the designers and design managers on the team, and the more I spoke with the group of people, the more I realized: yes, we need a practice lead, but we need a design ops lead even more.

[00:02:28] Why is that? Let's take a look at what was happening with the company at the time. A couple of years ago, Cloudflare went public, so Cloudflare was expanding really, really fast, from a private company to a public company. There were multiple product lines and different processes across the board, not just on the design team, across the entire company. And there was increased demand on the design team. If you look at what design leaders and design managers were doing at the time, they were not going out to talk about design. They didn't have the time to talk about design, elevate design, talk about success stories of design. They were tied up doing operations. And also, people were leaving.

[00:03:11] And the big thing happened a couple of years ago. We all know the pandemic happened. So the entire company transitioned from office-first to all-remote. These were some signals telling me that the team needed operations help even more than a practice lead. These are somewhat unique to us, but not entirely unique. You probably already see some of these signals on your team as well. If you're thinking about being a design ops practitioner, you probably see some of these challenges already. I was able to convince the hiring manager, and they rewrote the job description and hired me as a design ops lead. I was onboarded as a practice lead, because that's the headcount we had, and very soon after that I was transitioned to design ops lead.

Defining the role: a strategic partner to the head of design

[00:04:10] I've been there for over a year. How did I run design ops as a team of one? Where do you start as a design ops team of one? To me, the starting point is really defining the role, defining the roles and responsibilities, and internalizing what is the space I need to work in. I'm a true believer that if you have one headcount for design ops, then this person should be the strategic partner to your design leader. Whoever that design leader is, whether that is a chief executive officer, or the chief design officer, or your senior VP of design, whoever the head of design is.

[00:04:59] I was really fortunate. I was able to position myself and get the buy-in to be the strategic partner to our head of design. But I know in reality it doesn't always happen, because I've seen in the past some people who started as a designer, and then they saw the operational need, started to do more of the ops work, and then were transitioned into a design ops position. So you might not have had the opportunity to be positioned as a partner to your chief design officer. That is okay. Later on in the slides, when I start to talk about how we scale, I will get into a little bit of how you grow if you are not positioned at the top partnership level.

[00:05:44] So I was very fortunate. I was able to position myself as the strategic partner to my head of design. But in reality, I know I'm one person supporting a team of 20 to 30 designers and design managers. I have to work with all of them. I have to support all of them: support my head of design, support my design managers, support all of our designers. And that's my day-to-day work anyway. So I understand that there's a lot of work to do as a team of one.

People over process over tooling

[00:06:14] There are a lot of demands on a design operations practitioner. These are some of the things you've probably heard other people talk about. People want tools, people want to build culture, have someone facilitate events, and people want help to grow the team, and everything. There are just so many things to do, and it looks really chaotic, just really high demand. You're one person, so how do I sort all these out? How do I find order in this chaos? I see all these challenges in three groups: people, process and tooling. Helping our people to grow. Improving process so the entire team can be more efficient. Introducing tooling so, same thing, the team can be more effective and efficient.

[00:07:14] People hear me talk about this a lot. To me, no matter what you do, it's people over process over tooling. Think about what the role of a design ops person is. Essentially, our job is to help our people. So no matter what kind of process we improve or introduce, or what kind of new tools we introduce, it's to address the needs of our people. So people over process over tooling. Care about the people you work with.

Starting by listening: the first 30 days

[00:07:51] Starting a new job, a lot of the time our immediate reaction is, oh, this is a new job, I need to start doing things to prove my value and to prove I can get things done. Pause. To me, that is the wrong starting point. If you think about design ops as service design, think about the UK Design Council's double diamond. The starting point is really to understand the people we serve: understand the design managers, understand the needs of our design leaders, understand the needs of our designers. The starting point is observing, intake, learning about our people. Think about it: you were offered this job. You're in this position doing the work. Your manager already bought in and trusts you. Let's trust ourselves.

[00:08:53] So in the first 30 days, what did I do? I was fortunate that at the time we had about 20 people. I was able to set up one-on-ones with every single person on our team. Actually, I was able to set up multiple one-on-ones during the first 30 days. If you have a larger team, you might not be able to have time with every single person. I've heard of some people supporting 100 designers, 200 designers. So make sure you think about research methods. Set up a sample group of people you're going to reach out to, whether they are in different offices or different geo locations. Also try to find the people who have been with the company a long time, and also reach out to people who have just onboarded to the company. Think about more senior designers and more junior designers, different levels, and get a good sample size of people to reach out to.

[00:09:53] But I was very fortunate. I was able to set up time with every single one of them. I got a notebook when I onboarded to the team. I was a designer, so I like doodling everything. I write down everything in pen, on paper. I set up a tab for each person. I talked to them and got to know them. You might be thinking, "Oh, great, you get to learn about their challenges, what they need." No, not really. What I actually really needed to know was about them as people, to get to know them first. Who are they? What is their working environment? Who are their partners? What's their dog's name, cat's name, kids' names? Because their work environment and who they are impacts how they bring themselves to work, and the challenges they're facing are a combination of their daily life and work life. Especially now, when many, many of us are working from home, the home environment actually is our working environment, and it impacts which challenges are more prioritized, more urgent, and everything. So really get to know these people, learn about these people in person.

[00:11:03] After I got to know them, I was actually able to get them to open up and tell me what their challenges are. I was able to use a digital tool, I used Miro here, to synthesize and see if there were patterns on the team. So this is what I found. Different groups of people have different needs, of course. Let's take a look at our head of design and what they need to do. In theory, the head of design needs to go out and talk about the design team: 80% external communication, 20% internal communication. And my job, when I partner with my head of design, should be the reverse. As a design ops lead, my job should be 20% external, 80% internal.

[00:11:53] And look at our design managers. When I started, most of our design managers were player coaches. They were delivering product and at the same time managing people. There was just so much; they were overwhelmed. They needed a partner to help them build team rituals. They needed a partner to help them build process, and also help them allocate designers to different projects, and help them grow the design team, set up a leveling guide, and help them with people processes. People processes are things like the hiring process, the onboarding process, the teaching, education and learning process, and also the offboarding process. So they needed help with all these process things.

[00:12:40] Then take a look at our large group of ICs, individual contributors. What do they need? Remember what happened two years ago when I started: we went from office-first to all-remote, and the workload was just a lot for our ICs. We've heard this many times on many teams: we don't have enough designers, we need more designers. So on many, many teams designers are overworked, and their top need is really to figure out their workload. And of course, now that we'd gone from all in office to all remote, the tools we had before didn't work anymore, so they needed help introducing new tools. And also, now that we don't see each other every day anymore, they needed team activities, and to build a team culture, all remotely.

Prioritization as a superpower

[00:13:41] There are a lot of things. Everyone wants something. Everyone needs design ops help. I'm one person. I'm a human as well. I couldn't possibly address all these challenges at the same time. So what do I do? Prioritize. If there's one superpower I can take with me, it's prioritization. Again, let's look at it. We have the needs of our head of design. We have the needs of our managers. We have our ICs. I'm going to use one example today to talk about how I did it end to end. I'm going to pick one of the challenges, helping our ICs, as the example: helping ICs with their workload.

[00:14:27] Remember, I went out to talk to everyone. I synthesized and came up with the patterns and what they needed. I wrote down a lot of outcomes we wanted to achieve. Even with helping ICs, there are a lot of challenges, so how do I prioritize? There are tools out there. Think about product management. This is a very, very simple tool, a two by two. I wrote down all the outcomes I was trying to achieve, and then used the two by two to help myself prioritize, looking at visibility and impact. One thing emerged as the top priority: improve process to reduce workload, so that designers can focus on deep thinking.

From execution to planning

[00:15:12] Let's look at what it takes to achieve one outcome. There are two sides of doing one thing. There's the planning part, the strategic planning part, and there's the tactical execution part. And as a design ops person, we work with the leadership and we also work with the organization. So we want to be the bridge to the organization, address all the execution things, help with execution, and then go to the planning side. Once we can address all the tactical execution, we can go on to optimize the decision-making process.

[00:15:54] Remember I talked about wanting to be the strategic partner to my design leader. So the ideal space for me to work in should be this bottom-left portion, being the strategic partner with my design leader and doing more of the planning. But I couldn't really start from here. I had to work my way through from execution, to helping the organization, and eventually work my way through to the planning. This framework was first introduced in the book One Mission. I altered it to make it work for design ops. Originally this was a framework designed for chiefs of staff, and it works really well for design operations as well. To really work at the strategic partnership level with our design leaders, we actually also need to take care of the execution.

[00:16:49] So in this example, in terms of execution, before we could even plan, we actually had to address the immediate need, which is allocation. How can we put different designers on prioritized work? How can we match the goals of the company and put the designers on the highly prioritized, high-impact work, instead of saying yes to everything? That's what caused the overload. Then, looking at the organizational side, we want to reach out to our design team. I reached out to the cross-functional partnership teams to think about how we can do more of the design, PM and engineering balanced team approach. How do we do design pairing, pair designing? These are all execution and day-to-day life.

[00:17:44] Once we take care of the execution, we can actually start to think about the planning, to think ahead and get ahead of the challenges. In terms of planning, work with the organization, think about the intake process. Can we improve it? Can we do better? And then, once all these are in place, we can finally get to the quadrant where we think strategically about planning for the next quarter. If you think about just this one challenge, improve process to reduce workload so that designers can focus on deep thinking, for this one outcome there are so many things that need to be done, and that requires a lot of changes.

Framing change as experiments and building trust

[00:18:31] Changes are scary, right? So what if we don't talk about changes? What if we experiment? How do I get people to experiment with me? The starting point is really trust. Remember I went to talk to people. That is why I needed to get to know all the people, get to know the designers and design managers, who they are as people. All the little things matter. So build the trust. Another method to build trust is really bringing people along for the ride.

[00:19:08] If you look at the organization when I started, the design org was not very mature. We were growing. Many of the designers were hired in the last couple of years. So it's a developing team. If you think about development, how do we make decisions? This is a framework designed and introduced by Dr. Victor Vroom. It is a decision-making model. If you think the team needs more development, then you tilt this scale towards a more participatory approach. I also ask the question, because a lot of the time I hear people, especially design ops practitioners, say, hey, I have this big idea, I want to try it out, but I can't get buy-in from my group. So I asked myself: do I need my designers to do this with me? Do I need my design managers to do this with me? If the answer is yes, I tilt even more towards the participatory approach. And do I need these people to willingly experiment with me? If the answer is yes, which it was for all these questions, it leans even more to the participatory approach. So get people involved, work with people, come up with ideas.

Intake, design pairing and office hours

[00:20:25] Let's go back to this example. To achieve this outcome, let's look at the work on hand. We have planned work and we have unplanned work. I worked with our designers and design managers. We did a lot of workshops to figure out what we had to do to address the needs of planned work, and what we had to do for unplanned work. For planned work, we knew that we needed a better intake process. We needed to improve that. We can't just say yes to everything. We need to be able to see all the work that comes our way, because in the past, a lot of the time the work went directly to our designers. Designers want to help. Our reaction is always, yeah, I can help. But then we have no oversight. Everyone says yes, but the result is being overworked. So we needed to take a look at the intake.

[00:21:16] We also had to figure out how to introduce some new practices to help our designers. We came up with an idea borrowed from engineering practice: pairing, design pairing, pair designing. This is about increasing the bus count. If I have a design pair, and I need to take care of something, I don't feel guilty. I know this whole product is not paralyzed because I need to take a few days off, or even a month off, to take care of family. My design partner has my back.

[00:21:53] We also wanted to really address a lot of the unplanned work. It's important to address it, because what happens a lot of the time is someone comes to a designer and says, hey, I have this button, can you fix it? It's only going to take you five minutes. A five-minute task is going to take maybe five days, because you have this button, and then there's iteration, and then you talk about where the button works, and how changing one button will impact a bunch of other buttons, and how that works in your design system and everything. There's nothing as simple as a five-minute task. This unplanned work interrupts our daily deep thinking time to work on the prioritized planned work. So our team came up with the idea to run design office hours. These are one hour each week. We have a pair of designers helping people solve their bite-size emergencies, so these problems don't go into the everyday planned work space.

Rolling out small: build, measure, learn

[00:22:54] So now we had a plan. How do we roll it out? This is a lot of things to do. The rollout plan focused on starting with something small. Don't try to change the entire flow, the entire thing. Think about the product development method: build, measure, learn. Build small, measure it, learn from it, iterate. So we didn't roll this out to the entire team. We have a few regions. In the US we have four time zones, and in EMEA we have a couple of time zones. We didn't roll out to the entire team. We rolled out in one region, the central region, our office in Austin[?], with a few designers there. And we rolled it out in one domain area, not all of them. We have 20-ish products we're working with, so we rolled out in one domain area and started with a couple of pairs. Not everyone has to have a pair to start with. In terms of tooling as well, we started with something really basic, a Google Form for intake, and gradually introduced more tools into the process.

[00:24:07] So the focus was to build, measure, learn. We ran a lot of retrospectives to try to learn how we could improve incrementally. At the very beginning of the process, design ops was very involved. An example is the office hours. I was in every single design office hour for the first couple of months. I helped with scheduling. I went and observed, just to see how it ran and what the challenges were. I had people taking information and filling out a form at the end of every design office hour. I was very, very involved, hands-on. But eventually, after we iterated and iterated, it got to the point where nowadays the designers took more ownership, and I entirely removed myself from that space.

Measuring success: quality, time, cost and team health

[00:24:51] If we think about build, measure, learn, let's look at the measure. What do we measure? How do we measure success? I always look at the product management triangle, with these three things: quality, time and cost. We don't have to be super, super scientific about what to measure. It could be an educated guess. Does my work help to improve design quality? Does my work reduce time for our designers, engineers and PMs, or save money or make more money for the company? An example would be the design office hours I talked about. After running them for a few months, we looked at how many projects we had helped during design office hours: 88 projects in the past six to seven months. What is this? This is improved quality. Because if you think about it, without design office hours, these 88 projects would have gone out without the touch of designers. Now these 88 projects have some input from the design team. That is improved quality.

[00:26:14] What makes me really, really excited about working in the design ops space is that success for design ops can be measured by more than just the money saved or the time saved. It can be measured by team health. My outcome is to help our designers reduce their workload. How do we see if I actually achieved that outcome? Think about the design team: do we have a better, healthier, happier design team? The company runs health check surveys and pulse surveys. For our design team, I also partnered with our design researcher to run some pulse surveys for our entire team. If you can move the team in a healthier direction, a happier direction, that's also success for design ops.

Scaling: team ops and product ops

[00:27:15] Let's talk about growing and scaling. You're the design ops team of one. I'm the design ops team of one. At some point the design team grows, and design ops needs to grow accordingly. A good ratio is one design ops person to 10 design practitioners, and that includes design leaders, design managers and designers. I know this is an ideal number. It's a number a lot of people put out there as the ideal ratio. But think about how we grow the team. I look at design ops as two spaces. One is team ops and one is product ops. Each has slightly different focuses. I see team ops focusing on community, culture, learning and growth. For product ops, the focus is project and program management, productivity and delivery.

[00:28:11] But there's some overlap. If you think about it, we want to encourage designers to pair, and we also want to encourage our ops people to pair. There are certain areas that both will touch: strategic partnership with the leaders, and systems and tools, probably team ops and product ops will both touch these areas. So think about growing our team. I was very fortunate. I was positioned as the strategic partner to my design leader, and my superpower is actually team ops. When I have the headcount to grow my team, the next person I'm looking at most likely is a product ops person, to balance my strengths: someone to come in to take care more of the productivity and delivery, to run the numbers.

[00:29:06] Now, I talked about how not all of us were positioned as a partner to our leaders. Maybe we started as a practitioner, and as product ops, because we were a designer and then transitioned to ops by doing a lot of the ops work. So if I were in this position, how would I grow the team? I have options. I could find the next person, my counterpart, to help me with team ops. If my superpower is product ops, I could also think about hiring a design ops lead who has more focus on team ops. So this is growing the team, growing the ops.

Multiplying your impact without headcount

[00:29:46] But I know in reality we don't always have the headcount. This is the State of DesignOps 2021, put out by Angelos[?] and his team. If you look at where we're operating, most of us are on a design ops team of one to four people. I think four is optimistic. Most of us are a team of one, and there's also 10% of companies that don't even have a dedicated design ops position. So 60% of us are operating in this design ops team of one space. That's why I'm so passionate about talking about being the design ops team of one and how to run it. When we don't have the headcount, it takes a long time to educate people, advocate for design ops, and explain what design ops does.

[00:30:37] So when we don't have the headcount, think about how we multiply our impact. A couple of things: build templates, and uplevel others. We don't have to build fancy, elaborate templates. I spend a lot of time just building templates. It can be something really scrappy, something simple. I built Miro templates for our designers, and for the entire company, to use. I also built templates in Figma to help our designers, built the leveling guide templates, built intake templates in Confluence[?], and built some of the onboarding templates as well, for our design managers and for our new people. This can be super scrappy. It could be a template for just an email communication. Our managers can then copy and paste, change a couple of lines, change a name, personalize it and send it out. Scrappy is okay, but build templates that will help us multiply our impact. We couldn't possibly do everything ourselves, so get others to do it as well. Uplevel other designers. I do a lot of facilitation, and I also coach other designers to do facilitation.

Recap: define the role, care about people, experiment bravely

[00:31:44] So let's look back and recap. The starting point: defining the role, defining our own role and responsibilities. Pick our battles. Change management: design ops is change management. Change management takes time and effort. It is hard. But care about the people we work with. I know a lot of practitioners in the design ops space, and there's one thing we have in common. We're all passionate catalysts. We care personally. We care deeply about helping our people, and we want to make our team the best they can be. Helping people is rewarding. And remember, you're not alone. There are a lot of design ops practitioners in this space.

[00:32:47] Experiment. Experiment bravely. Think about this service design principle: build, measure, learn. You've heard my story, my success story, but I could spend 10 times the time talking about my failures. Framing our efforts and activities as experiments gives us the permission to fail. Let's try it out. What if this doesn't work? We iterate. We make it work with the team. So this is my story of the design ops team of one, and I'm eager to hear your story of being a design ops practitioner. With that, thank you.