Changying (Z) Zheng - Connecting Teams Through Ops

Speaker A: A lot of time we say business need to prioritize design, need to value design. When we get there, we haven't been able to really show our value. We have a lot of uh, strategic approaches to everything. We say, oh, we were not given the opportunity but a lot of time. We also haven't done justice to the design industry. We were there and we didn't provide the same equal amount of value to the business. And that's why eventually we lose our Chair. Foreign.

Speaker B: Welcome to another episode of Brave ux. I'm Brendan Jarvis, Managing Founder of the Space in Between, the behavior based UX research partner for enterprise leaders who want an independent perspective to align hearts and minds. You can find out more about me and what we do at thespaceinbetween Co NZ Here on Brave UX though, it's my job to help you to keep on top of the latest thinking and important issues affecting our field of design. I do that by unpacking the stories, learnings and expert advice of a diverse range of world class leaders. My guest today is changing Jung, though you might also know her as Z. Z is the Design Ops lead at cloudflare where she's been scaling the operational foundations of one of the Internet's most well known and recognizable infrastructure companies. Starting as a team of one, she's helped grow and mature the organization's design and research capabilities all all while championing people, process and platform as the connective tissue of a high performing design org. Zee's journey into design ops has been anything but linear. Trained as a graphic designer, she's worked across agencies, taught user experience in higher education, run her own very successful retail business and contributed to product design at ah companies like Akamai, VMware and Nasdaq. But it was through her growing interest in enabling others that she found her way into Ops. Whether it's onboarding, tooling, scaling design systems or increasing research maturity, Z brings a thoughtful strategic lens to the often invisible work of making design teams thrive. Her talks, like those at the DevOps conference and the Design Ops Summit, have helped shape how people understand the evolving role of design ops, especially in highly technical environments. And now she's here with me for this conversation on Brave ux. Z, A very warm welcome to the show.

Speaker A: Thank you for having me here Z.

Speaker B: It's a real pleasure to have you here and I was curious to start by asking you, how did you come to use your mononym Z. How did that come about? Did you just get sick of people not being able to pronounce your name correctly.

Speaker A: That is actually what happened. But it's a very controversial topic actually between me and uh, my husband because uh, it's because people can't pronounce my last name. And then it started short by Z. And this has been over 30 years I've been using Z. But my husband, who is actually not Chinese, always felt strongly about uh, not using my Chinese name because people cannot pronounce my real last name. And then, But I say look at it this way, this is helping people to pronounce my name. Also it became a brand when I'm doing all UX related.

Speaker B: I mentioned in your introduction, Z that you have had a bit of a twisty turny road to design ops through your career as a designer and an entrepreneur. Um, you have also, as I mentioned in the intro, taught user experience. So you know business and design very well and now you're in this quite pivotal role in design ops leadership at Cloudflare. When you think back about the arc of your career, what's the common thread, if any, that you can, you can see in these experiences?

Speaker A: For all of the things I do, I, it really led me to what I do today. So people always say, oh, if I learn this, do this, will that progress my career? Right? So people think about career progression or think about that. But for me, everything you learn, everything you do will make you who you are and then eventually lead you to where you are. And uh, it's the right thing for today, whatever you're doing. And uh, so if it's no longer a fit for your personal growth, then you look for the next thing. So there's never a wrong way to go about certain things. And uh, I think typically people tend to think of a very straight uh, career trajection. They're definitely that path for a lot of people. But for me it turns out to be a very different path and it worked out perfectly. So everything I do, I always gravitate towards how things work, how do I help people, whether that's agency work, designer work, entrepreneur. It's always thinking about how do I make things work, solve that problem. So eventually led me to operation, which is all about helping people out, solving people problems.

Speaker B: So that is the context in terms of helping people out and uh, solving their problems. That's the common context across these different things that you've done. But you mentioned that there's the sense that you have of whatever you're doing in the M moment is the right thing to be doing in that moment. And to me that sounds like a very Calming way of thinking about where you're at at the present moment in your life. Are there any underlying philosophies or philosophers or influential people in your, in your life that have helped you to shape or adopt that point of view that you hold?

Speaker A: I can't think of someone on top of my mind immediately. But what I think it really influenced greatly for my um, perspective about this is during my entrepreneur um, time and running a retail business, it's actually food business which is very, very risky compared to doing standard ux because people could have died if you put in the wrong elements or ever the ingredients or people could be allergic. And uh, they were a time that people will call, says, oh, I had something, I uh, had to go to the hospital. I didn't think of the peanut allergy or something like. Right. So now I look at things, what I do is like a, is it super urgent? Is it life or death situation? It's not. And then uh. Could this be a mistake? Yes, probably could be a mistake. But I'm making the decision with the information I have at this given m moment. So it is the right decision.

Speaker B: So from that very much high stakes situation I think you were doing, it was dairy free food, right?

Speaker A: Exactly. Dairy free frozen dessert. That's what is essentially it's a dairy free ice cream. It's a little bit early, before the time of a dairy free ice cream. But you cannot call it ice cream.

Speaker B: Got it. And I can imagine getting those calls from people that are, you know, saying that something that they've eaten of yours is taking them to the hospital. That's sort of a next level of intensity in terms of the day to day operations. And I think you're a COO in this company that you co founded, right?

Speaker A: Yeah. Running all about operations.

Speaker B: Yeah. I mean funny how the thread, you know, you can see that thread comes through to where you're at now. So it seems that you've borrowed that way of handling um, those situations and brought it forward into your work now where it's not life or death or it doesn't have that, that same potential risk, uh, in the work that you're doing. How has that mindset influenced how you've led your people in your design ops organization?

Speaker A: Yeah, people always think I have a very calm way approach things and uh, there's never drama. But in reality any work there's always drama. But it's how you handle the drama, how you actually uh, face the drama. So same thing as I lead people, team or people and everything I try to Bring that perspective into everyday work as well. So is this perfect? And maybe not. Can you walk away, think about it, sleep through tonight and come back? Because it's not a life and death situation. So far after my dairy free business I haven't really come across. So if this button is in the wrong place, if the this person said something, it's not life and death. Let's think about how to handle it. So I bring that calmness into the overall day to day craziness into business and everything. I think that's helpful. And then when I'm calm, people I work with will be calmer and the people report to me will be calmer. And then when you are calm, you don't react to things and you don't say things you regret later.

Speaker B: Yes, that's 100% correct. It's interesting that um, being calm is actually quite infectious. It's interesting to think about the context of the work that most of us who are listening to this, including uh, myself do you know there's like we're talking about, the stakes aren't as high as we perhaps can be led to believe, but nevertheless we seem to acclimatize uh, to the drama of the day. And things can feel very much um, critical and yes, some things are. But I'm curious to know if you've identified any common anxiety inducing situations in your role as a leader that people perhaps listening today we could reflect on um, in the moment now and see them for what they are when they next come out. Are there any sort of common patterns and behavior that you've observed, um, that would benefit from a bit of that?

