Implementing Change in Ways of Working

Muriel Naim, Mike Brown, Alberta Soranzo, Noah Levin at UXDX EMEA. Video: https://www.youtube.com/watch?v=NNgpSnbc3QU

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.

Introductions, and the careers we might have had

[00:00:03] Noah: Hello everyone, it's good to see you again if you saw me before. My name is Noah, I lead the design team at Figma, and I'm super excited to be here with you for this panel about change and change management. To get started, what we're going to do is just introduce ourselves and say what you do, what you work on. And we asked this question in an earlier panel, it's kind of fun: if you weren't in design, or what you're doing today, what's something you might have thought you'd be doing or would want to do? We'll start at the end and then we'll go across.

[00:00:37] Alberta: Right, so name, serial number.

[00:00:39] Noah: Yeah, Social Security, all that.

[00:00:43] Alberta: Okay. I'm Alberta Soranzo, so you see my face somewhere up there. I am a group head for customer experience at Vodafone Business Group, so not in any specific country, and I lead a team of designers and analysts that look at the B2B side of Vodafone. If I wasn't in my job, how many choices do I have? All the careers in the world. So I wanted to be a firefighter, because my favorite cartoon when I was little was about a little dragon that was a firefighter.

[00:01:16] Noah: That's cool.

[00:01:18] Alberta: A dairy farmer sounded appealing, or airline pilot.

[00:01:24] Noah: All three great options. Very different options.

[00:01:26] Alberta: Yeah, very different.

[00:01:27] Noah: Cool, nice.

[00:01:28] Mike: Hi everyone, I'm Mike, I'm head of design for Reed, reed.co.uk. The Reed organization is one of the biggest recruiters in the UK. The organization handles every part of recruitment, but my team, a team of product designers and digital designers and researchers, really we deliver all the digital experiences, mostly for a big job board basically, for both customers, both B2C and B2B. Thinking of careers, when I was a kid I would have really liked to be a professional basketball player, but unfortunately I stopped growing when I was 15.

[00:02:04] Muriel: Muriel Naim, and I am the VP of design, research and UX, because it's a startup, I know how it goes, at fabric, which is a headless e-commerce platform, and B2B2C. I do a lot of stuff. Previously I was in Disney and ABC and Walmart, a bunch of big corporations, leading UX architecture as well as product design, in my hands until I grow the teams. A different profession: when I was younger I was very set on being an astronaut pilot for many years, and then it changed and I was much more interested in human behavior, so I would probably be a psychologist or a psychiatrist. Bridging the gap between them, something about processes.

[00:02:43] Noah: That's awesome, that's great. I feel like there are so many things we do in design and psychology is obviously such a huge part of that, and to imagine a world where you're getting even deeper into any of the stuff that we do seems really exciting. I answered the question earlier but I kind of want to change my answer and maybe say something different this time. Maybe something in architecture or interior design would be kind of fun. I feel like it's super hard and I wouldn't be very good at it, but I like the idea of understanding how things are made around you and helping make those experiences better. Obviously there's a lot of overlap with UX design and the ways that you have to think about spaces and how people move through them, so something around that.

What we mean by change

[00:03:18] Noah: But we're not here to talk about architecture, we are here to talk about change. Obviously a big word, a loaded word, can mean a lot of things in a lot of contexts, but in this context here it can mean, let's call it, a few things. It can mean influencing a change in your company. It could be the process. It could be, if you're in a growing company, what processes need to change. It could be even things like if the market requires a change for you to influence in some way. So obviously a broad definition, but learning how to handle change is probably one of the most important themes we're working with in general these days. Things happen so quickly, we need to adapt, and it's hard to do that.

[00:03:53] And so for me personally, at least at Figma, there have been kind of two articulations of that. There's been helping companies make changes to change the tool they're using, which is hard. You've got thousands and thousands of people who are used to one way of doing something and we're having to figure out how to influence change for them when it makes sense. But then there's also the reality of being at a growing startup. I joined Figma five years ago, we were about 25 people, we're almost 900 people now, and over those five years you have to influence a lot of change. So throughout I'll try to chime in here and there with what that's looked like where it makes sense. But to start, for the panelists, when you hear that word, if a story comes to mind for you, I know it's kind of broad, but whether it's a change you had to implement in the company when you were there or a past company, just any anecdote that comes to mind where you had to see a change happen, and what happened in that environment. So take it wherever you want, whoever wants to start.

