Measuring Success in Design through Shadow IT and User Feedback

Transcript

[This transcript is auto-generated and lightly edited. Please forgive any copy errors.]

Jesse: I’m Jesse James Garrett,

Peter: and I’m Peter Merholz.

Jesse: And we’re finding our way,

Peter: Navigating the opportunities

Jesse: and challenges

Peter: of design and design leadership,

Jesse: On today’s show, one of the largest scale and highest precision plastics manufacturing operations in the world belongs to Denmark’s LEGO Group. LEGO’s Rebecca Nordstrom leads the team designing the software they use to produce those billions of little bricks. She joins us today to talk about bringing UX to the factory floor, measuring success when user adoption is mandatory, and the differences between leading design in North America and in Europe.

Peter: Thank you so much, Rebecca, for joining us today.

Rebecca: Thank you for having me.

Peter: Typically we start our conversations with a very easy question, which is: who are you and what do you do? What’s your job? What’s your role? Tell us a little bit about yourself.

Rebecca: Yep. So I am the head of digital product design for our area inside of digital technology inside of the larger LEGO Group. So, LEGO Group is a little bit of an onion organization, if you will, and inside that we have digital technology, which is responsible for all of the external digital tools that our customers and play experiences support, but also we have a lot of internal. And then I am in charge of a digital product design team of around 20 folks and we are primarily supporting internal-facing applications. So, these are supply chain and manufacturing. So it’s a little bit of a different flavor. And I hope that listeners are not disappointed that we’re not going to talk about the fun LEGO play experience. But I think we really do some fabulous work where it is focusing on enterprise design work, supporting folks in the factories, folks in supply chain, and it’s a lot of really tricky, complex problems. But we also get to deal with a lot of kind of cutting edge technology and the things that we interact with, which is really fun.

Peter: You mentioned the factory and supply chain, like I’m assuming there’s like internal design and development. What’s your relationship to that, if anything?

Rebecca: Yeah. So for the internal design and development, we have product teams, and my team is the design resource into those product teams. And then we have product managers, which sit on the business side. And then we’ve got engineers inside those product teams as well, which sit kind of in the same area as me in digital technology.

So, the product teams straddle both sides of the organization, if you will, and then they are dedicated into kind of user group areas within LEGO. So we have a product team, for example, all around packing. And so that is supporting all of the packing functions that help produce the finished LEGO good that leaves. Yep. I don’t know, I feel like, I feel like the stuff that happens behind the scenes in large organizations like LEGO is like this hidden gem that nobody really ever talks about or looks at, but there’s so much interesting things and like fantastic work happening there.

Design for Internal Tools

Peter: What’s the top thing that no one knows about that you wish they did?

Rebecca: I think one is that we, we strive to create those play experiences for our internal employees inside LEGO as well. So even the factory workers should get that fun, enjoyable experience because we have that people promise to them. So we are creating, you know, polished end products, even with like the little microinteractions and animations and all of those things into it, for the factory workers.

And I think that’s something that, unless you really, like, pull back the cover, you would never know that about LEGO. And we do that in a lot of organizations, actually, not just LEGO, but I think we have a high promise to our employees in that way.

Jesse: it’s fascinating to think about the tension between playful experiences and supply chain and manufacturing logistics. And so I am curious about how products even get conceptualized in an environment like that. I feel like a traditional, kind of, requirements definition approach is not going to quite capture it for you guys, right?

Rebecca: Yep, so typically we are approached with a business problem that needs solving. Either that we need to cut down the cost for manufacturing the finished good, that’s the one that we are constantly kind of battling year over year, because we always need to drive down cost, right?

And so then what we do is we work with business.

So the designers will go out and start researching with business on the processes that they’re involved in and start to identify different areas where we can change the process, and so, in that way, a lot of time, we’re not doing kind of traditional digital design in that way, but it’s really looking at end to end process, and how do we redesign the entire process and experience that we’re supporting in the shop floor. And how can digital tools play a role in that, and then working together with business to kind of tear that apart and put it back together.

Jesse: I imagine that entails a different kind of a partnership with the business than you might see in other places. Because you need that deep process expertise at the table, right?

Rebecca: Yep, so we have designers embedded into the product team. So they’re not, we don’t work as a agency or consulting centralized team. We’re embedded into the product teams, and in those then the designers over time are getting those relationships with all of the stakeholders in the business, but they’re also getting a lot of domain knowledge in there.

So you can go in and talk to the designer that’s working in the molding area and ask her about all of the different settings and all of the processes to do with like molding and manufacturing. And by the way, LEGO is the largest producer of tires in the world. If you don’t know that. So like we are, we are a massive manufacturing company actually, and that’s kind of at heart of what everything does.