Speaker A: Yeah, that anxiety is real, right? Everyone, you will feel that anxiety. And then a lot of times what I think uh, is that we will see things our own perspective just by default. We only see things how we see things. But for me I always go back to my entrepreneur time because that's totally a different type of work. And I was actually in trench doing like scooping ice cream sometimes. Right. So in that level and then uh, I got to meet a lot of people who I normally stay in my design firms and everything I would not come across. So I start to hear their story, got to understand their perspective. The most important things to help me to understand, understand there's always, always a different perspective. And most uh, likely I'm not seeing that. So step back, calm down, think about it, think about it a little bit from other people's perspective, help me to address things, to approach people. And I definitely trying very hard to Bring that perspective into my everyday work as well. So sometimes I could be purposely contradictive. Maybe I don't believe it, but I'm going to say anyway, just to get people to think about a different perspective. And I'm, uh, trying to show that to people I work with as well. I tell people, you know, I will always challenge your perspective. Even I don't agree or I do agree. So I think that helps us to start to see different ways of seeing things. And I definitely sometimes go out, I said something, someone will tell me. So, oh, gosh, I never thought that's how people are actually taking it. Right. And, uh, also another thing. I think during COVID time, there's a lot of a change in the way we work, in the way we handle people, dealing with people. We did lose some of the social skills because of that. And then. But the challenge is also, we don't see this sometimes we're just on camera. We don't see a lot of a subtle body gestures, the facial expressions and everything. So you would say something. The receiving end totally took it differently. And then I would love it if they tell me, hey, do you mean this? Do you mean that? And it heard because you said this. I said, oh, gosh, I don't mean it. A lot of times people said things a little bit hurtful, but then it turns out I don't mean it. I just didn't know that's how you took it.

Speaker B: So, yeah, we place that value judgment on what's coming in, uh, almost reflexively. It's funny you mentioned also the change to working more remotely. When Covid came in, I had one of my previous guests, Amy Santee. She'd seen a recording of me delivering a talk on a real stage. And then she realized that I wasn't just someone that, uh, existed from the shoulders up on this, uh, podcast, on these recordings. Like, I'm actually someone with hands and legs. And this real person, which doesn't, of course, doesn't translate in this context as well. You can't see the whole person physically, but I think what you're touching on there is you also can't intuit or receive the full emotional signal that's coming from that other person. When we're multiple boxes on a screen in a meeting. It's just we're not, um, well adapted to the current context.

Speaker A: Exactly. We learn. We had to learn to adapt that.

Speaker B: Yeah, yeah. And I like to think that we're all getting better at it. And you've certainly been doing some great things at Ah, Cloudflare building this practice and I wanted just to touch on design ops now in terms of how you've framed it before. And that is, and I think I mentioned this in your intro as well as service design for design teams and the goal I understand from having listened to some of the things that you've previously talked about and now I'm paraphrasing you is to create an environment where designers can excel. And when you think about the environment that you have created for designers at Cloudflare through the work you've been doing in ops, uh, what has that environment where they can excel, what does it look like?

Speaker A: So you mentioned that I think design op is service design to the design team and the reason it came from. I was a designer, that's my route. I was a designer for a long time and uh, I take that skill into that operation perspective as well. So if you think about designers you think about double diamonds, you think about uh, all the design practices. So I actually applies really perfectly into the operation world as a service designer. So I certainly hope, this is definitely my hope as well to support a design team to build a culture that designers and the design leaders can thrive and uh, people first. And also uh. I'm hoping designers and design leaders can also start to think about the different perspectives. Is the business perspective as well essentially designers since I was an entrepreneur before as well. We essentially serve the customers or you know our. We say users customers definitely it's important but also we serve the business who hired us, paid us to do the job as well. We need to be able to see these different perspectives to be better designers and hoping that come across the team I support as well bringing in different perspectives into the team help them to see differently. But uh, definitely I want to make sure that our team is people first and everything after.

Speaker B: Well let's talk about that perspective in particular the perspective of the business. What practical steps did you take? Perhaps it was early on or perhaps it's something you've done recently. But what practical steps have you taken that you feel have led you to be able to build a more productive relationship with those stakeholders?

Speaker A: Again from a designer's perspective. Right. So we always being taught or uh, at least that's our belief that if you think about the three leg stool and working collaboratively with the cross functional team with engineers and the PMs and design. Right. So we would think a design always represented the customer user and that is true in certain extent and then but designer I said that before as well say designers need to represent the users, everything. But on the other hand, uh, we need to understand the business perspective. PMs bring in the engineers, bring in their practical skills as well. So in practice building a design team, we want to help the designers to be able to storytelling. And then so if you talk about designer designers that we are very custom to talk about, this is what I did, this is this, this is this, and this is the final result. Uh, and then even you think about interview, portfolio, review and it's tend to be this process, uh, we talk about this process. But I'm trying to help our team to think about storytelling. Tell the end first. Tell the story, the end, the uh, end result first. Because that's what my PM cares about and that's where my stakeholder cares about. And then go back, you can talk about, explain why you did what you did. And then so this goes to all the levels from entry level designers to presentations to support my vp. And then when I help say my VP to prepare presentations, I was trying to think about what's the connection? What's that tell the end story, what we're trying to tell. And I'm hoping that through all these kind of pushing storytelling which designers understand, actually have people start to think about the business perspective of design.

Speaker B: Yeah. Starting with uh, what's in it for them first. Right. Rather than why do they care? Yeah, why, why, yeah. Why should you care about what the words coming out of my mouth are? I sense that there's uh, an element within and it wouldn't be just designers. Right. But that's the microcosm that, that we live in, that this need or this want to be understood. Which is why process seems to get elevated. Like the, all of the, um, what should be in the appendix gets put into the body because we want people to see and understand and appreciate all the work that went into the outcome. And what you're saying is that we need to lead with the outcome and then we'll get the opportunity, if they're interested to be validated, uh, in the ways that perhaps we, our ego, um, seeks some of that. Now of course I'm wildly generalizing here, but it seems to be a common pattern in designers that we don't always get what you're talking about.

