How to Influence as a Design Manager within an Enterprise

Roberta Virzi at UXDX EMEA. Video: https://youtu.be/ul1xUwaIWzQ

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.

Introduction

[00:00:08] Roberta: Thank you, Emily. Hi everyone, I'm Roberta from Booking.com, and today we're going to discuss how to influence as a design manager within an enterprise. In large enterprises, design managers face unique challenges in influencing decisions and driving the design agenda. So today, starting from my experience with Booking.com, I would really like to discuss with you, and hear from you, how you structure teams, how you secure stakeholder support, and how you improve communication between developers, product managers and UXers.

[00:00:46] This session is tailored mostly for early-career design managers aiming to increase their influence and leadership within a large company. But if you're not a design manager, or you're coming from another craft, don't worry about it. I'm very curious to hear your way of working and your opinion about the questions.

[00:01:08] Cool. Before we actually start with the questions, I would like to briefly introduce myself. I'm Roberta, and I'm from Italy, as you can guess from my Super Mario accent. As I mentioned, I'm a design manager, but I actually joined the company as a UX designer in 2017. I have in total 14 years of experience in design, and six years as a manager, overseeing teams of up to eight people. My company's mission is to make it easier for everyone to experience the world, and to reach this vision, my team works on helping users book vacation rentals and supporting hosts in registering their properties with us. Having transitioned myself from an individual contributor role to a managerial role, I'm very passionate about the topic of influencing as a designer. I have a lot of experience working with stakeholders from various crafts, especially with product roles, to shape strategy effectively.

How do you structure design teams?

[00:02:11] Cool, so without further ado, let's start with the first question, which is: how do you structure design teams currently? I'm going to give you some context, because not everyone might be familiar with the terminology here. The way design teams can be structured can be very different, and it can affect scalability, efficiency and innovation. So I would like to understand how you structure this. It can be an embedded model. The embedded model is where there is a product team with a product leader, a designer, a copywriter and then a bunch of developers. Then there is the centralized model, which is where the design team works all together in a team, with a design manager overseeing it. It's more what we call an agency style. And then there could be any other option, like a hybrid way, a mixed setting between the two. So I'm curious to hear from you how you work in your company.

[00:03:12] Cool, I see some votes coming. We have a lot of hybrid, that's nice. Does anybody want to share? Maybe the ones who voted hybrid, which is the majority of you, or any other option is also fine. I'm Italian, I don't like silence, sorry, so please help me. What are the pros and cons that you see with the structure you work in? A mic is coming, in case anybody... Nice, thanks.

[00:03:58] Audience: Hi. I voted hybrid, and this is mostly because our client wants us in several different projects, but also wants us to do overarching design infrastructure. This leads to us sometimes being integrated in the rest of the dev team, and sometimes we're our own team, and we had to adopt a very flexible model of integration.

[00:04:26] Roberta: So do you mean with the client you work mainly embedded, and then when it's the larger things, you work more centralized?

[00:04:33] Audience: Exactly.

[00:04:33] Roberta: Nice. And what do you see as the pros and cons of this?

[00:04:38] Audience: The pros are definitely that we don't lose touch with the dev teams. Sometimes you can easily drift apart if you're too centralized, and you just become a service unit, and you can sometimes lose the developer experience. But the cons are that you sometimes get pulled in two directions, and there is not enough time to do either thing right.

[00:05:03] Roberta: Yeah, I understand. Cool. Does anybody else want to share? It can be a different model. We have a lot of votes. Maybe one with the centralized model? There you go.

[00:05:26] Audience: Hi. In my company we work with the centralized model, and we are basically an independent department: a design team whose decisions are independent of any project team. The advantage is that we have our own decisions. We can rule over project teams, and we can keep the design system consistent and so on. One disadvantage is that we belong to several project teams, but we don't really belong to them. We are working as external partners, so sometimes it's difficult to create a rapport [?] so that we're really accepted.

[00:06:09] Roberta: And do you manage to influence the strategy in this setting too, or is that a bit harder?

[00:06:14] Audience: It's a little bit harder, but we do as well, because the CEO is a design fan, so we end up having a lot of say because of that. Because beauty is important.

[00:06:28] Roberta: Nice. True, we just saw that. Yeah, makes sense. Nice, thanks a lot for sharing. Anybody else who wants to share? Otherwise we can go to the next question.

[00:06:41] Cool. Just to give you some information about the way we work: the majority of teams at Booking.com work with the embedded model, where a product manager is the leader of the team, and there is a very close relationship between product and design. But with my team, we decided together to change to a hybrid model. That is basically where the designers remain embedded in their teams, so they still work with the product manager very closely, but they own topics, and these topics can span different teams. Because we work on different platforms, like apps and desktop, that means it's easier for us to keep consistency across the different platforms. So that was the reason why.