And so the designers really deeply know those areas and those processes, and they are experts in their own way of that. But also you need that expertise to be able to talk to business about it too, because it’s not, it’s not an app for buying a cup of coffee where it’s super relatable,

Jesse: Mm hmm.

Rebecca: it’s getting into these really complex and engineering-focused processes. And so you have to be able to speak a bit of the language with the users for them to trust you and to open up.

Peter: Nothing against apps for buying cups of coffee.

Rebecca: No, those are, those are wonderful too, but I think, I think it’s like a totally different end of the spectrum of like what we deal with. Yeah.

Peter: I’m wondering then, as you’re looking to build your team, right? Because you’ve had looking at your LinkedIn, I’ve seen you’ve had jobs in corporate America. I don’t know exactly… I saw Capital Group and Kaiser Permanente, so large legacy organizations. Then you’re now at LEGO. You’re working in this really specialized environment, like, like an uncommon one.

Hiring for specialized environments

Peter: Not that many people are probably working on the design of manufacturing and supply chains. And I’m wondering how that, that has caused you to shift how you approach recruiting and hiring, or your orientation on skills. Like what is it you’re looking for in building your team that might’ve been different than the kinds of things you were considering in the past.

Rebecca: Yeah, I think one is, people that really fall in love with the problem, right? So it’s not people that are super focused on the solution all the time, but that can really fall in love with the problem. So they are willing to spend time investigating that problem, spend time understanding it, and really understand all of the, the nuances and edges to the problem.

So we get these like really crazy wicked problems of… you have all of these VPs and stuff and they’re looking at it and they’re like, we don’t know what to do. And then we get some of the design team in there. And so they need to fall in love with that problem as number one and really enjoy that it is complex.

And you’ve got some really amazing designers that that is their sweet spot. They don’t, they don’t want the, the easy showy stuff. They want the stuff where they know this is going to take a bunch of iterations to really smooth this out and understand where the places that we can move and where are the places that we can’t move.

So I think it’s, it’s that problem that’s number one and then the other one is just really strong collaboration skills, because part of what we also face on a regular basis is the change management portion of design as well. So for like consumer-facing things, you can kind of release it. And then the adoption of it as a proof point that you’ve made something of value to the consumer-facing audience.

That’s not really true when you talk about internal applications, because it’s a mandated use of those applications, and so the adoption of it and the change management of that is a totally different beast, right? Where you need to be working with the training organizations to understand what are their obstacles around the change that you’re proposing, working with all of the different local teams that should be adopting it to also understand what’s their point of view because they adopt, like, local practices towards their work as well.

So it’s kind of the problem, and the stakeholder management, and collaboration and the ability to kind of lean into those things. So it’s, it’s maybe less of a traditional design role where you’d get a brief and then get to kind of rock and roll and create something that’s really, really fun in that aspect, but enjoying the other types of problems in there.

Jesse: And in your role as leader, how close do you get to these problems?

Rebecca: So when I joined LEGO Group five years ago, I was actually an individual contributor in a team. And I was the first designer that they hired in to my area inside LEGO Group. So at that point I was kind of acting as individual contributor. And then over the last five years, we formed a team of 20 people and I’m head of this larger department.

And so I’m more triage for some of these things and to be the glue between all of the different applications that we work on as well. So when we have supply chain and manufacturing, all of those pieces need to kind of flow together this bigger system design. And so my role now is kind of to look across and to spot where we need teams to be collaborating, where do we need designers to be collaborating, and then encourage as much as possible for our designers to steal from each other with pride. Like don’t, don’t keep reinventing something. Like we have our Figma files completely open and people should be in each other’s Figma files. They should be copying each other’s work. They should be leaving comments and asking questions and trying to, to bridge it so that it is cohesive across.

Jesse: Well, it’s this interesting balance that you have to strike because you have this need for deep specialization and expertise, kind of team by team. But then you need something that’s going to hold all of them together in some way. How do you do that?

Rebecca: I think one is, so I’m partnering with the heads of product in that way to create kind of the bigger picture of those larger cross-product initiatives that need to happen. And part of that is also the vision and they’re calling it roadmap. And I really cringe at the word roadmap usually, but, so they call it roadmap of where manufacturing should be going.

So part of it is to see, okay, in, you know, 3, 5 years, what is the ambition from the LEGO Group of where they want to bring supply chain and manufacturing, and from the knowledge that I know about the product teams, how does that piece together to move towards that, and then we have a lot of recurring sessions together with the heads of product and engineering and the product teams to then review what they’re planning to work on and get it there.

So I think it’s more in that trio function, I’m playing at kind of like that leadership level to then steer the direction of the product teams and help coach the designers to support that bigger vision.

Jesse: Mm hmm.