Speaker A: I think so it's in a way, I know for years we're talking about we want a seat at the table. Right. So we always looking hours. We need a seat, we need a seat. And then. But the thing is that. So you finally got a seat. Even you bring your Little suit there. You finally got a seat. So what, why you're here, right? So you got to be able to actually sit there, talk the same talk with the rest of people. And I think uh, this could be very controversial in a way. So a lot of time we say design, business need to um, prioritize design, need to value design. And so when we get there, we haven't been able to really show our value. We have a lot of strategic approaches. Everything we say, oh, we were not given the opportunity but a lot of time. We also haven't done justice to the design industry. We were there and uh, we didn't provide the same equal amount of value to the business. And that's why eventually we lose our chair there. I think uh, it's both way. I think a lot of time from a designer's perspective, we talk a lot, we need a seat at the table. But uh, when you have that, so what right, that also go back to my entrepreneur time because I was a designer and I was the founder, co founder, everything. So I have that seat, I understand the business so I can make that decision and uh, bring in the design practice, what I do. And I think uh, design founders are great because they can see the business value. And I think uh, to keep our seat at the table we actually absolutely, absolutely have to be able to elevate our speak storytelling to that level. Not just about process. This is what we did, this is what hear from our customer, from a user. That's why we have to. Yes, that's all true, but cannot lead just from that lead. But uh, this is what we'll do for business. And because this is the right thing for the business and this is, is the right thing for the customer.

Speaker B: Yes, it brings you much closer to achieving a broader view of the reality facing that business. If you can embrace it that way. Yeah. And I was wondering because you've both been a practicing designer, you've been a design leader in terms of you've had VP and other senior, uh, directorial type roles in design where you would have been leading other designers and now you're in design ops leadership. My curiosity here is design ops. Is design related, very closely tied to design, but it's not design. Is it easier for you to be taken more seriously and have more business minded conversations with your stakeholders in your role in design operations than it was for you to have when you were in design? Strict design leadership?

Speaker A: I wasn't sure if easier is the word, but on the other hand it's uh, helpful for me to be in that role because I can understand designers. Designers have a very different way of doing things, have a very disciplined practice outside design field. Might not understand, might not know. So if you think about engineers, they have their practice, but then there's the tickets. Then why design tickets take so long? Why design does not have 500 different steps before we can ship the thing to anywhere? Right? So there's things. So I understand designers, but on the other hand I also understand the business, that the urgency of the business. I have contract commit. I have to meet this. Because if we don't meet this deadline, all the research is great or everything is the right thing, but I lost this contract and that's how I pay you all, uh, to do the work you do. So I think it's helpful for me to put bring these all the perspective together to help people to balance it, to prioritize things. I think in an operation, perspective, able to prioritize things, ruthlessly prioritize things is helpful. When I started ops here, design team tend to just at the time we were a lot smaller as well. We were just taking orders in a way, taking tickets, doing it, ship it. And then designers felt like really burned out.

Speaker B: So.

Speaker A: So I was able to start to say, hey, can we start to say no and say more no, but focus on, um, prioritize the more strategic work, more impactful work and then balance with some quick wins as well and then to be able to demonstrate value as well. And um, so I think it's easier for me to do my ops job, but I wouldn't say exactly, just easier. I put a lot of efforts to make it easier. Easier as well.

Speaker B: Absolutely. It sounds like you're working on the same problem but from a different angle. And you can use perhaps slightly different language and tools than you otherwise might have if you're in the strict design role. Um, let's talk about when you first started at Cloudflare, because you mentioned there that the team was a little overwhelmed. And I seem to recall seeing somewhere some ratio that was quite, quite a big ratio between, I think it was designers and, and engineers. Tell me, what was the state of that ratio when you first arrived and how are things looking now?

Speaker A: So at the time when I started, the design team is extremely small. But then, you know, a lot of tech companies, that is very common. It's not a surprise when I start a team. And uh, so at a time, not only design to engineer ratio is really out of proportion. Design to PM ratio is also very out of proportion. And I know that in the Design field we prefer for one designer to ideally 1pm but maybe even uh, if it's a little bit larger uh org, maybe one designer is at least no more than supporting couple PMs because that's how you can actually work. And then context switching and everything. But we definitely even in the org we still not ideal but it's like one designer to potentially in certain areas 5 to 7PMs and uh, it's really hard for designers to context switching and then actually make it work. So right now we're still not ideal. We're still consistently talking about ratio and everything. And we are maybe like a 1, 2, 3 in certain area 1, 2, maybe still 5 in certain areas that's for sure. But now we're focusing more on uh, with the people we have. And uh, we have to draw that line and draw the hard line. These are the things we can support and certain things we cannot prioritize. Headcount is always a uh, tricky question, tricky issue in a way. Right. So it's like uh, we're always talking about ratio. There are certain companies has better ratios but so we don't have the best ratio. So what do we do? And that's prioritization. So it's a balance now. And uh, so I still think uh, we could do much better and you will still hear our design leaders that our ratio is really not ideal. And it's still very true because company grow so fast. Our team when I started is about 12 or 15 people now the design side we have about near 40 including managers. And then we also um, included content to our team. So the entire product experience team now is about 60. It's actually a little over 60 people.

Speaker B: So is the ratio improving overall?

Speaker A: A little bit, but very small improvement in a way. That's just the reality still. But the work improved a little bit because the prioritization.

Speaker B: Okay. And maybe, maybe prioritization is a big part, if not the entire part of the answer to this next question which is around um, something that I heard you describe in your DevOps conference talk, which was how you transitioned the model at cloudflare from the design organization being very reactive in terms of a ticket, uh, taking type mentality to being more proactive. And I was curious, I mean obviously you've spoken about the importance of prioritization a couple of times now. Um, maybe we need to go further into that. But what were the practical steps that you took to enable that shift to go from reactive to more proactive?

Speaker A: Designers believe that to prove our value we want to be helpful. So one day tickets or the requests come to our way. We want to say yes, we want to be helpful and then we believe we should be involved everything. So we have that tendency. But the other side of it is that we become ticket taker and then we get really busy and then we get um, overwhelmed and then we don't have time to think about strategic work because we're just doing the work in day to day. Right. So I think the most important thing is really to start to say no and uh, um, at a very early stage and I start to push the design team to think about um, what we can do, support, uh, fully support. But for the things we can't, we start to implement what we call office hours. Those are the kind of like a consultation time. So we can't support you but we want to be helpful. So come we can give you some ideas, give you some guidance and then you go to do your own ideal. No, definitely not ideal. But in a way that we were able to. We're not just saying we're not going to do it, say no. But we're saying but let me help you out the best I could. And uh, so people don't feel like oh, designers are always bottleneck, they always say no, they're jerks or anything like that. But it's more we want to be helpful. Right. This is the best that we could do and let me help you out this way. And uh, so we implemented office hours but now that our team got bigger so the blanket version of office hour doesn't work anymore. So what we actually transitioned with uh, my design leaders that talk about it and we have more managers as well. So. Right. So the managers can help triage as well now and then we implement a more domain specific office hours and then we have our design lead running office hours as well. So we have more office hours but more focused. So it's not just anyone have a problem in can bring in but it's more focused. So we are continuously iterating But I think all these kind of the approaches are fully embedded to support the most important work. But office hours or consultation time to do our best to help people. But that also cut down our burden in a way for the designers because uh, we make it very clear you can come to the office hours say it's an hour. So we have to talk about the things within this hour. There's no homework. It's not like you come here, I uh, take another ticket back to do or anything. This is the hour. Let's see what we can do, get it done in an hour. But obviously there are time things really big, really important come to the office hour. Then we encourage our designer to encourage those people to talk to design managers. Maybe they can help to prioritize, go to talk to the product leaders, maybe they can help us to prioritize and then to focus on, um, whatever as a team, we decided is the priority. So there's that solution as well. We do want to be helpful. We don't want to be jerks.

