Q&A With Z Zheng

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

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.

Why the design ops title matters

[00:00:00] Host: Jumping in quickly, we're going to talk with Z about building design ops as a team of one. So welcome, Zed.

[00:00:07] Z: Hello, hello. Thanks for having me here.

[00:00:11] Host: Great. And sorry, is it Z or Zed?

[00:00:15] Z: I go by Z, but this is a really interesting subject to start with. We have a global team, so my EMEA friends always call me Zed, and my US friends always call me Z.

[00:00:27] Host: So I'll go with Z. Apologies, coming from EMEA.

[00:00:33] Z: No problem.

[00:00:35] Host: I'm just going to jump right in, but again, if anybody has any questions, please do throw them in and I'll ask them. Jumping right in: you mentioned that when you got this new role with Cloudflare, you chose to change your title from being a design lead to being design ops. Why did the title matter? Why not just do what you're doing, but with the old title?

[00:01:04] Z: The title doesn't matter, but how people perceive it matters. Design operations is not a new practice, because there has always been someone doing design operations work, for a long time. But design operations as a practice, as a title, as a profession, is rather new. So changing the title gave me the tool to advocate for design operations, to talk about what it is. That's where the title matters.

Meeting people and prioritizing their needs

[00:01:36] Host: Excellent. One of the things you said was the most important, and I think this is true for any role, is to meet the people. When you're starting out, just get to know all the different people. One of your slides was, depending on the role, these were their needs. And then you said you prioritized. What's going through my head is that you've met all these people, you're brand new, and then you've said, "Look, that's not important right now." How did you manage that as somebody new coming into a role? You believe this is the most important thing, so that involves telling other people, "Listen, I can't do your thing at the moment, but I'll get to it."

[00:02:19] Z: That maps back to the talk, about building the trust first. You have to build the trust that people can actually talk to you and feel you listen to them as well. The next step is also what we were talking about: to look at the needs of the people as a group, and also look at the business needs as well. And the third thing is that I talk a lot about bringing people along the way. It's not "I decided your need is not as important as their need." It's really getting together as a group and outlining: these are the things we need to do, and this is how we prioritize them. Then people can see what you're doing, and you talk about why this is more important, this is a bigger need on the team, and this has a higher impact for the team, and hence that's the prioritized work I need to do.

[00:03:19] Host: Excellent. And did anybody give you different feedback? When you said, "Look, this is how I've analyzed it and this is my prioritization," did everyone accept that, or did you get a bit of back and forth with people?

[00:03:37] Z: Not always. Not everyone can be aligned. There's always a back and forth. It's always a discussion. That also maps back into how I roll it out. I can't just say, "Hey everyone, all 20 of you, start doing this." That's why we start very small: try with a small group, get the people who are experiencing this with you to talk about it, and then spread it out to the larger team. So there's always a conversation.

Design ops and the design lead as strategic partners

[00:04:05] Host: Great. One of the key themes in your talk, I would say, was the strategic partnership between design ops and the design lead. Because, as you mentioned, it's quite new, I've heard conflicting things: that the design lead is the people side of things and design ops is the system side of things. But in your talk you said that design ops has both the team and the process aspects in it. So where do you see the delineation between your design lead and your design ops?

[00:04:43] Z: Part of it is in one of the slides, where I mentioned what we see our design leaders needing to do. If we think about our design leaders' tasks, their task is less about internally managing the designers. It's more about advocating for design, talking about what the design team's strategy is and what the product strategy is. And for a design ops person, when I come in, I'm the counterpart. It's 80/20: the design leader is looking at 80% outward communication, and I'm looking at 80% inward communication, balancing that out, and helping with a lot of the logistics.

[00:05:21] Z: When I think about design operations, I talk about people, process and tools. The people are the center of everything we do. We need to support the needs of our people. So design ops is the bridge between the people and the organization. That's how I see design ops.

[00:05:43] Host: Excellent. And with that structure, I guess people are moving more to product teams and reporting to product lines, but there is always a design reporting line. Would you see that staying with the lead? Or, if the lead is focused externally on communicating, does that reporting line move more into design ops?

[00:06:08] Z: I believe the design lead is still the reporting line. The design ops person can be the strategic partner. As an example, right now I'm not a people manager. I'm an IC, and I've actually really consciously stayed in this space. Being a people manager is a different job from being an IC, especially as I'm passionately talking about design ops as a team of one. In a one-person team there is a lot of work that needs to be done, and that is a different focus. So the design operations partnership with the design leader doesn't have to be a people-management structure, and that's where I talk about leading by influence rather than by authority.

Doing design ops without the title

[00:06:54] Host: Excellent. Coming back to what you said at the start: people have been doing this role for a long time. They haven't called it design ops, but they've been doing these kinds of things. If there's anybody in the audience who doesn't have the title of design ops, what would you recommend they do now to try to improve things without having the authority of being a design ops leader?

[00:07:23] Z: That is actually very common; it's how most people started. For a designer, only a more mature, larger organization, an enterprise, has the ability to hire a design operations role; it's almost a luxury. In many, many companies, people start by just doing the work. To me, the important thing is to do the work, find a partner within the design team to do the work with you, and then capture and tell that story, to show success: why the organization needs a design operations person, and how design operations can help the organization, help the product team and help the design team to ship products and grow the design team. So do experiments, small experiments, but importantly, tell that story. A huge part of my job is also telling the story of why we're doing things, what we're doing, and how that made the difference.

Measuring success

[00:08:23] Host: Excellent. That leads me on to my next one, about success and metrics. You mentioned, let me know if I'm right, was it 88 projects that were touched by the office hours? I can't remember the exact number.

[00:08:36] Z: Exactly.

[00:08:39] Host: Perfect. How do you measure and communicate success? Yes, that's the number of projects touched, but do you have any way of identifying that those projects had a beneficial outcome from it? What I'm trying to think is: moving away from just a task base, "we did X, Y, Z," to more of the outcome, "this is what was achieved." But how do you know what would have been achieved if you hadn't helped them?

[00:09:08] Z: Here's the thing. That's why, when I talk about measurement, it doesn't have to be super scientific. It can be scrappy. The 88 is one factor of how we helped. You can articulate that for those 88 projects, if we hadn't had these office hours, the project would just have been done by engineers, and whoever can pick up a project would get it done. But now we have 88 projects that designers actually worked on and improved. So this is one aspect.

[00:09:38] Z: But there are other aspects of this whole office hour. People bring in different kinds of projects, and the designers might say, "Oh, I know that we have a design system. I already have a component ready for you," and they can just put it out very fast. That goes to the other side of the measure: saving money or saving time for our engineers and our product team when they don't have an embedded designer. So the measurement is never one-dimensional. There are always multiple data points we can leverage to tell the whole story. If you think about the entire span of the office hours, a few months, we touched 88 projects. That's just the number of projects touched. We can also look into how many projects out of these office hours were able to utilize component libraries instead of just doing a one-off thing. There are multiple ways to measure.

[00:10:29] Host: Excellent. We've run out of time, and I could keep chatting about this. I love this topic, so I could keep chatting for a long time. But thank you, Z, and thank you for sharing. If anybody hasn't seen the talk...