Gaining and keeping stakeholder support

[00:07:30] Cool, maybe let's go to the next question. How do you mostly gain and maintain stakeholder support for design initiatives? We have different options here: building strong relationships, demonstrating ROI, and so on. Curious to hear the one that you feel is very, very important. Nice, we have a lot of building relationships. Does anybody want to share what they voted for and what they see, how this is working? I don't see very well, so raise your hand, because there's a lot of light. Maybe somebody that voted building strong relationships: why do you feel it's the most important? The mic is here. Oh, here in the first row.

[00:08:47] Audience: I think it's important because when you build strong relationships, you understand what they need from their perspective, their agenda, and then you know which parts to communicate to them. Sometimes they suggest design decisions, and that's annoying. They say, "Oh, keep the button there," when you know as a designer that color is not suitable. So you can know their perspective, and if you build a strong relationship, you know how to communicate to them, if they're a main stakeholder, when their decision is not the one going in. Egos do play a role. You know how to communicate and how to soothe their ego when you've built a strong relationship.

[00:09:31] I also voted for consistent communication. I want to combine them: building strong relationships leads to consistent communication. I don't mean consistent so much as precise communication, how to communicate with them. So I say relationships are very important, so you know that person and how to communicate to that person, how to not offend egos, and how to gain support in the future for your desired roles, research, budget. So yeah, that's my answer.

[00:09:59] Roberta: Makes sense, thank you. Maybe just a follow-up: how do you go about it? When you start a new relationship with a product person, how do you start?

[00:10:10] Audience: Sorry, can you repeat that again?

[00:10:11] Roberta: How do you go about building these relationships? What do you do as a first step, maybe?

[00:10:18] Audience: Okay. Whenever I change company, first of all, for the first 90 days, instead of just focusing on my work, I try to observe. I try to involve myself in as many meetings as possible and just sit back and observe who is talking and who has the power in the room. It may be a junior person who is influencing; it doesn't need to be the highest paid person. Once I understand the relationships, I try to have lunches with them and try to understand their role. It's not personal, but I try to build a form of friendship with them, know what they do and how they work. Later, when I'm working with them, there's an easy rapport, and I feel comfortable texting them separately on Teams, or having separate catch-ups. That's how I build the relationship. During the process, I also get to know not only their role, but, since everyone has a personal agenda, what their agenda is and how I can support it and build relationships. So that's how I start building relationships before I even start working with them. That's how it is. Thank you.

[00:11:24] Roberta: Nice, thanks a lot for sharing. Anybody else who wants to share? Here we go.

[00:11:32] Audience: Hi. I think on building strong relationships there's also just a practical part to it as well. We work at an enterprise level. There are a lot of competing requirements, a lot of competing people pulling at everyone all the time. You would like to think a product manager would always think to involve design, but it can be so competing in terms of what they have to think about and what they have to include in their considerations and timelines. So building a strong relationship is a practical thing as well. It just keeps you at the forefront of their minds, because without a strong relationship, particularly at enterprise level, you may be overlooked or forgotten about. It's just the nature of it. There's so much going on all the time. So there's a practical aspect to building strong relationships as well.

[00:12:19] Roberta: Yeah, that's very true, because sometimes they don't involve us just because they forget, and then we're like, "Oh, why didn't you involve me in this conversation?" So yeah, makes a lot of sense. Anybody else who wants to share? I don't see... Here we go.

[00:12:40] Audience: Hey. We were the first UX team in our business unit for a very long time, so what we did was grow on them. We just forced them to love us. We brought cakes, we brought candies, we organized events, Secret Santas, things like that. So we really grew on them, and now they feel guilty if they forget about us. That's really our strategy in our business unit: we just force them to love us.

[00:13:06] Roberta: That's a good one. So, tips for you: bring cakes and chocolate. That's cool. Maybe anybody else wants to share? Otherwise we go to the next question. Let's see, maybe we go to the next one.

Challenges in getting stakeholder buy-in

[00:13:23] Cool. I want to ask you: what are the biggest challenges that you face in obtaining stakeholder buy-in? Where did you find it difficult? Let's see. There are also some online answers that might pop up. Not seeing the value of design. They don't get product design in general. Competing stakeholder requirements. Yeah, makes a lot of sense. Not enough time. Politics, that's very true. Lack of maturity. Nice, a lot of answers. Anybody here that would like to share, even if you didn't write it? That's fine. Yeah, there.

[00:14:27] Audience: Hi. I think the challenge is when there's a lack of alignment in terms of outcomes, what the business is supposed to achieve. If there's a lack of alignment with the stakeholders, then yeah, maybe egos, politics and hidden agendas.