Speaker B: Yeah, yeah, yeah. And it sounds like, and correct me if I'm wrong, that you never give a hard no. Never.

Speaker A: Never say never.

Speaker B: Right.

Speaker A: So I can't think of a time people are just outright says never no, but in a way we are saying no. And, uh, they are actually. I wouldn't say we never say no. There are certain situations we'll have to say actually we really can't. We don't. It's too big. We can't. And it's not prioritized. No, we can't. And uh, so we will say no, but kindly. You don't have to be a jerk to say no. There are different ways to say no. Right.

Speaker B: So, yeah, perhaps there's something deeper in there. What is it about the art of saying no kindly that you seem to value in the way in which you've approached this practice personally?

Speaker A: I don't know. That applies to everyone personally, I think, um, a way to say no is that, ah, I hear you out and, uh, I hear you and uh, I understand your challenge, but I really can't help. Either I don't have the bandwidth or I don't have the knowledge, or it's not the priority. So. But definitely hear people out first. They are again, perspectives they're bringing their perspective, their need is real, whether it's their priority, because that's 100% thing they're doing that is their priority. Just on a, uh, bigger team, I would say we don't have that many people. We only have limited people. And uh, if it's not a priority, unfortunately we can't. Right. So we are saying no. But I really hear you. And working together, see what we can do. I can give you some ideas or can point them to resources as well. And uh, with all the new tooling coming up, there will be better way to support people, I'm hoping. I'm also big on automation. If anything can be automated, let's do that. Saves time. And that's also why for a lot of, uh, design system team actually roll up to ops in our situation we don't design system doesn't really roll up to us and a lot of team design system actually roll up to up, especially smaller team. The reason is because that serves the foundation and basically giving us a way to help people out without actually doing everything for them. So there's other ways to say no.

Speaker B: Well let's talk about foundations or in another sense let's talk about pillars. Because I understand that much of the work that you do at Cloudflare is shaped by the three pillars of people, process and platform. How did those three things become your foundational pillars and why have you kept them as those, those foundations?

Speaker A: I certainly hope so. And for me people is always comes first. Uh, everything we do and it's people, right? So internally or externally, customers and we need to prioritize that first, right. And then for operation people, we are process people in a way. Process can be allergic word for a lot of companies because people think that will slow things down. But from an operations perspective, processes actually help us to scale and help us to have a rigor to scale and uh, process for process sake. It's not helpful. That again goes back to the service design perspective, right? So you intake, see what process makes sense, iterate and then implement that process, kind of scale that. And then once you have a process that goes to the platform side, right, so you can scale the team, build the foundations and think about how you can support the business from a platform perspective. Think about program. Now we're not thinking about project, project, project. We start to think about bigger picture, the program but in return that help us to elevate design because we're start to think more strategically, enable the team to do more strategic work instead of project, project, project. So those pillars I think will always stay true and uh, especially important for the designers to understand and why we do it this way.

Speaker B: What you've described there, it ties into the framing that you've used of connective tissue, the connective tissue that Design Ops represents within the design Org. Have you found that this connective tissue can be successfully created either through direct experience that you've had in roles or in um, other people's stories that you've heard without a Design Ops practice? Or is this kind of connective tissue only able to be crafted if you can have some um, separation from the design Org itself to make that happen?

Speaker A: I don't think it's ah, one size fits all being connected tissue, you don't have to be separated from the design. You could be the Connected tissue within the org. It's really about um, intake, learning what other people's perspectives are and build that report and then see the big picture. You start to see different parts of the org, you start to see the pattern, you start to see the strengths of different parts of the org and then you can connect all different parts. So that could happen within design. And uh, I also see really great success when it's outside the design. So I was adamant about design operations stay within design Org for the longest time. So interestingly last year our operation got consolidated into a product operation everything. So at the time it's like, well if you want to support, support design fully, we should stay with design. But then the benefit of uh, being larger in the product work side, then you can see the bigger picture. You get to see how PM side work, how engineer, how infrastructure work. You get to see that picture. So there is that and there's definitely trade off. So but anyway we got moved to the product Org and uh, I started to do a lot of uh, crossboard thing. The same thing still being the connective tissue but now it's connecting more orgs, larger orgs and different parts of org in return. I always tell people, you know what, I'm biased because I was a designer. I'm always rooted in design in a way. But on the other hand by connecting the org it really benefit the design team tremendously because we actually see even bigger picture. And so I think it's helpful. So it could be within the design team. If you have a really large design team, definitely. I think a dedicated team. Designing ops is really um, beneficial. But if you have a mid size or something, it's possible. Design ops is part of the larger operation. So where you sit is not the most important thing. How you see things connect that is actually more meaningful.

Speaker B: Well let's talk about that aspect of it, the perspective aspect of it. In this Product Ops focus that you now find yourself in, do you have colleagues that have come from say product or engineering alongside you or are ah, you still the tip of the spear, so to speak and leading that Product Ops organization.

Speaker A: Now we're side by side now actually I get to learn from uh, people from a different perspective, bringing the operation perspective. Definitely Product Ops is a very defined discipline. In a way it's operations different. So the focus is different as well. Design is design Ops has some very specific thing. But what I learned a lot from people who they are not designers, they came from either uh, PM side or TPM side or uh, some of them come from psychology side or whatever that is. Right. So that's not uh, whatever they bring again, they bring in their experience. I feel that I learned a lot from those perspectives, how they run Roadmap and it's very differently than the way that design operations designers think. I've, as a matter of fact, so I learn a lot. But then on the other hand I find interestingly design ops, we always talk about uh, uh, how we work together, how we get things down, how we elevate design. Right. So I bring that framework into a product operation as well. So how we work together now it's a larger team work together, how we work together, how we get things done and same thing how we elevate the org we support. If that's not design per se, it's a larger work. So I think it goes both directions as well. But definitely we're not, I'm not like the tip of that, it's really side by side with other people and I feel I benefit a lot from that as well.