Change done well and change done badly

[00:04:44] Mike: I'm happy to start. In my current role at Reed it's been quite a nice experience, because I was brought in to essentially affect a lot of change. It was a company with not a lot of design maturity. There was a design team that was doing good work, but there were probably a lot of changes that needed to be made, and I had buy-in from the business to do that. I was given the time to really look at everything design: a clear product design strategy to deliver everything, tools, extra people, changes to ways of working, all those kinds of things, and it was all agreed and implemented quite easily, which is quite nice.

[00:05:20] It's nice to have a good experience, because I've also been on the other side when it's been done really badly. I was in a much larger organization before, where we made some really positive changes. It was quite a while ago. It was a really large design organization still split along UX and UI, so we moved everyone into product design, everyone became product designers overnight. Also there was a wide range of different ways of working: some people were in agile teams, some people were in waterfall teams, a lot of people halfway between. The entire organization, thousands and thousands of people, the entire digital organization, all moved into empowered product teams, which is a great change, but all this happened at once and it was done with almost no consultation.

[00:06:03] So people's jobs changed overnight, their ways of working changed overnight, people were really scared, there was a real absence of information. People tried to do that, but it led to a fair bit of churn, and as a leader bringing that through, just a huge amount of heartache. So I think the thing I learned with that is just the more communication and the more planning that can come into this kind of large change, the better.

[00:06:24] Noah: Yeah, that's interesting. Have you seen moments where there's been good communication around change? Are we talking about an email message? How does that even show up? Is it Slack? What are the ways that you've heard or seen that show up, either there or wherever?

[00:06:40] Mike: Well, I think the key thing is it can't just be top down, it has to be bottom-up as well. There are some things that have to come from the top. If we're talking about hiring new people, changing teams around, that's fine. But in terms of ways of working, how we're all going to work together, that has to be done bottom-up and it has to be consulted. Because even if we're changing to something better, there are always things that were working before, there are always people that were working really hard, and a lot of the problems that were there, it's not because everyone was an idiot, it's because there were problems they were trying to solve and they weren't able to solve them. So without that consultation, which I've seen in some places, it just leads to a lot of anger.

[00:07:13] Noah: Yep, that makes a lot of sense. People need to know the reason behind things when they're happening, and that clear articulation can be super helpful. So either of you, any stories that come to mind when you think about change, either that you had to implement or that you saw happen at the company, any anecdote that comes to mind when you think about this?

Repositioning design inside a large corporate

[00:07:33] Alberta: The thing that has happened to me in my current job and in my previous job: I generally get brought in to either create or re-establish or reposition design organizations in large corporates. Not by trade, it's just what happens. And so the big change is a changing perception that you're trying to support, a changing thinking, and that's that design is no longer — the organization doesn't want design any longer to be the cute little thing at the very end, make this thing pretty, but turn us into a customer-centric organization, which is a completely different ball game.

[00:08:23] And it's interesting, because Mike, you were talking about how change scares an organization. Designers are really terrifying to an organization, because we dress different, talk different, act different and believe in fundamentally different things. And I think a part of alleviating that fear comes with knowing what any good researcher knows, and that is that you cannot do things to people. If you really want to achieve outcomes you need to do things with people and make them part of the process. And that's especially when you're looking at bottom-up ways of working, that type of change. I think it's fundamental. The buy-in doesn't come because you send a cute email, doesn't come because you issue a new playbook. It's because you say, hey, I know a few things about design but you know everything about your organization, help me understand and let's see how we can do it.

Translating design into the language of the business