[00:14:53] Roberta: And how do you go about it when you feel there is a lack of alignment? Do you try to act upon it?

[00:14:59] Audience: Ask questions. I think you need a strong PM for that, someone from the business side who leads, to facilitate the alignment.

[00:15:15] Roberta: Okay, sounds good. Nice. Anybody else want to share a different perspective, or build on top of what we just heard? ROI. Yeah, maybe in the meantime I can share. I agree with everything that has been said. We need to build strong relationships with product. We need to really align on what the outcome is that we want to achieve, what the goal is. A lot of times I just go to my reports and ask, "Are you clear on why you're doing that?" And they're like, "Yeah, not really. My product manager said, 'Oh yeah, we want to build this feature.'" Yeah, but why do we want to build this feature? So that's very, very important. I agree with that. Cool, then maybe anybody else wants to share? Yes, we have someone I don't see.

[00:16:22] Audience: Hello, Roberta.

[00:16:22] Roberta: Hello. Hey, friend.

[00:16:26] Audience: I think the biggest challenge, especially now, as one of my friends has mentioned, is that design is getting seen more and more as an expense house, a cost center, versus something that generates revenue. So oftentimes we need to do a better job explaining how findings turn into feature changes, and how those changes turn into losses that didn't happen, so that they understand that we actually generate a better product that loses less money, which is essentially the same as making more money.

[00:16:54] Roberta: Yeah, that's a very good point. Thanks for sharing. It's also related to a question... I don't remember if it's the next one. No, it's not the next one, but we have a question about it later.

Communication between design, product and engineering

[00:17:07] Cool. So how do you mostly facilitate effective communication between design, product and engineering roles? We just saw that building relationships is very, very important, so how do you do it when it comes to communication? We have regular cross-functional meetings. What's coming in... a lot of... maybe regular cross-functional meetings. Does anybody want to share how they do that? Do they see any challenge in this? How do they structure these cross-functional meetings? Okay, nice.

[00:17:52] Audience: I said documentation, just because it's a lot easier for someone to reference an email, or written-down instructions, or comments in a code base, versus the thing that we talked about last week while getting coffee, or the thing that someone brought up in a meeting that no one wrote down. The more things are written down, and the easier it is to find them in an email or in Slack or wherever, the easier it is for people to reference things, for people to articulate what they actually meant, for them to clarify. And also, in some cases, if you need to catch someone when they're lying, or when they're saying they didn't say something or didn't do something, it's a lot easier if everything's written down for everyone to be able to talk about that.

[00:18:42] Roberta: Sorry, a follow-up question: how do you make sure that everybody actually reads this written communication, the documentation?

[00:18:49] Audience: I'm really big on linking to it, and making sure that whenever I talk about something, I'm also referencing the documentation that I use. That way people don't just see me saying "write it down." It's one of those: I wrote it down, I'm sharing with you what I wrote down and why I wrote it down. Whenever people ask me questions, I'm really big on sending them the documentation and having them add comments, just because I want people to know that I'm not just coming to them to extract their work. I do care about the process, I do care about the workflow. I'm not just doing this so that we can all not do our job.

[00:19:32] Roberta: Sounds good, thanks for sharing. Anybody else who wants to share? Here we go. Here, oh, sorry.

[00:19:43] Audience: Hello. I feel that the most effective way of doing it is bringing engineers and QA to user testing, so then they'll be able to understand the users' pain. By doing that, it's easy to communicate and explain our design decisions to them. So I feel that's the most effective way: bring them to the user interviews, and bring them in beforehand, in discovery as well.

[00:20:10] Roberta: You mean to empathize with the users and with the pain points?

[00:20:12] Audience: Yes, absolutely.

[00:20:14] Roberta: Makes sense, nice. There was another hand here, at the front.

[00:20:23] Audience: Hey. I think it depends on what you mean by most effective, because I think a lot of it is actually based on your intention. For example, I actually think informal catch-ups are great if I'm trying to evangelize the role of design in a given product: catching up with people, establishing trust and understanding that I'm a partner, that I'm not just somebody here to change the strategy or push an agenda or all that kind of stuff. That's really effective. If it's about trying to show process, I think documentation is really helpful, because I can outline things. Regular cross-functional meetings are obviously really useful when you need to ensure that you're on the same page with engineering and on the same page with product. So I think it's all of them. It really is contingent on the intention behind the communication and how you're trying to establish trust with your given stakeholder.

[00:21:13] Roberta: Yeah, makes a lot of sense. I agree, it's all of them, depending on the actual context. Thanks for sharing. Cool, let's go to the next question.

Advocating for design decisions