Rebecca: But it’s, it’s chaos, honestly, right? Like it’s, you know, it sounds all good and it sounds like we have a nice plan and a path there, but it is constantly things popping up and it is a bit chaotic, but that’s part of the fun.

Peter: Chaotic because you’re responding to what?

Rebecca: Chaotic because we have 30 product teams and 600 plus applications inside those 30 product teams. And then we’ve got 5 factories, soon to be 7 factories around the world that each have their own set of stakeholders and want to have a say in what’s going on? So it’s, it’s a big communication game sometimes.

Jesse: And are you also operating in that trio mode when you’re engaging the stakeholders?

Rebecca: Yep. So we try to have the trio within the product team. So with one of the designers in the product team, the product manager, and one of the more senior engineers, and then we also have the trio at the leadership level. So head of design, head of engineering, head of products working together and this kind of trio at the leadership level.

That’s the one that is engaging with a lot of the different stakeholders across the factories and across the supply chain, because they also have those kind of leadership hierarchies and are trying to put together plans at these wheel levels or leadership levels. Yeah.

The intersection of physical and digital

Peter: And you’re… I’m curious. You’re the head of digital product design. So your team is largely building software or designing software. And that’s what these groups are doing. But I, I’m imagining there’s a need for integration between your software stuff and some form of hardware physical manufacture… like when I think manufacturing I’m thinking giant robot arms moving things around, and so like, where does your design end? Where does other design begin? How do you coordinate and integrate with teams to make sure that it’s all coming together? Given what you said about the chaos, I can imagine part of the chaos is all these different modalities and kind of ways of working.

Rebecca: Yeah, no, you’re totally right about that. I think with the integration with the hardware that’s in the shop floors and the factories, that is a different team. So there’s a operations technology team that handles the purchase and design of that hardware, but by and large, it’s off the shelf purchases for that.

So that team is kind of screening which hardware we should purchase. And then it would come into ours to deal with, okay, how does somebody actually interact with that hardware now? And more and more we’re learning that that decision, when they’re purchasing the hardware, needs to start engaging with the design team as well, because we see that we purchase a lot of hardware where there’s built-in interfaces that are completely unusable, or there’s clashes between the way that the hardware operates and the process of how the user actually needs to interact with that hardware. So, I think more and more, we’ve kind of learned our lesson that it needs to be this holistic approach where we have the design team, the product team, and this operation technology, all looking at the tools that we’re buying, both in terms of software, but also hardware, to make sure that it actually works together.

And we have a couple more collaborative initiatives that we’ve been running more recently where that’s been really successful. And it has been a nice kind of proof of concept of that collaboration. But I think the integration with the hardware is really like a fun thing for the team, actually, because like, you know, you, you’re doing something and you can physically see how it is interacting. And then we have some initiatives where the team, even though we’re digital product designers, we are designing things directly onto the hardware as well.

So, whether it’s signals with lights and sounds and things like that, or screens that we’re mounting onto the hardware, that sort of stuff.

Measuring success

Jesse: You mentioned earlier that you don’t really have, you know, user adoption to guide you in terms of evaluating the success of a design, the success of a product. How do you measure the success of your work collectively, but also specifically for design?

Rebecca: Yeah, I think one of the key things that we try to pay attention to is gray IT or shadow IT, depending on whatever you want to call it, but the systems and workarounds and tools that users are often creating themselves, because there’s a gap for them. Something is not working for them, so they’re going to solve it themselves.

Jesse: hmm.

Rebecca: So that’s a really good signal to us that something has gone wrong, or we’re not supporting the right thing. And so that’s often something that we are trying to pay attention to. Do we see that the shadow IT is going down? Do we see new things popping up in that area? If so, then we need to go do some research and figure out, you know, what’s going on. What need do you have that is not being met by the tools that we’re giving you?

And another thing we’re trying to do is to get more data into the tools themselves. So, get user feedback integrated into the tools. So, just like a consumer app, they can rate the tool. They can provide feedback into the tool. They can capture screenshots of what’s going on and write back to the team and say, “Hey, this needs to be different.” So to get that feedback directly in from the users, interacting with it, and then also get analytics into the tools so that we can see that they’re actually completing the process that we want them to complete, but where are they getting stuck in there? Where is it taking too long or where do we actually see, because we kind of own the whole ecosystem, where do we see that they’re leaving this tool and going to that tool and coming back to this tool, because then we need to integrate.

Peter: Kind of related to that, I’m wanting to go back to your story of 1 to 20, right? You started as a team of 1, now there’s a team of 20. In order for that to happen, I’m assuming value was made very clear and explicit. What was the nature of that value? How did others recognize what it was you were doing? How did you then build momentum to scale this organization? How did you have to navigate the organization? Were there any politics involved, or was it a fairly straightforward kind of business case? ” Let me hire 20 people. These 20 people can realize, you know, n number of millions of dollars in cost savings” or something like, what’s that story of, of one to 20?