Speaker B: So the triad or the three legged stall holds up well as a way of working within a, uh, product ops organization as it works within. Okay, yeah, that's interesting.

Speaker A: Yeah, I believe so.

Speaker B: Uh, forgive me if I've got this wrong, but when you started at Cloudflare, you were a team of one.

Speaker A: Mhm.

Speaker B: And now you find yourself as one of the leaders within the broader product ops organization. So you've come a long way. Right?

Speaker A: I still don't have a large team. Operation is always a small team because the operation is uh, supporting a lot of people now. I find that in the product op side and um, I still have a very small team, but on the other hand I supported a larger team now. And so it's a relative scale, I

Speaker B: guess that larger team, the growth that you've helped to enable, is a symptom at least partly attributable to the success that you've had in the role that you've been performing. And I noticed that you'd been there now, I think for four years or so at Cloudflare. Right. So you've been almost five. Almost five. Right. So you've definitely been demonstrating value. That's what I wanted to get into is when you started. And you know, the really, the pressure comes on, right. Like you're new in the role, you've got to come up to speed with the company, you've got to, you know, earn your stripes, so to speak. What did you decide to focus on

Speaker A: first and why at the time, again, I started doing at the beginning of the COVID Right. So it's again the service design perspective. What is the most important thing for this group of people I serve that needs address those first and then you can think about the larger problem wherever you believe that should be the priority. The priority is address immediate needs. So when I came in, the biggest need is actually designers. Burnout is Covid new way of doing things. Everyone. We used to be an office first company. All of a sudden they were 100% remote and no one knows how to deal with all of these things. That's the biggest problem. And, uh, since we are not seeing everyone every day together and uh, say project comes in, we don't see people get burned out. We don't hear people. Because if you're in the office, you see people frustrated, they're overworked, they stay long time wherever. But when we became entirely entire, um, remote team, you don't see that unless someone say, you wouldn't know. And so the biggest problem is the burnout. So we have to address that first. Once that's dealt with, then we can take next step to think about what's the next large issue. I think, uh, balance that strategy and also immediate needs will help you demonstrate success so your team build that trust. Okay, so you're not just bringing in whatever practice you know, it works, but you're actually hearing me out, what I need to help me out. And next thing, when I reach out, people say, hey, hear me out now. Well, let's try this thing. Can we do that? Then I'll build up that report already so I can do the next big thing. If it's a big thing.

Speaker B: Yeah, you're investing and building up, uh, those deposits of rapport that you can then call on later. That makes a lot of sense. You touched on a little earlier Z on this, uh, reticence that some people have towards process. Now clearly you were a practicing designer. You have designer's mind and creative, um, mind as well within you. And one of the challenges that can happen within organizations as they mature is sometimes people perceive that process stifles their ability to practice their craft. And those can be tricky things to balance. How have you, if at all worked to be mindful of that trade off between systemizing and enabling designers to do the problem solving in the way that they would most want to do service design again.

Speaker A: Right. So if you implement a process and uh, from top down, sometimes there's necessity, but it will be hard. People don't understand why is this process. So if you worked with People then they feel they're part of it and uh, they can actually participate, they have input and then they are more willing. And then you tell people, let's iterate. This is the experiment. Let's iterate and let's uh, see how this is going to work out. And then they're part of it again, so they're more willing. So now it works for your team. Let's spend that to next team and scale that and then see how that works. Yeah, so I think it's really again service design approach, bring them in along the way and then work together. And I think it will be helpful they understand why the process is important.

Speaker B: So Z, you were talking there about the importance of getting alongside designers and uh, I suppose helping them to feel listened to and contribute to the change in particular process or tooling or whatever the changes that you're trying to implement. I wondered, seeing as we were talking about what sounded like quite ruthless prioritisation earlier on. Right. You just physically can't do everything and serve everyone's need and sometimes you have to say no kindly in uh, order to focus on the things that you can have the most impact on. Is there also uh, a parallel here between how you've chosen to work or selected certain teams within the organization to roll out certain process or tooling changes first because you've identified them in some way as perhaps being more receptive or being good candidates for that type of work?

Speaker A: Yeah, absolutely. And it's the same thing as prioritization for designers. Design ops also needs to prioritize our own work, everything. Right. So find the right team to experiment with us is important. Different teams will work differently and uh, you want to observe how they work and then for a particular process and you want to try with the team who is the right fit to experiment with you. So definitely prioritize. That example would be. So if you think about tickets and JIRA is our tool, the thinking is good. The thinking is that uh, our designers should be embedded in the team and then support all the teams. And then we shouldn't need a design ticket, we should be just engineering tickets or the ship tickets that we all roll up. The thinking is not wrong. But our org doesn't work that way because we are at the time it's more of a centralized work. We shift designers everywhere so we can't see what designers are doing because they're all part of their projects. Everyone has a different label, different uh, type of tickets, different projects and everything. So we can see our team is doing then I Cannot articulate. Our ratio is not ideal. I don't know. Right. So because we can only count head count numbers. But then we don't know in terms of project how can we support it. We don't see our work. So then my goal is well, how can we visualize our design team's work? And then my idea was that well, let's bring tickets into a uh, design ticket. Right. So then if you just tell everyone say hey now from today you'll have to start a design ticket. You can do that. But habit is hard to change. And so I had to find the team that they are more willing to experiment that uh, maybe the designers managers felt the pain. We don't have a way to show our work also let's try this, let's try. So let's capture our work separately and uh, can we start to report on our work and then to figure out and if that's the right way. So I found the team and then we started to do it and then we ran to the next one and the next one. It's a small org at the time given that so it wasn't too hard to roll it out. But still I found a small team and the next one, next one very soon. So okay, now we can say the process comes in. All the design team need to start design project. I think I did a uh, talk dev talk way back talking about Jira structure. People actually at the time asked me a question. Oh, you know if designers is working with the uh, agile uh team and uh, wouldn't that be better? They work in their own team, have the ticket there. So yes, for some org, I came from an org, Agile Org. That's how we did it. It totally makes sense. But if you think about our team's need actually make more sense that we can visualize the design work separately. So we would design tickets, engineer tickets and the PM ships as the umbrella to help this. But definitely prioritize the team, find the team and then roll out the process. So prioritizations work for operation as well.