[00:21:27] And maybe connected to that: what do you think is the most important best practice for advocating for design decisions within product teams? We saw building relationships, collecting data. But in this case, if you really want to push a change, maybe a design system change, or any other that is hard to do, what do you do? Nice: understanding business goals. Does anybody want to share, while you vote, why they think so and how they do it?

[00:22:04] Audience: I voted for understanding business goals because, as I've heard in talks before as well, in the end we want to build nice design, a nice customer experience, so that the customers keep coming back, and in the end the goal of most businesses is just to make revenue. I think that's often what I notice in design: that's the missing link. We need good design not just because of good customer experience, but in the end, understanding what kind of business goals that leads to, whether it's customer retention, a lower cost of customer acquisition, or higher customer loyalty. Having those business goals in mind really helps to speak the other person's language, basically. The same with talking to engineers as well: having their tech goals in mind, to really understand other people's objectives. That helps you to really communicate your goals and your needs.

[00:22:51] Roberta: Yeah, makes sense. We also heard in the talks yesterday about really speaking the language of the business: understanding what we're trying to achieve from a business perspective really helps to justify our proposals. Anybody else who wants to share? Here we go.

[00:23:22] Audience: I voted build relationships, because I found out that if I don't have relationships with the people who have the information about all the other things, they're not necessarily going to tell me, or even think to tell me. A lot of the time our team didn't understand the business goals, or didn't have the data, or didn't know about the tech limitations, even though we tried to ask people, because when new things arose we weren't necessarily in the loop, because we were outside of it. So building those relationships, and having people remember, "Oh, we definitely need to tell these people too," has helped.

[00:24:00] Roberta: Yeah, makes sense. Also building trust with them, so that they can actually come to you as a partner.

[00:24:04] Audience: Yeah, exactly.

How the design manager role is evolving

[00:24:07] Roberta: Nice. Maybe for the sake of time, let's go to the next question. I'm curious to hear, since you probably have a design manager or a manager of your own: looking ahead, how do you see the role of a design manager evolving within an enterprise? Going more strategic, staying the same, focusing more on team management? Anybody who wants to share? We have a lot of becoming more strategic. Yes, thank you.

[00:24:51] Audience: I've been working very closely with a design manager for quite a few years, and I consider her my right hand, as well as the tech lead on the other side. I think that working on the product strategy together is super important. And sometimes I think designers can have a better strategic mindset and look a bit further, and not be so focused on the details all the time. There's a time for everything. So be more strategic, look at the long term, and maybe at long-term business goals. I think it's going to be extremely useful to work like that.

[00:25:31] Roberta: And knowing this, how do you go about being more strategic?

[00:25:38] Audience: Maybe sparring and collaborating closely on, for example, a product strategy, and being very inclusive, especially making sure that the design manager and the designers are also involved in that.

[00:25:51] Roberta: Yeah, makes sense. A lot of the time I hear, "Oh, but this is not my role, it's actually the product manager's role." But I actually feel there are a lot of overlaps, and things really start to change when you build this relationship and you go more...

[00:26:07] Audience: Can I just comment on that?

[00:26:09] Roberta: Sure.

[00:26:09] Audience: I don't think it's the product manager's role to create a strategy. It's the product manager's role to facilitate it. It needs to be cross-functional for it to be successful. Maybe the product manager facilitates it, but it should be a shared decision and shared work, cross-functional basically.

[00:26:27] Roberta: Yeah, makes a lot of sense. I agree. Cool. Anybody else want to share their opinion? I cannot see. Otherwise we go to the next question. Yeah, let's go for it.

[00:26:53] We've talked about how the design manager role is evolving and how you see it. Let me elaborate on what my opinion is there. I feel it's becoming more strategic, following up on what you just said. I feel like building this strong relationship with product allows us managers to create opportunities that we can give to our reports to actually grow. So I feel a lot of impact can come from becoming more strategic, also on people management as well.

[00:27:28] So what benefits or challenges do you foresee with these changes? Do you have any opinion on that? "Designers becoming too thinly stretched." Yeah, that's a fair point. What do you think about it? Does anybody want to elaborate? "Don't get to see the side [?]." "Nobody likes change." That's very true, nobody likes change. Anybody want to share what they think? "More awareness of the usefulness of design at the big tables." Yeah, agree.

[00:28:17] "How to build this relationship when most of the team works remotely?" Yeah, that's an interesting one, because we talked a lot about how to build relationships, like getting coffees, maybe bringing cakes. But when it's remote, maybe it's a bit more challenging. You have to be more intentional. You maybe have to schedule a bit more time to do that, and understand when the right time is to schedule a meeting with people. Maybe a recurring meeting can also help. If you have a recurring time that works remotely, that can also help, and we heard the same yesterday in one of the talks. Nice. Time is up, so thank you very much, everyone, for the participation. Have a nice rest of the day. See you.