Nurturing organic growth

Rebecca: Yeah, it’s, it’s really a very organic story, actually, and we still have the debate within the team and with the broader design community about value. And I think it’s something that we see people talk about all the time. What’s the value of design and how do you quantify that? But actually, I, kind of disagree with the whole concept that we should quantify the value of design.

And I have not, I’ve not been a super vocal in LEGO about that either, because I think the value of design is in the success of the product, and it’s not a separate metric. It’s not something that we should be creating separate standards for design than the rest of the product team. Like, we should be functioning together with them.

The success of the product is the success of the design. And so I think that’s mostly been my approach towards it as well. I think the thing that helped traction in there is that I started out on a project that was the third or fourth time that LEGO had tried to do it. And each time it had failed and cost several million crown, so hundreds of thousands of dollars, right, each time it fails.

And I think they’d been trying to do it for four or five years at that point. And I came in and I took a design thinking approach and it was different than how they had approached it before and it succeeded that time. So I think the proof in the value in that was actually that it did succeed, that it was successful.

It was a different way than how they had thought about doing it because we involved the users in the creation and the design of it through workshops, through research yeah, and involve the stakeholders in the testing. I actually got a lot of the stakeholders to be running the user testing themselves, which was a nice one.

Jesse: Nice.

Rebecca: Yeah, because they, because you know, like in these super specialized areas, you have these people who are SMEs or subject matter experts, and they want to own everything. They want to own the voice of the end users and be the representative, and that’s kind of their role in the organization. And one of the only ways that we kind of got around that was to have them be the user testers. So we say, you can own it, but you need to take this and then go actually run the tests for the users. And we train them in that. So I think the kind of success and pitch to the LEGO Group to build the team was just in the success of the initiatives that I was part of. And the fact that because I was part of them, they ran differently than they had previously.

Peter: And so was it a matter of demand was being generated, and you were simply meeting the demand. More product teams are seeing that success and saying, Hey, we want some of that. And it’s like, well, you’re going to have to hire some new types of people and we’re going to have to engage in some new ways of working. And it just kind of slowly built over time.

Rebecca: Yeah, it was, it was super organic like that. It was that that product started getting some momentum. We started getting some success in that people that I interacted with as part of that process said, Hey, can you come over and look at this other thing and help out with this? And it just kind of snowballs, right?

So you start to get a reputation in the organization and it’s a very relationship-driven company at the LEGO Group. So you start to get a reputation, you start to get more people requesting you as a resource. And at that point I still wasn’t officially a manager or anything like that. So what I did was I started hiring in student workers cause I didn’t need approval for it.

Jesse: Ha, ha,

Rebecca: So I talked to some of the other managers and I was like, Hey, I’m going to hire in this student worker officially, they need to report to you, but I’ll take care of everything. So don’t worry about it. So we started kind of building the team there and getting different students around. And luckily I went to graduate school here, so I had relationship with some of the universities and things here already and the design programs. So we just started bringing people in, and over time, they were kind of like, okay, well, maybe they should report to you. I’m like, okay, cool. So then we just started kind of building from there. Yeah, it’s been really strange to look back at it and that it’s changed so much in 5 years, but it’s also been really organic and kind of natural in the shift there.

There’s not been any big battle or pitch to it. It’s been based off of demand.

Peter: What I’ve seen over and over again, as organizations grow, is there’s a point at which you can’t run it organically anymore when it’s six, seven, eight people, you can run it organically. It’s enough people that fit around a conference table. You can manage it pretty directly.

When it’s 20 people, you now need to put some systems in place and some processes in place, or the chaos you were referring to kind of affecting you, you’re generating chaos if you don’t have something. So was there a, a liminal moment where you had to like, establish some organizational practices just within your team, to kind of manage this organicness. What did that look like? What ended up working for you?

Liminal moments in growth

Rebecca: Yeah, I think there’s been a couple key points in that journey where we’ve had to step back and say, okay, we need to restructure again. One was with me getting to the place where I can be holding the same conversation with the engineering leaders and managers, and then the product leaders and managers as well, so that we weren’t getting pulled in last moment into things as designers.

And I think this is super-typical, right? They like, they’re going along and they have all these ideas and then they get there and they’re like, oh, we need somebody to make it look nice. Get the designer, right? So we needed to shift that at some point and make sure that we were up front in the work and part of the discovery and the research going into it and part of the foundation to the work. So I think part of that is getting me into the right place.

Another one was when we started having design managers below me. So that’s also kind of a different shift, right? So you like leader of individual contributors and then you start being a leader of leaders. And that, that was actually really hard because you kind of let go of a little bit more there. And you think like, you want to know all the details. You want to know what’s going on in the product teams. And then you need to step back and let somebody else handle that and just trust that it’s going to go, but they’re not going to do it the way that you would do it if it was you running it.