Speaker B: Yeah, I think after having had I think 170 odd of these conversations, there seems to be this desire within the broader community to come to the one right answer. And if there's anything that I've learned through these conversations with clever people such as yourself is that there is no one right answer. There might be some core themes that are useful across all organizations to employ, but really it's so highly dependent on the organization itself. That team that you found. Yeah, it really depends. Right. I Mean, this is such a. That's a typical consultant type response. Uh, right. But it's a. That answer because it doesn't give them certainty. Uh, but I think that there's enough clarity over the types of behaviors or mindsets that are useful to bring to this type of work. Um, that you've even shared today about your approach at Cloudflare and some of your previous experiences that are of value to people that are in similar situations, but not the same situation. I want to come back to that team that you were mentioning there that you used as a friendly way to adopt something that they were willing to embrace and therefore you're able to more easily roll that out across the wider org. I wondered if that had, um, any role at all to play with. What I understand is called Cloudflare's Growth Week, which is a mini conference that you've previously used to spotlight certain team work and that seemed, from what you were saying previously, to be quite impactful for your objectives. What can you tell me about, uh, Growth Week and how you've used that, um, to help, uh, grow, um, and bring people alongside you as you've developed the Design ops. Org.

Speaker A: I'm so happy that you found that about Growth Week. It's one of my passion projects in a way. And that's the intention exactly, is that to elevate the team's work, also giving the design team breathing room to learn. Designers are so busy doing work and all the time, right. There's just endless work for designers. If we don't, um, purposefully, consciously carve out time for growing, learning, and we will not do it, designers won't have the time to do it. And so we started to do same thing as during the, uh, Covid time. People are burned out. So how do we address that? Right, so where's the space we carve out for people to learn? So we start to do very small scale within the design team and then we go grow that to inviting PMs in. Now we actually opened up to the entire company. We just actually had our Growth week a couple of weeks ago for this year. It's the fifth growth week we're doing now. And, uh, I definitely see more discipline, um, other parts of the org people coming in, but it's really carving out a space for designers to grow, to learn. We used to call it Design Growth Week. Now it's just Growth Week, actually, because it's a broader sense. We try very hard to invite cross functional partners coming to talk as well. So designers could learn other things as well we work with our vendors coming in to do some training to help us as well. Every so often we'll invite um, industry speakers to come in to talk about uh, whatever the passion thing they're working on. And uh, we as a team we're a SaaS company, software focus and everything. But there's the fun creative part. Like you earlier you mentioned like uh, how do you balance the creativity and then also the rigorism of the could be a little bit boring doing a SaaS project. Right. So we invite people coming in and one of my ex coworker working for lucid car company so coming in to talk about interface for cars. We have nothing to do with our software development but designers get excited about things. Oh maybe this approach, we can actually think about our approach when we approach, assess projects, assess the software project, everything just really broaden the uh, way uh, of exposure. And so I think the growth week has definitely been my passion project and continue pushing it but that I could not do it alone. I need people come to speak about it. I need people to come to participate as well. To be able to have people, people participate. We need to have all the manager support, they need to tell all the cross functional teams that hey, this is our growth week. You're welcome to join as well but we are not going to be doing busy shipping work. Some of the meetings have to uh, be moved and everything. So it takes a lot to make this happen. And then I still think it's a small scale but I definitely hear a lot of positive feedbacks and people really enjoy these learning opportunities you touched on

Speaker B: out of category learning and the importance of that. I mean clearly having domain knowledge and category knowledge for design is really valuable, uh, particularly the more technical you get. But having that inspiration and those things that can come in from the outside and provoke different ways of thinking or uh, approaches to problem solving, the sort of big borrow and steal type mentality can be quite useful when it comes to getting around the curlier issues. You also mentioned how it was difficult. I'm not sure if that was the exact word you used, but I got the sense that a lot had gone into making this happen. You've done it now for five years. It's required from what it sounded like a coalition of people to come together around this to make it a reality. It also sounded like you literally block off the week to minimize the amount of work that you're shipping so you can focus on this growth led endeavor of growth week. How have you managed to sustain that? Because one week it just is, it's just one week. Right. But it's one week out of 52. All right. So it's quite a significant amount of time when it comes to SaaS businesses uh, operations. So how have you managed to sustain uh the belief that this is a worthy and valuable way for the design Org to spend their time?

Speaker A: I'm still working on that in a way and so I do have a very tight needed team and the design org is extremely supportive. The design leader I work with uh, and is extremely supportive understand the value of it. So I have the executive buy in from the design side. So now then the next challenge is uh getting the cross functional side. The PM side or the engineer says hey the designers are all gone for a week and uh, I still have my deadline. What's going to happen? Right. So then I need a design managers to support as well to go continuously articulate that uh with the cross functional team I try to prepare that ah ahead of time as well. Hey give people the heads up. Hey this week knowing down the road in a month we're going to be out for this week. Remember we have our growth week. You are welcome to come as well and join us and uh, so learn with us and have fun with us as well. Right. So it takes some prep to articulate that. Take a lot of uh collaboration with uh our supportive design managers to go out to reach out their day to day partners as well. And uh communication is really important to build up that momentum. We invite other cross functional team members to come to talk so they bring their people. So I'm going to do this growth week then you all can come to listen to my talk as well. That opens that and uh communications are preparing people. We now actually send it to the company newsletters the week off they will put company have a newsletter every week goes out. So what's happening this week? It gets on the company calendar. It gets on the newsletter being promoted. We send email out preparing people. No one wants to be surprised. Hey, you are going to be gone. But we want to talk about why this actually benefit all of us. I'm still working on that to be honest. It's never if you think about business, business taking out, it's a week. Sometimes we do two actually we try to do every six months two girls week. Two out of 50 weeks of working day. It's a lot. And then our team that's 60 people. So that is an expensive week. So we better get something out of it.

Speaker B: Yeah, there better be some sort of roi. How much of your role just subjectively would you say in any given week you're spending on um, communication?

Speaker A: I always think I'm always in the communication. Whether that's email or it's a chat or it's a newsletter. I think that's part of things. The most important thing for design ops and because in a way I talk a lot about the OPS is a ah, thankfulness job and then no one knows what you're doing and nobody understand why things work. If everything works. Yeah, why, why wouldn't it work? But when things doesn't work immediately, it's ops. Deal with it. With this thing, it's broken. This process doesn't work. This doesn't right. So. So communication I think is extremely important in different level. Right. So something you need to just ping people, keep telling people you think about connected tissue is keeping people informed and why I'm doing this constantly. So the big communication. Maybe newsletter doesn't go out all the time but then everything else is always communication. Talking to people, pinning people, keeping people in informed. Different parts of or get the connective tissue is keeping people informed. And it's. I felt like I'm always communication. That's the big thing and everything I do in these different level, different type of communication. But that is definitely I think is a uh, strong. I think it's very necessary skill for the ops. I'm definitely not doing the best uh and I definitely keep pushing myself learning how to communicate, finding the right level. And that is the important skill for operation people. Keep people informed so you can connect them.