[00:09:24] Alberta: But the most important thing for me is how do you communicate the importance of this change. I want to say the value of design, because that's the thing that McKinsey publishes, but the importance for the organization. And that comes with a localization of our language as designers for corporate, for senior leadership. So I think my favorite business book, it has to be The Little Prince. I don't know how many of you have read The Little Prince. A few of them. How many of you consider it a business book? Yeah, I didn't think so. One didn't think so.

[00:10:09] So at the very beginning it talks — if you've not read it, go out and buy it, it's, I don't know, less than 100 pages. But at the very beginning of The Little Prince there is this fictional little prince that meets a pilot who gets stranded in the desert, and talks about his exploration of planets and how children and adults talk about the same thing in different ways. So if I buy a house, you might ask me how much did it cost, how many square meters is it, what is the zoning on the land. A child will ask me what color is the roof, can I play hide and seek. So adults and children look at the same thing in different ways and talk about it in different ways.

[00:11:07] And we need to do the same thing. We need to translate our design speak and our design lingo into something that the organization can appreciate. And it's only when we act like the children in The Little Prince, I think, that we're able to bridge that gap and make change less strange and less scary.

[00:11:30] Noah: Do you think that means — I love that analogy and that example — do you think it means using the language they're using, or does it mean shifting the language to something else to help them see that change? Or which has happened for you, if either?

[00:11:42] Alberta: I like the concept of a Trojan horse, and in corporate especially, numbers are the best Trojan horse. So if you tell your CFO that you want to spend six hundred thousand dollars because you want a new research program, or you want to buy Quantum Metric to analyze some journeys, they will say, oh, that's cute, but no. But if you tell them, by spending this six hundred thousand dollars I can save you two million dollars, or I can help you make five million dollars more, then it's a completely different conversation. So it's not a matter of radically changing how we speak, but also adding that layer of translation into what it means for people that have a completely different frame of reference.

[00:12:37] Noah: Yeah, that's really great advice in general. So any other kind of moments where you've seen change happen, or that's come up for you, that you want to share?

Educating the organization about what design is

[00:12:46] Muriel: When I joined this startup I really wanted to bring — I realized there was, again as always, a very, very small amount of designers compared to the enormous amount of engineering folks, as always. So I really wanted to bring the system that I built for Disney, which was interestingly a similar case. Design is typically underappreciated, as I said yesterday and I say again, and we really need to evangelize how to change that, but you do have to work with numbers. We do have to be very personable and empathetic, smart and a little bit manipulative, in order to grab this Trojan horse and push it into a place in which, even with numbers, they may not still understand the importance of good design, not just design, good design, which sometimes requires more time and more people.

[00:13:30] So I did it before at Disney, and I was able to post some numbers and manage scrum teams with engineering and somehow push in design. And then I went to the startup and I wanted to implement these ways of working, that is, really centralizing the team again, so that we can have an equal amount of work for everyone, so that I can see what everyone is doing, because they can have peer reviews, they can have retros, they can have internal and external sharing and a lot of cross-pollination of how things work, as well as support the whole organization, 70 domains[?], which is over the top.

[00:14:04] And I realized that the organization equated design to high fidelity prototypes alone. It took me a second to realize that. I didn't realize how far behind they were in understanding what good design is for real. So sometimes it's also about educating, and it's not condescending, people sometimes don't know. Before the design system as well I was like, okay, design system, we're going to save this amount of time, X amount of, you know, XYZ percentage of engineering time and storybook, and it's obviously going to save all this engineering money. It wasn't enough, because some people didn't understand what that even is. So I had to explain what a design system is from the ground up for the full company, and that drove an enormous amount of change. I felt weird explaining such a basic term, but sometimes it's just about this empathy and meeting people where they're at and speaking a little bit in their language, to your question.

[00:14:57] I do think you did that too with the financial officer, right, because it's spoken in numbers, but they know. So yeah, each team requires something different, and I'm really pushing my designers to be like, hey, you need to educate, it's okay, be patient please, you need to educate, you don't always know.