And so it’s a little bit of like, you know, passing your baby to daycare when you leave like maternity leave or something, right? You’re like, I trust you. I’ve read good reviews about you. Please take care. Yeah, so there was a little bit of that when we shifted having the competency leads or the design managers below. And then recently we’ve seen that we really needed to align more across the different squads now that are inside our design organization.

And so with that, we’ve made a design definition of done, to help manage expectations toward the designers, but also to give them a clear role in the product team, because their role inside the product team was really varied, depending on the maturity of that team.

So, for the really mature teams, they were integrated into the product trio, they were part of the decisions, part of driving the strategy. For other teams, they were getting, the UI work at the end, just in time for getting it out the door, but not getting integrated into the rest of the discussion. So we started working with a definition of done for design in there. Was a bit strange because I thought they would have one for the engineering as well, because I always picture that it’s like more mature than the design inside LEGO, because design is so much younger. But actually we see that the engineers are taking a lot of lead from the structure that we’re starting to put with design now, which is interesting.

Jesse: That is interesting. It’s interesting to think about the influence of your design work and, for want of a better term, design thinking, extending beyond design activities, and I wonder, what advice you have for folks who are trying to extend their influence beyond design in that way?

Rebecca: Yes. I don’t know that I have a magic, like the golden ticket of advice there. But I think at least my approach that has worked for myself, and I think everybody’s a little different, but what’s worked for me is to have in my head kind of where I want to drive things and then to not say no to opportunities and engagements and then just make those what I need them to be, if that makes sense.

I can give a example that today, one of the heads of product came to me and they’re like, yeah, we need to do this thing around adoption within the factories, but from a compliance point of view, right? So, like, with the chief operating officer for all of the manufacturing across LEGO that he’s really interested and the factory is having compliance and stuff like that.

So he came to me, can you help with that? Sure, why not? Not, not my field that I play in typically, but I think I’m really good at looking at those things and then thinking, okay, what’s the opportunity in here to, like, help my team move forward in there? So, like, in that example, I can see that we can talk about user adoption and there we can make sure that teams are better at getting those metrics in place. Getting the feedback in place.

So all of those things can actually help ladder for that bigger story that they need that maybe is not traditionally design, but design can have a point of view and a voice into it and benefit from that getting there. So I think finding those little connections and ways that like design can help, but it can also help design in the backwards way. Those are good ones to spot.

Peter: I’m wondering these five years you’ve grown organically, if you’ve seen certain things work and other things not work, right? And what are the things maybe that don’t work that you’re like, let’s not do that again. Let’s not try to evolve in those ways and instead lean into the things that have worked. What has shaken out in that way for you?

Balancing structure and autonomy

Rebecca: Yeah, I think something that I’ve learned over time is the need to provide structure and then back off. So when things grow organically, I tend to just be like, yeah, of course everybody’s on the same wavelength. Like we’re all moving together. We’re all, you know, it’s like we’re dancing together, right?

But when the team starts to get to a certain size and when you have people of different maturity and experience inside design, you really need to provide a good frame for them, clear expectations, and then back off and let them do it. And that was like, that’s a really painful lesson to learn, honestly, because I want to trust everybody on my team, like, 110 percent and know that they have best intentions and believe that they are capable.

But sometimes I’m too hands off and believing in their good intentions. And then you kind of get burned from that because things are not turning out as they should be, right? And then you need to step in. And so I’ve kind of learned over time that it’s much better to get those clear expectations, even a little bit too harshly and then let them run, rather than think that it’s okay and have to come in later.

Peter: Is that where the definition of done has, has kind of emerged? What does that even, what does that mean?

Rebecca: Yeah. So the definition of done is like requirements that we’ve put towards the product team of what they need in place before they are allowed to go live with something. So, from a design perspective, they need to tick all these boxes before they should be going live with something. And that is partially so that my team also has the right frame of expectations of, I expect you to do these five things before we go live with something. Otherwise, it’s not ready.

So, I think that one works both ways though. So that’s helping the team. Have expectations toward the designers, but also the designers understand my expectations towards them.

Jesse: It seems to me that with so many of these things that you’re talking about, the partnership that you have at the leadership level with product and with engineering, the opportunity you have to go wide with your design explorations and your efforts to understand users and their behavior, the opportunity that you have to be involved in the earliest stages, all of this stuff is stuff that lots and lots of design leaders dream of trying to attain and seems to be just kind of out of reach. So I, I wonder about what is the formula here? Why is this working?