Speaker B: That sounds like it's been an area and a continuing area of growth and it certainly is for me communication, it's. It shouldn't surprise me at all but it is, it is so integral to the success of many, many other things. I think we completely uh, guilty at times of underestimating just, just its value when it comes to thinking about in this current moment how much of your role is taken up with that communication. Does it at all surprise you?

Speaker A: I never thought it that way. It's just become part of your life. You do and uh, it's almost like a muscle memory now I think at very beginning I don't even think about this is communication. It's just well let's talk to people for ops connecting people. Let's talk to people, let's ping people. And then you look back, oh this are just different ways of communicating and it's uh, communication. So I never really labeling say if I ping people for five seconds. I don't Label that as communication ever. But then if you look at that, that is also a different level of communication, everything. So I never thought about it that way. So I would say maybe it didn't surprise me and it's just part of life. For Alps.

Speaker B: One of the aspects of communication that you've mentioned earlier on in our conversation was storytelling. And you've mentioned a couple of examples of how you've been doing that through things like newsletters and showcases. I was curious whether or not you had any experiences enrolling those kind of more storytelling driven initiatives out, any learnings that were hard at the time in uh, terms of how effective those were and any course corrections that you've had to make as a result?

Speaker A: I think yes, because I was thinking, remember earlier on uh, we were talking about the answer is always depends. It depends, right? People hate the answer because there's no definitive guidelines or whatever. So one thing is that when I came to Cloudflare I came from prior to that, VMware. But VMware actually I was part of a company called Pivotal Software, which is all agile practice and everything. So I came from a very strong pair programming. We actually pair designing, pair everything pairing environment. So I benefit tremendously from that practice. So I want to bring that practice to our team to try it out and everything. And uh, so I think that is actually was a mistake. That surprised me because part of things, the storytelling actually wasn't right in a way. And I'm uh, thinking I'm um, coming in and say, hey, I have this idea, let's do this. And then it worked this way works really well. And it didn't work. We don't have enough people. Everyone, we have a very small team. Remember people are burned out. Really we don't have that luxury because the back then in Pivotal Software is more built into our DNA. Everything is pairing. And then that's a practice that we just took it for granted. But when we leave that environment, it turns out pairing is not an easy thing. There's a lot of things uh, that have to set up to make that success. So I came in from a very, again it's like an early stage, right? You hear, okay, you're burned out. But then there's other things. You can benefit a lot from pairing because pairing take care of a lot of low uh, hanging fruit and actually will ease the burnout. So my beliefs that will ease that burnout or whatever. But then I said let's try this out. But they did try it, but then it really did now. So in hindsight what could have worked is that the storytelling part of it is really talking about the beautiful picture, the end of what pairing will provide designers so they will be more willing to try it out instead of I don't have time and it takes a lot of effort and then practice vulnerability to show your vulnerability to do it. And so I wish I had presented that uh, grand, beautiful end result could possibly be. So I just totally didn't work work I tried pretty hard and didn't work well.

Speaker B: Never say never. I mean you could always try it again. But I wonder, given what you know now, which you didn't know then, is it something that you still feel would have benefit at Cloudflare now that the team's larger and perhaps not in those Covid years?

Speaker A: I still do believe pairing is really uh, helpful, but doesn't have to be a process way, can be a process more organic way now. And I uh, think now I don't explicitly say you're going to do design pairing or anything pairing, but I will always try to say, hey, let's do this with this person, let's do this with that person. I don't put a label on uh, as pairing anymore and let's do it with this person. And so that I think is organic, uh, way of pairing that worked here. And so certain times people will get together to work on things together, but it's not a process.

Speaker B: So did you find it difficult moving out of design and into operations like personally difficult in the sense that you weren't as closely connected to the work of a designer anymore?

Speaker A: For me it's not. But I can see that for some other people might be. For me, I always drawn to the service, uh, design operation side of uh, any kind of organization, everything. I would like to think I'm a pretty passionate designer as a design practitioner, but I think uh, there are people always do better, do faster than me. And uh, I think where I can bring the most value to the business now is not just a shipping product anymore. It's really helping the organization to grow in terms of culture, in terms of process, in terms anyway, because I can't bring in all that entrepreneur perspective, all different life experience to help people now. So that's what energized me. So for me I didn't mind. I no longer live in Figma. I live in spreadsheet now. And uh, I don't mind. That's why people are saying you try it out. If you think this is your world, happy with this, great. But if you find this is not Your world you can always go back to be designer. Right. So I still go to college config, I still learn all the Figma tricks and everything. I can still pick up Figma and uh, I actually still build templates for our team and everything. But then I don't do everyday shipping anymore so I don't miss that part. I uh, think uh, I provide better value to support people who can do that faster better than me. But I can see some other designers I find my creative venues rather than doing products.

Speaker B: Now that you're almost five years into this OPS leadership role, do you still see it as a two way door or has it become a one way door for you now?

Speaker A: For me I still see it as a two way door but I do give people the warning when they want to get into the ops. Potentially you have to be really passionate about ops. It's a ah thing if you always constantly need recognition, sometimes you don't get that at all. And also uh, you could potentially um, put yourself out of jobs. Because if you think about work, if you think about now, the environment for the past couple years, you know design industry went this up, down, up down the roller coaster we were in downhill for quite a bit. If I have money to hire a designer or OPS person, who do I hire? I will hire a designer. Right. So the ops and you could really position yourself out of jobs and uh, that's something you need to be conscious aware of. I am aware of that. And uh, um, I tell people who come into the industry you can always go back to the designer for sure. But then there's that risk ah, you're running. Keep yourself up to speed with your skill, everything. Then you broaden up your opportunities in case it comes to job security and everything. I still think it's two way store. Yeah.

Speaker B: And I suppose if you did have to walk back through the door, uh, part of the art of storytelling comes into it. Right. Like if you had to walk into a design leadership role, there's obviously some great stories that you can tell about the work that you've done in operations and what benefit that might be to the organization that you're interviewing at.

Speaker A: Absolutely. I tend to think this could be my bias as well. I think OPS leader can be design leader anytime and that we choose to be the support, support of our leader. Because I think I work well to support our leaders and then they have their jobs to go out to actually outward facing and I'm more interested in taking care of the internal um, works. But if one day I have to switch, go out to lead a design team. I can't because I did everything behind the scene.