[00:15:13] Noah: Yep. And to build on that, there are moments where we're finding ourselves having to articulate a change or what we're about to do, like in the example of that design system. There are also moments where, if we have the privilege or time to do it, demonstrating or showing something can be one of the best ways to make change too. So in that example, if there's time or bandwidth to even just show someone who's wondering what this thing is what that new change looks like or what the design is. And even at a micro level, if you're the first designer at a startup and that startup doesn't know what design is yet, you're probably not going to have the time, because the startup has a lot of asks of you, to try to say, oh, here's what I do. You're probably just doing it, and hopefully if you're doing it well enough they are inspired enough to want to continue that function or grow it as the company grows. But it's not always easy to do that.

Where designers sit, and who resists the move

[00:15:56] Noah: Maybe one anecdote I was thinking of, because you were talking about centralizing the team, you brought them together because you needed to see them together. That reminds me of the change we made, and it was kind of a small one. When we were a small team we sat together, there were three or four of us and that kind of worked for us. We like to jam and we like to collaborate. But there was always this lingering question of, should we be sitting with our engineering teams instead, should we really integrate ourselves? And it didn't become obvious that a change was needed until we grew, and we grew to a point where engineers were walking over to the design area constantly and it was just like, something feels wrong about this, we're really building something together.

[00:16:31] And yet implementing that change wasn't straightforward, because you've got a team of people who may not all agree on that change. Some of the designers were like, of course, I want to sit with the engineers, some of them were like, no, I actually really enjoy this. And this is pre-pandemic of course. Post, I think that actually made that conversation a lot easier, you didn't have to think at all about where people were sitting, which is kind of in its own way interesting, that kind of changed too. I don't know how much that's already been talked about during the conference, but we can touch on that as well, if that affected anyone's way of working.

[00:17:00] Mike: It's really interesting what you're saying, because I've had that exact same experience in multiple organizations now, where we've moved to an empowered product model. As it is with my organization now, the designer's team is their product team. They're part of the design organization, we all work together, communicate, it helps with our ways of working, but their team is their product team, and so obviously it makes sense to sit with them. But in various organizations it's quite funny, the designers have often been the most reluctant to actually sit with their team. Designers really like working with other designers and bouncing ideas off, which makes perfect sense. We want to have a creative space, we want to work together. But in modern product design it just makes more sense to be sitting with the rest of your team. It is funny, often the leader of change, if it's actually my organization and team, that's who I have to work the hardest to get to sit with the rest of them.

[00:17:51] Noah: Yeah, I like — because change is such a broad topic, I like these examples, because you can kind of pick at them and be like, okay, what's going on there. And with that one, sometimes I think about it as, if design is, as you mentioned earlier, understaffed at most companies, it can be a kind of lonely or isolating role. You're looking around to see, does anyone else see what's going on, do we feel the same way? And so sitting together makes a ton of sense in that context, where it can be a therapy group, it can also be a chance to generate a bunch of stuff. But fortunately, if there are ways to influence change in the way people see the role, then they can hopefully have those same kinds of moments when they're with a different group of people. And at least for me, I get the most energy when I'm jamming with someone on something, literally just that almost improvisational back and forth when you're coming up with an idea or working through a problem. That stuff is really fun regardless of the role or who's there. And so yeah, it's interesting how each of these examples of change might come with different constraints or different challenges.

Retros, stakeholders and closing the loop

[00:18:44] Muriel: Yeah, and to add to that, it's not just that we're centralized. You have to have an enormous amount of interaction with all the different portions, otherwise it just won't come out good, period. No way. If you're in isolation it will not work. So a bunch of the things that we did to adjust the process, the ways of working in my organization: almost every sprint, since we have retros, I really want to hear from people what worked, what didn't work, and then we have immediate action items and then we integrate these action items the next week. So it's like a never-changing ways of working, and we try to pull in a bunch of other people to weigh in as well. Something might have gone not the best way. I don't like saying wrong, but can we make it better? How is it actionable? Everything, so you don't just stay like, oh, this was bad, this was good. I don't like the word bad. What didn't work, and make it better.