Rebecca: I got really lucky. I have a amazing manager. So I think that is part of why it’s working is that I have really just gotten as lucky as I could get in that I have an amazing manager who really believes in me and what the team is doing. And basically is there to just clear roadblocks and otherwise is like, whatever you want. Yeah, you got it. Like, go for it. Which is fantastic.

So I don’t have a lot of handcuffs or push back from my manager in that. But he is also a really good advocate for me and the team with those other forums as well. So he asks, like, why isn’t design in this conversation? And when I meet new colleagues and heads of engineering and HR partners and things like that, and they ask, how can we support you? That’s usually the thing that I say, like, if you’re in a conversation and you don’t see design in the conversation, ask why, why is design not here? Because I think us being part of that conversation and it’s such an innocent question, right?

Because there’s no bad intent from them from asking that. It’s a, it’s a kind of a very naive question if you want to like, ask in a conversation. So having them ask that on my behalf in the parts that I have not been included with has really helped me get included in them.

Avoid UX fundamentalism#

Rebecca: I think the other thing is, I see a lot of design managers and leaders that I interact with that are very like, kind of fundamentalists. So they, I don’t know if you, if you remember, like, maybe 5 or 10 years ago, all of the job postings, they wanted UX evangelists, right? You had to be like a, an evangelist and go on a crusade in your organization and, you know, tout the benefits of UX design or design thinking. And it was like a war zone that they were pitching in the job posts and stuff.

And I think I’ve intentionally tried very hard not to have it at us versus them or battle in that way, but rather, Hey, you may not understand what I’m doing, but I’m here to help and just invite me in and I’ll, I’ll help you as best I can, and I’m not gonna be super dogmatic about the approach, but rather really, really flexible. And we’ll make it work. And if I play out of field, that’s okay.

So I think that openness and flexibility and the lack of like strictness to the approaches.

Yeah, exactly. That, like, I see people burn so many bridges with that stuff where it’s like, you know, they, they want to like take a design thinking approach and like hell or high water, like they’re going to do it by the book. And it’s like, that doesn’t work, man. Like those things are great. I have a whole bookcase full of books about those things, but that is just the starting point, right? That is not how you actually end up doing that in any organization.

So I think also that really practical approach, if people want to get good traction, just be super practical. don’t kill yourself on the theory.

Peter: I totally agree, but it raises a question, because you were mentioning earlier how your executive is advocating to make sure that you’re always in the room. Design should be in the room. But then what you were just saying is that design is happy to show up, roll up our sleeves and do whatever is needed in order to get things done. And so why design? What is the thing that design, as a function, the team that you’re building, bringing to that conversation? If what you’re bringing is just a willingness to do whatever it takes to get done, clearly there’s something that that has been recognized that your team is primarily responsible for, and I’m wondering kind of how that was defined, how you carve that out, in particular, your relationship with product.

This is something Jesse and I talk a lot about and see, is there’s that uncertainty often, as design gets more strategic the relationship between design and product can get unclear in terms of who owns what or does what. So how have you carved out your niche, kind of established your space, that you and your team are doing, given this need for flexibility.

Rebecca: Yeah, all honesty, I do think our input and role in the product teams is still blurry with the product side. So with the product managers, and then with the more senior designers in the team, there’s often that really blurry overlap in there because you talk about like product strategy and things like that, like, both are contributing into that. Who’s responsible for shaping what those epics are, shaping what that sequence and strategy for rolling out different features and things like that are, it’s often this kind of amalgamation of the designer and the product manager working together.

I think the thing that my team is bringing that is otherwise absent in the product teams is the voice of the user. So it’s not business, and I know that in this case, the user is business, but business that comes from the business side is typically, like upper management, looking at cost savings, looking at, you know, increasing productivity, those sorts of things.

And my team is coming in and bringing the user’s point of view about how is the process actually working or not working for them. And nobody else is willing to do that legwork, figure that out and to represent that and bring that into product team. So I think the methodology can vary. And I think the methodology is what I’m not really like dogmatic about, but the role and function of the designer to represent that user, bring in that voice and do the best thing for the user at the end of the day that I think we’re pretty, pretty strict about.

Jesse: In that relationship between design and product and everybody side by side hashing out the roadmaps and so forth, I start to wonder about how disputes get resolved and how differing points of view get reconciled, in what’s supposed to be a partnership of equals.

Rebecca: So between the product manager and the designer, for example,

Jesse: Yeah, between yourself and your counterparts.

Rebecca: I think within the product team and the designer, and it’s primarily the designer and the product manager that are sometimes stepping on each other’s toes in terms of roles and responsibilities there. Typically, when there’s really bad kind of conflict there, it’s because one is compensating for the other’s role.