Speaker B: Being talking a little bit here about career development and the type of decisions that you've made personally. And I understand that there is actually a two by two framework that you've used previously to rank tasks or perhaps job activities by enjoyment and competence. Correct me if I'm wrong, but I understand you've used this as a form or a tool to help with career, uh, focused self reflection and that it's led you to some interesting insights when you have used it. Um, what kinds of discoveries, if I've got that right, what kinds of discoveries recoveries have come about from doing that activity that have surprised you?

Speaker A: It helped me tremendously developing people. So I didn't invent a ah, framework. I took a uh, leadership, women leadership course as part of the framework that was introduced. And you think about the two by two, right? So things you're really good at. And uh, the other side is the things uh, you really enjoy doing. So in this two dimension, a lot of time we think about development people, you hear this, you're doing great, you're awesome or room for improvement, you need to improve. It's very typical when we think about developing people. But I like to think of this as a two dimension instead of this one dimension way of you're good or you're bad at something. So I do this two by two. And uh, so if you think about things you're really good at doing, doing and the things you're not too good at doing, right? So in one axis and there are things, things you really enjoy doing and things you really don't care about. So I'll do the vertical uh, axis, the things you really enjoy, things you don't enjoy as much and the things you are really good at and the things you are not really good at. So you divide it into two by two. So if you think about there are four type of strengths and again I didn't divide develop this framework, uh, I use it a lot. So there are things you really really enjoy doing and you are just extraordinarily good at. That's your natural strengths. So that's the part that people just think oh, they're really good at it. And part of the reason you're really good at this is because you really love, that's, you know, you're really good at it because you love it. So you keep working on there or whatever. So that's the part I want, want everyone to focus on as them um, developing their career because that's where you find stretch opportunities. You can be better, you can be the best of the category and no one can do better than you. And then so there's another side that you really want to get good at, but you're not quite good at yet. You think I want to learn. So that's your potential strength. So that's the area that you keep learning. You take courses and then you learn from other people. You find opportunities to do it, uh, try it out. So that's where you can actually grow if you think that's untapped potential, basically. And then there's the bottom left corner you are actually really good at. It's because your job depends on it. Because if you're not good at it, then you're not going to get this job. But that part people don't know, that's the part really strangulate for the people. You need to focus it. You need to put a lot of time, hard time in. So that's where I say if this is the type of work you're doing and then you need to carve a time heads downtime to keep working on it. So you need to get it done and so you don't lose your job in a way. Right. So, and then sometimes we get really good at it because we do a lot of it. Spreadsheet wasn't my thing. That is my area. So I need to do, write formulas, do spreadsheet and I really need to get it done. I enjoy the strategy of what the spreadsheet will give me, but I have to do that part. But then I need to carve out heads down time to produce that. So then the last area, the bottom right is the area that you suck at and then you hate doing it. So the thing is that that's where we talk about you can pair with people because I suck at it. I guarantee you probably are good at it. That's your strength, that's your natural strengths. Then let's pair. Let's do it together. I can learn a little bit from you, but you will enjoy tremendously doing that work. That's also the work I can delegate to other people on my team. That's also when you hire a team, you want to make sure you hire people who actually can complement your skill as well. You can learn from them or give them the work that we can actually take what we're good at. Right? So that's the part people say you need room for improvement. That's not the room for improvement. The room for improvement is top right and not the bottom right because you can never get good at and that you can get a little bit better, but you will never be the best of that category just because you hate it. Why would you be the best? Right. So that's the area. So if you think about in a two dimensional then people can help people to understand. Where do I develop and understand there are things that I just absolutely shouldn't be doing. Let's talk to my manager. Think about can you find people to do it? It's not because the work I don't want to do. When I delegate people, it's not work I don't want to do. It's actually I can find people who enjoy doing that part. Sometimes I might have to pick up that part, but ideally not me. Get someone who love it to do it. So that's the career two by two. I talk a lot to talk to people who report to me. I try to talk about it outside as well, to talk about how to develop people. Instead of thinking about you're good room for improvement, but think about different strengths.

Speaker B: Sounds like it's a brilliant framework for bringing clarity and um, perhaps some level of objectivity to those conversations. And as a manager, I imagine it enables you to make quite well informed, informed decisions as to how to change things in the team so that the team's more effective.

Speaker A: Absolutely. I think that's a really good perspective and actually help you to be a better, not only better manager to the people who report to you, but also help you to think about how do you build your team for the longevity of the team as a strategy as well for building a team. So it's really helpful.

Speaker B: Z. I'm uh, mindful of time. I have one final question for you and that is in your role as a people manager, what's the thing that you find yourself needing to remind yourself of most often?

Speaker A: I grew up in a generation that you hustle, you do your work and uh, I personally don't need a lot of praise. That's part of thing. I go into elves and it's okay. But I do remind myself other people have different perspectives, that people have different personalities, people have different way of approaching things there people need to constantly, um, be recognized, everything. So people are different. So finding people on your team, what's their style? It's important I keep reminding myself not to neglect that part. But my tendency is like, uh, you're doing your job. But then I learn, constantly learning that and I'm continuously working on that. I do know a lot of people on my team and a lot of people on the larger design orgs team. Uh, excellent, excellent at that. They will always immediately spot out, say this is something, deserve praise and everything. So I'm learning from people as well.

Speaker B: Thank you for sharing that Z. This has been a wonderful deep dive into all things design ops leadership and also the wonderful stories you've shared with me from your career. So thank you for so generously sharing those stories and your insights with me today.

Speaker A: My pleasure. It's fun discussion.

Speaker B: Yeah, I had a lot of fun too. And for people, Z, who are interested in hearing more about what you're up to or uh, connecting with you, what's the best way for them to do that?

Speaker A: LinkedIn is the best way. It's changing Z. And uh, I have all my links there, including my passion projects and everything. So you can find me there and my website is listed there and then my blog is listed there. So LinkedIn is the best way.

Speaker B: Okay, thanks Zee. And to everyone who's tuned in, it's been great having you here with us as well. I'll make sure that I put links through to Z's LinkedIn, her website and her blog in the show notes so you can find them there. In case you also want to hop back to anything that you've heard in the conversation. There are uh, detailed chapters that you can find in the show notes as well. If you've enjoyed the show and you want to hear more great shows like this, conversations with people like Z, world class leaders in UX research, product management and design. Don't forget to leave a review. Subscribe. So the podcast turns up every couple of weeks in your feed. And also pass the podcast along, perhaps just to one other person who you feel would get value from these conversations at depth. If you want to reach out to me, you can find me on LinkedIn as well. So just search for Brendan Jarvis or you can find a uh, link to my LinkedIn profile in the show notes. Lastly, you might want to check out my website which is the SpaceInBetween Co NZ. That's TheSpaceInBetween Co NZ. And until next time, keep being brave.