[00:19:28] So one of the things we did to close that loop is that we have stakeholders, and these stakeholders are essential, without them we cannot start. We do have our own board. I'm a big, big advocate for that, I can explain later why. But one of the things we have to have, because we have our own board and it's separate from the other boards, is that we have to pick a back-end engineering stakeholder from the inception through the low fidelity prototype, which I would argue is the most important step before you go into visual design, which is kind of automated in many ways if you can, the design systems in a way. And also invite a PO and a PM. And without these three stakeholders in a room, for big features, we're not moving forward. And this is big, because those are table stakes, and without them I do think you work in isolation and you may create a very beautiful, fun, tricky thing, but it may not work for this trifecta of important people and their customers. So it's about both in a way, if you can pull them in, awesome.

Mourning the old process, and who holds on

[00:20:26] Noah: So another thing I'm wondering about with change here is, whenever there is one that's introduced and there's a moment where people are having to make an adjustment in their process, their way of working, is there a moment — I read something recently that was talking about having these, if you, we changed, we grew to a size where we could no longer be in the same critiques, we used to all be in the same room having those jam sessions, whatever, you get to a point where you just can't do that. And we even had a standup channel where people would post their work, and it just didn't scale with the number of people. And so what we did was, we read that it was kind of a fun idea to almost mourn your past processes, but in a fun kind of way, almost like throwing a party, like a goodbye party for the last process. And I always thought that was a super interesting concept, to just be like, hey, we know that this type of change might be hard, you might be used to doing this for a while, so let's grieve that out in whatever way you need to. Literally we made a highlights reel of the posts people did in that old channel that was going away, so people could feel like, yeah, that was a cool moment, and now we're in a new moment and we're going to do something different.

[00:21:26] I guess, do any of you have examples where you had some people that were still kind of holding on to this old thing and you were like, oh please, we're in this for whatever reason, the business changed, the team size changed. Anything that comes to mind for either of you where you had to kind of pull someone along, or maybe they did, whatever happened through that?

[00:21:47] Alberta: So I expect this is different depending on the organization, primarily size, age, scale, maturity. What I've seen in my teams is, because at least in the last few jobs I've worked with fairly sizable design teams, there is some sort of Darwinian selection. If you struggle with, not so much accepting the change, but with adaptation to a different way of working, not sitting next to your colleagues rather than doing whatever it was that you're used to, eventually you self-select and move on. And it's a terrible thing because sometimes you lose very valuable people, but at the same time I feel it's part of, it's the best for them. Some people really do struggle with just radically disrupting the way they're used to doing things, and that's totally fine.

[00:22:52] I suppose the best adaptation, so the flip side of that, was seeing people absolutely resistant to anything that they saw happening on paper or on a screen, and rejecting outright attempts at connections that weren't sanctioned by some protocol, and in their mind, exclusively in their mind. And I've seen them turn around when they were approached by, you know, again, Trojan horses are my favorite animal at this point, but by younger, more junior members of the team. Generally it was not by design, it was a very organic process, but they were asking for mentoring, when in reality they were mentoring them back. And it's a beautiful thing to witness.

Juniors, reverse mentoring and design ops

[00:23:45] Noah: That's a great thing to hear, especially because I've been hearing that the industry isn't making enough space for entry-level designers, and hearing that is a good reminder for companies of, you think of it as, oh well, we're spending all this time training this new individual in the team, but you're right, it's bi-directional. The people doing the mentoring — I don't know if any of you have hired interns before or new grads, the energy shift is really palpable. These are people who are coming in hungry, excited, and I know a lot of companies are worried about the change of, can we support a designer who hasn't done this before, but you're absolutely right, it's so noticeable when the team look and they want to help, and all of a sudden there's just a different, you know. Maybe this is too meta or too philosophical, but there's change in life all the time and we're constantly evolving and seeing new students and young people going through things, and if you're not embracing that, then I don't know, are you living, are you even, you know. So anyway.

[00:24:35] Alberta: Yeah, I suppose, sorry Mike. Just to conclude the thought, I suppose this is one of the advantages of working in enterprise. There aren't very many, but one of them is that tendentially they're fairly design mature, so they don't even think about whether you will have the energy and time to support someone fresh out of school, because we have graduate schemes and we have internships, et cetera, et cetera.