So that can be, yeah, we’ve had a couple of different cases where either the product manager is not doing what they need to do, or the designer is not doing what they need to do. And then they kind of are compensating on top of each other and stepping on each other’s toes in that way and then that, yeah, that can be an escalation to the different people leaders in that.

It can also be that, sometimes if it’s the design, they’re compensating for the product manager. Actually, the guidance that I give is to just stop. And I know that sounds really mean, but at the same time, they’re not going to learn to do their job if we keep doing it for them. So sometimes they need to realize like that there is a gap and then stop and let there be a gap there, which is maybe not the friendliest approach to that.

But yeah, we can’t do everybody else’s jobs all the time either.

Leading design outside North America

Peter: One of the reasons Jesse and I were really interested in speaking with you is you have experience leading design and outside of North America. And most of our conversations have been with people in North America, and we’ve gotten some feedback from listeners that they’d love to hear from design leaders outside of the United States and given that you’ve worked in the United States and now outside, I’m wondering what, if anything you see in terms of differences in how you’re able to lead design, if there is anything more broadly societal, cultural, whatever, that you find. I mean, you’re at LEGO, which is probably a pretty weird company, so I don’t know. Or maybe not, maybe it’s typical Danish company, but I’m, curious what you maybe had to unlearn in order to succeed in your new context? Anything as an anthropologist yourself now looking at these two ways of, being, what have you noticed?

Rebecca: I think my experience in different companies in the U.S., so, and this is primarily with Kaiser Permanente and the Capital Group, was that things were very structured, right. So there’s clear hierarchy. There’s the design team, which is sitting with product in both of those cases. It’s very top down and you get the work once the work is defined and ready, either for the manager to then allocate out or the designer to tackle.

So it’s, you’re not kind of opening up to the entire organization, right? It’s very kind of isolated and protected and padded. LEGO is not like that. LEGO is really, so it started out as a family run company. It’s still a family run company, but it’s grown to 7000 plus people. But it still acts like a family run company.

And I think the feedback that I get from others coming from other parts of Denmark in organizations that have joined the team is that it’s pretty similar, where it’s really about, it’s about knowing people. It’s about taking the time to have coffee. So when people onboard, it’s not the work that you onboard to, it’s the people that you’re onboarding to. So you should set up and have coffees with like 45 people to get to know them.

And when you interview, this was so weird when I was interviewing in Denmark, actually. So you go and the first things they talk about, like, I think 90 percent of the interview is not about your profession. It’s like, who are you? How many kids do you have? Where do you live? Where do you come from? Where are your parents from? You know, what are your hobbies? So, it’s all of these things that you’re not allowed to ask in the US, like at all.

And a strange, like, add-on to working in Europe, I guess, but I’m also like the oddball because I’m not Danish and I’m not European. So maybe that also, it affects people’s impression of me and whether they want to work for me. That’s fair. I think part of what I do in those also is I share a fair amount of, like, personal stuff about me in those interviews as well, to kind of make it feel like an equal exchange, which would never happen in the U.S.

Rebecca: And for the design, it’s not so tricky to make sure that we are having, all sorts of, like, folks from all around the world in the team– different, different religions, different nationalities, all sorts of dimensions.

But I think for some of the other areas, it’s really hard, especially in Denmark, because it’s not the most diverse population here. Maybe it’s why they can get away with those questions, too. But it’s not the most diverse, like, you know what I mean? Like, it’s the, the majority of Denmark is Danes or Germans. Or maybe you get, you know, the odd Swede or Norwegian, but it’s not, as many nationalities coming together as you get in the US.

Jesse: So, You’ve been on this journey with this group building up this competency from an idea, bringing these people into the fold. What I wonder about is what’s the next stage for what you’ve created? Where is it going?

Coordinating UX/Design across LEGO

Rebecca: Yeah, I think one is that right now I’m working with some of the other heads of design to get more of a design structure and community across all of digital technology then. So that would be both with the play experiences for the kids as well as the adult experiences and then the consumer.

So LEGO.com and retail and things like that. So shopper retail. So bringing all of those design teams together so that we have some collaboration across, and learnings, because each team has different things that they’re more skilled in, just by nature of the work that they are doing.

So one of the things… we’re having a creative boost around that, where we have some themes that are overarching themes that hit across kind of bigger domains in LEGO.

And so typically product teams are not getting to deal with the themes. So we’re having all of the designers come together, in person, like gather from all the different teams around the world. And then we get to spend some time collaborating with the different designers across, see what pops out of that and then do a big exhibition and showcase with the Chief Digital Officer and see if we can get some of that work picked up into the portfolios. I think those kind of larger collaborations across the design teams within LEGO, that’s kind of where next focus is. Yep.

Peter: Is there an existing design community of practice? Like, is there some connection already, or is this pretty new to bring these teams together?