[00:25:02] Noah: So you sneak them through, effectively.

[00:25:04] Alberta: There's horses everywhere.

[00:25:05] Noah: Yeah, cool, yep, absolutely.

[00:25:08] Mike: Yeah, but I'd just completely agree that balance in the team is so important. We actually had a junior designer start this week. I wasn't there most of the week because I'm here, but it is great, because if you speak to any product team, the product manager, everyone else on the team, they prefer to have a senior, but not all the work is going to be senior, and it's not helpful for energy, for team morale, to have a whole team of seniors as well. Having that balance is really important, and it's exciting for everyone to see people grow and develop.

[00:25:35] Noah: Yeah, we added recently our first design ops hire, which is a function that I'm sure is relatively newer in some ways, but in other ways there have been forms of program management and versions of it inside of disciplines for decades. But it's been really cool, because I think as leaders we probably spend a lot of our time thinking about how we help change our organizations, but when you have a partner in crime who doesn't also have the bandwidth of managing large sets of people but can actually think about how that organization is working, it's almost like what I think consultants — I've never been one, I don't know exactly what that works like, but I'd imagine that that's part of the advantage. You can come in with this fresh perspective, you're looking at how effective it is from the outside and suggesting changes. And so far it's been amazing. Kai, we brought in, has been wonderful in thinking about onboarding processes for people, and that's a form of change, someone's coming into a new job and they're trying to learn what it's like and how to do it.

[00:26:24] And I think another thing we've been trying there that was interesting is thinking about changes as experiments sometimes too, which, maybe depending on the company you work for, I don't know how controversial of a term it is. But for us it's just like, can we not think of change as such a drastic shift, and instead be like, why don't we just try it this week? And it's not like you're announcing and you're planning a big reorg or something, but you're like, hey, this week we want to try this thing. I think you've alluded to that too in talking about some forms of these sprints and so on. So yeah, I don't know, if that incited anything, if there's anything you're thinking about, then maybe one or two more responses, and then if we have time we'll do some questions.

What I ask new joiners for

[00:26:56] Muriel: I'm really intrigued by new members of the team. It doesn't have to be a junior person. I always ask for two things from them, because they're invaluable, they have fresh eyes. We don't have fresh eyes on anything, so we don't really know what sucks and what's working. So the first thing I say is, hey, you're new, I don't mind your role, your level doesn't matter, I want you to write me, just can you write a diary every day of the things you have to go through, if it's onboarding, if it's company onboarding or team onboarding documents. Be the most critical you can possibly be and give me a diary of your first week. I want to know exactly what worked, what didn't work, and can you make it better? That's the only way I can actually have gorillas[?] into what's happening.

[00:27:36] The second thing is, I love not letting people know any background. I don't want them to read anything about the product, and I want them to go through the product suite and say what they figure out themselves and what's not. Now, some of the things are high-end or very niche customer base, so they need to know a bit more, but I love throwing them into the things that are more, interestingly, admin level, which many times are really high roles in some very big companies such as GNC and Chico's and Gap even. So sometimes people are actually not fully connected to the smaller roles, or, that was a really wrong word, the lower layer roles. There's no small or big role. And I like sending them into just writing me again good, good medium, bad, anything you saw that you really liked, anything you saw that you really don't like and why. It's invaluable, you can never get it again.

[00:28:25] Noah: There are a few things I think are interesting about that. I think the idea of intermixing roles as well, and like you mentioned, just through hierarchy in a company, are people actually interacting with different roles, let alone people in their own functions? I've been at companies where everyone takes a role in the support team for a week, or in our company we have every employee join a critique, a design critique. It doesn't matter what function you're in. We don't tie your hand to it, it's optional, but we highly encourage it, and it's awesome. It's really fun to get to learn about each other's disciplines and what happens, and it's a great way to also help with change, because what you're doing is you're smoothing things out a little bit, where people build empathy for their roles and what they have to do. And if there's that layer of trust there and they understand it better, then they're more likely to be more malleable or want to be interested in shifting something together, because you know where you're coming from.