Rebecca: So the teams have never gotten together. So that part is new. We do have occasional Teams meetings where we’ll get on a call together and maybe talk about topics and things like that. The thing that I struggle with, with those kind of bigger forums is once you get, you know, 60, 70 designers on a call, it’s not really a conversation at that point. So somebody presents and then somebody has a different point of view and like maybe three people get to talk. Or people start to kind of spiral down on a certain topic and you can’t really like lift the conversation into something good again. So these kind of larger forums that we’ve tried to get together with these Teams calls and stuff are a little, they’re a little hit or miss.

So I’m hoping that like getting people together and then having them form kind of mini teams where it’s people that they’ve not worked with before to then tackle these kind of cross domain themes hopefully that will kind of spark a little bit more community there as well.

Peter: I’m also wondering if each of these distinct teams defines design differently, I’m thinking about it from a very kind of operational standpoint, like, do you have a shared job family that your user experience designers are using the same as others, or does every group, because I’ve seen where in big companies with federated design orgs, every team defines it differently, has their own job families, has their own recruiting and hiring practices, their own compensation bands. And then that can create this internal… more chaos as these folks start trying to come together and realizing it hasn’t been shaped coherently across the organization.

Rebecca: Yeah, so we do have one single job family and we have clear descriptions of the different role levels in there. And then the salary bands for each of those is aligned. And so that’s across all of digital technology for design.

The part that gets interesting is that we see some design role starting to pop up in the business side as well. And those are not necessarily falling into that job family, even though they’re interacting with the same product teams. And also the pay bands and stuff like that can be a bit different. So, within digital technology, we’re actually pretty good on the structure there. And over the last year and a half, we’ve been running a lot of workshops and sessions to get input on that and make sure that we’re aligned.

So that part’s pretty set up. But I think because we’re inside the IT organization and then product is sitting over in business, product has started to kind of hire some of their own kind of rogue design roles over there. And then that’s kind of putting a little bit more, intrigue into the story around.

Peter: Are they hiring UX designers or a different kind of like more strategic or service designer?

Rebecca: Yeah, so it’s the user research and service design roles that they’re hiring over there. But the way that the archetype, so this digital product design archetype is written for within digital technology that should cover research and service design inside that archetype too. So it’s, a very kind of bland, broad umbrella for that. And then you can have specialties inside it, but that way the levels and the pay and things like that are pretty aligned.

Peter: I’m curious, as your team has scaled and I’m assuming other teams have scaled, if you’ve instituted some type of design operations capability in order to handle within, say, your team, a lot of that communication and coordination across, you’ve mentioned like 30 product groups and all that kind of stuff, or operations to help keep these different design teams connected. Has that been something you’ve needed to institute in order to maintain this, to minimize chaos and maintain a community, or is it more just being done by the leaders kind of in fractional time?

Rebecca: So, right now, it’s mostly done by the leaders in fractional time. It is something that we’re trying to push. So we’ve tried to put it into the portfolio objectives for the next year. I don’t know if it will get approved, but the idea that we then spin up a design ops across the whole digital organization though, so not having separate ops functions, but rather one across all of the different design works that are in there.

I don’t know what will happen with that. I really hope that it gets picked up because even the tooling alone is like a huge pain point for the teams. Because we’re supposed to have owners for each of the tooling. And then that you have designers like managing licensing and things like that is just a waste of time.

it’s just absurd. It’s like the most expensive licenses possible then, right.

Peter: Yeah.

Rebecca: It doesn’t make any sense. So hopefully that’s something that will come is that we start to get a more mature design ops set up within the organization. I would love that.

I think it will happen though, because they’ve actually set up kind of an engineering ops in the original kind of restructuring with the digital transformation. So, I think it is coming to the maturity point with design that we also should have a design ops.

Rebecca: And I think they start to see that. So…

Peter: …there’s a model there that you can point to and go, it works for that function, we need something similar for ours.

Rebecca: Exactly. Yep.

Jesse: Rebecca, this has been wonderful. Thank you so much for being with us. If people want to find you on the internet, how can they do that?

Rebecca: Yep, best way to do it is on LinkedIn and just look up Rebecca Nordstrom and if it says the LEGO Group next to me, then that’s the right one. There’s also Rebecca Nordstrom in Sweden who gets an awful lot of my mails. So don’t, don’t pick her.

Peter: Sounds good. Thank you so much for joining us.

Rebecca: Yeah. Thank you. It’s been a pleasure.

Jesse: For more Finding Our Way visit FindingOurWay.design for past episodes and transcripts. For more about your hosts, visit our websites, PeterMerholz.com and JesseJamesGarrett.com If you like what we do here, give us a shout out on social media, like and subscribe on your favorite podcast services, or drop us a comment at FindingOurWay.design Thanks for everything you do for others. And thanks so much for listening.