Q&A

[00:29:13] Noah: So we're almost out of time and I wanted to make sure that if there were any questions, either if you're trying to work on a change personally in your company or you've experienced one that you want to share. I know it's tricky to do audience questions historically. Or ways of working, because I think that was essentially the original title, changing ways of working. If you have any questions about that, either one works. And if not, if any of the panelists have other anecdotes you wanted to share but didn't get a chance to share.

[00:29:38] Muriel: How many centralized teams are here, of design and or research? If you're in a team that is only designers or only researchers and you feed other places, can you raise your hand? Wow, very little. Interesting.

[00:29:54] Noah: That's like the underdog. Okay, cool.

[00:29:56] Muriel: Do you mean centralized, just all the designers together in the same — yeah, they feed other departments. We got one.

[00:30:03] Audience: Yeah, first, thanks for all these insights, that was really, really fun to listen to. So I have a question and it's about feedback loops within establishing these new ways of working. How do you make sure that the feedback you get is honest?

[00:30:21] Noah: Good question.

[00:30:24] Mike: It's a great question. I think, in the example I talked about before, when we implemented large-scale change we got a lot of direct feedback. Some people, the more confident people, were very vocal in giving that. But in our organization we were conducting multiple surveys, we had lots of workshops to try and find out, using lots of different methods, to try and get feedback on how it was all working. But the problem with that, as I said, was a lot of that was after the fact. The decisions had been made, we're already making the change and then we're getting the feedback afterwards. It would have been nice to try and make the whole thing a bit more collaborative and consultative at the start.

[00:31:00] Muriel: I have a few. I was thinking about it while you were talking. It's great to be the second speaker, because then you can think. The first one is modeling. You have to show it yourself, and modeling not just by giving feedback, by getting feedback as well. As a head of a department it's maybe a bit unusual, but I do that sometimes, like, can you give me feedback about the offsite we just had, please? Feedback is caring. If you don't care you won't give me feedback. Can you care and give me feedback?

[00:31:25] And the second thing is framework, that's really big. There are a lot of really blunt feedback givers, they're not really useful to many people. There's sensitivity, and a lot of designers are introverted, so I set up the ground rules, or guardrails, for giving feedback properly. Because there's honesty and there is bluntness, and there is caring direct feedback, I think direct is caring, and there is not nice feedback and not kind feedback. So set up the guardrails, and you can set it your own way with your own company and how you usually speak, and then say it at the beginning of every meeting as a reminder, every meeting with feedback giving. At some point it will become second nature, but in the beginning it's important. And call people out directly when something is off.

[00:32:03] So I recently had to give an example — actually, you know what, we can talk about something old that was really, really tough. Someone was very smart and very talented, that was like two or two and a half years ago, and he came in, he was an architect, and he gave feedback that was really horrifying in a way that is not constructive. So what he noted was correct, but the way he said it was so mean and not useful. I called him out immediately in the meeting, live. He said, this, I don't know if it's very pretty, I think it's a little ugly, I think the placement is incorrect, and XYZ. So he kind of put it as it is without any constructive words, and it wasn't building, it wasn't challenging the next teammate. And I called him out right away, I was like, okay, that's not very useful, what doesn't work in it specifically, can you give me specifics, and then, do you have an idea of maybe how we might make it better? Just reshaping it live.

[00:32:54] So calling out, excuse me, but also then speaking to them later and saying, I want your feedback, I want you to frame it better, do you want to work with me on that, we can do a workshop. That's important. The other way around as well: if you have introverts, call them out, hey, what do you think about that, how do you think it may have been done better, do you have any ideas? So you have to call people out, you have to set up the ground for that.

[00:33:17] Noah: This is a great question, thank you for asking. I wish we had more time, because I feel like feedback alone probably could easily be a whole half hour discussion in itself. There's so much nuance in it, even cultural differences between companies and the way that feedback lands in those different places. So really, really great one, but unfortunately —