Delivering Innovation

Penelope Barr, Damien Lutz, Rory Madden at UXDX APAC. Video: https://youtu.be/4bP_HADRT14

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.

What stops innovation

[00:00:00] Rory: Delivering innovation. Everybody talks about how they want to deliver innovation and how we need to be more innovative. I think every time you look at the list of the top priorities for the C-suite, it's either revenue generation or cost reduction, and then new innovation is always up there. What we're going to talk about now is asking different people from different contexts. So we'll be bringing back Penelope, but also introducing Paya [?] and Damien, and they'll be sharing their insights on how to get innovation really flowing throughout an organization. So welcome, Paya, Damien and Penelope.

[00:00:40] Paya: Hello.

[00:00:41] Damien: Hi, everyone.

[00:00:45] Rory: I'm going to jump straight in. What I want to do is get an understanding of where you've worked, what style of organizations you've worked in, and what you have seen as the barriers to, or constraints on, innovation in those organizations. I'll start with Penelope.

[00:01:09] Penelope: Sorry, Rory, I didn't hear your question.

[00:01:13] Rory: The question is just around what types of organizations you've worked in. I think from your experience you've done the range, from startups to large companies. And what constraints and what challenges have you seen in those different organizations? They might be different in different organizations. What constraints and challenges have you seen to innovation? What's stopping innovation?

[00:01:34] Penelope: Yeah, thanks. I've worked in startups and the big end of town, and I think some of the key constraints can be brought down to a couple of things. One is the definition of innovation. Innovation is seen as the one thing, and most of us understand that innovation is a spectrum. It's not one and done. A lot of people expect innovation to be done really quickly. They bring somebody in, pop them in a corner that's usually brightly colored, with some beautiful Post-it notes and some great Sharpies, give you a couple of people and a little bit of a budget, and say, "Great, now go and innovate."

[00:02:25] And it's not always understood as a profession, and something that can take a long time, and that brings with it a lot of risk. That's irrespective of the size of organization. So one of the key observations for me is that it's still not really well understood in terms of the time it can take, and what the good conditions for innovation are. It has to be led from the top. It has to have people who actually understand it. It's not something where you can just throw in a couple of internal people who you think are creative and then say, "Okay, off you go. We'll see you back when you've innovated and changed the company."

[00:03:19] Rory: Great, that's a great example, touching on how it's almost a role or a skill: being able to research, uncover the pain points in the market, and then convert that into ideas. Where sometimes people just go, "I'll hire in the chief innovation officer." Damien, the same question to you. In your background, what are the constraints or challenges for innovation you've seen?

[00:03:48] Damien: Yeah, hi. I've worked mainly in digital products, from the big telcos to little startups, but my current role is in government, where we're looking at improving the exporting process, which is a really big systemic project. So two very different worlds. But I would echo Penelope's points about time and risk. Your big system-view projects take a long time to really get into, to get into the detail. Sometimes projects and stakeholders can lose a bit of patience with that and want to speed things up, so details can get lost.

[00:04:29] And in more commercial projects, I think there's this established mindset of profit only. Everyone's in competition, and they're having to invest heavily in short-term and reactive activities that can really drain the market, rather than thinking in a more collaborative and life-centered way that allows for looking at innovation, again, from the system view, but in that commercial space. Because then you can see how those points of innovation that may not be BAU or MVP actually have a direct impact, direct value and return on investment in the commercial space.

[00:05:11] So I think it's the same point: it's time and risk. In a commercial space, things move fast; we've got to react, we've got to compete. It's a risk to spend time and money on these things that take a while to actually return investment, and there's uncertainty in it as well.

[00:05:36] Rory: Yes. So looking at it, people think that it's something that can just happen, and I think you've echoed that there. When you're trying to push constantly for delivery, there isn't really that space, and, as you were saying, Penelope, the expertise and the role to focus on it. Paya, do you have any thoughts on that? What's stopping innovation? Do you have the same kind of profit motive, the difficulty with the role, the people who are trying to uncover that?

[00:06:19] Paya: Sure. I have the same background as Damien. I've been working mostly in digital products, from big companies to smaller startups, and right now I'm with Klarna, a well-known fintech company based in Stockholm, Sweden. Right now at Klarna, people are moving really fast. We have maybe a thousand startups within one company. We are encouraged to do innovation, hence everything is moving really fast. However, healthy innovation is the problem, the pain point that we're facing. Because when the team structure is very decentralized, the collaboration between teams, and also how to ensure the end-to-end customer experience reflects that, is our problem now. So I would say it's not really about profit, but about how to have a healthy decentralized team model. That's what we're trying to solve.

[00:07:36] Rory: Oh, great. That sounds kind of familiar to me: they move fast and just keep trying things. So it's less about that upfront big plan and more about letting the decentralized teams try out things.

[00:07:51] Paya: Yeah. And right now I'm for a hybrid model, where we're decentralized, but we also have someone in the leadership of every expertise to ensure that we're doing the right thing, that we're following the right guidelines, and that we have some kind of principles to guide everyone toward. Because in the end, the customer just wants a smooth experience. So a hybrid model is what I believe in.

Balancing research and delivery in decentralized teams

[00:08:23] Rory: Yeah, that's a great one. Somebody else, I can't remember who said it recently, mentioned enabling constraints, which sounds like an oxymoron. But if you put in the right constraints, it actually enables teams to do more. Can I stick with you there, Paya? It sounds like your teams are quite innovative, but they're also moving fast and probably delivering a lot. Some of the problems that people have raised to me about that decentralized approach is that you have the teams all together, but there might not be the right balance in the teams. You get a situation where it's very dev-focused, and designers and researchers are just spinning their wheels trying to feed; I've heard it referred to as feeding the devs. Do you have that problem, or do you have a good balance, where the teams are able to balance the innovation of research and thinking about ideas versus just building them?

[00:09:31] Paya: That is a very good question, and also on point. Because post-pandemic, or during COVID, we started working remotely as well, so everything around onboarding, and making sure the team is moving in a healthy and balanced way, is really hard for everyone. But right now, in the teams that I've been working with, we're trying to reach a balance where we have enough resources and enough time for every expertise within the design competencies, which are product design, UX writing or content design, and also UX research. And sometimes we have the PMs always insisting, "We don't have time for that. We have to ship something really fast." So it's really tough math.

[00:10:21] But at least in Klarna right now, for every design competency we have, let's say, a product design director, a UX writing director, a UX research director, to ensure that every expertise is something everyone needs to think about when you ship a product. That's what we're trying to do. And for every competency we do have certain design principles, guidelines and processes as well, for how teams have to work: how to work with design, how to work with UX copywriting and research.

[00:11:04] Rory: Excellent. Can I dig into that topic? You touched on a great point about the skill set with decentralization. You said that there are directors for particular skill sets. How do they help? What is the interaction with the teams? Do they do the UX writing work for the teams, or do they help the teams learn that themselves?

[00:11:31] Paya: Let's take an example. In my domain right now we have about 20 teams, but there's only one UX writer, and they have to serve every team. That's really hard on them, and they have to try to educate every team on how to work with the UX copywriting process as well. And the PM for each team has the ability to reach out to the UX director in order to learn more. Right now, actually, yesterday and today, I'm at an offsite with the leadership of every design competency, to think about a better way to educate stakeholders when it comes to the different competencies, and the importance of every design competency when it comes to product management and product delivery.

Uncoupling the UX skill set

[00:12:24] Rory: Excellent. That sounds like a good model, but there's always the challenge of trying to get the balance. Penelope, can I give that question to you then? What Paya just explained is that they have decentralized teams, where they have those people whose skill set is more in research, talking to the customers, and that's helping to drive the innovation. Do you think that's the answer? We just need to get more UX people into teams, and that will instantly deliver us innovation?

[00:12:59] Penelope: I think it would be great to get more UX people into every team, but I think it depends on the kind of organization that you're in. If you're working in a professional services organization, for example, which I was in a couple of roles ago, professional services organizations really guard and protect client relationships very, very closely. So whilst you can have face-to-face conversations with clients, you can't just do that from a research perspective. The last couple of organizations I've been in have had that, either from a sales perspective or a professional services perspective. So you have to be really clear about what kind of research questions you want to take to clients, and what you're really trying to uncover.

[00:14:05] Part of the real skill is upskilling those people who are having those ongoing client conversations with what information you need on an everyday and ongoing basis, so they can be looking for some of the signals that you need to help you determine if, with product A, product B, product C, you're moving in the right direction or not. And depending on which part of the product development cycle you're in, at some point you're going to need to get closer to the customer, to really get some of that real customer-speak and some real feedback. But there's a lot that other people within the organization can do in terms of research skills.

[00:14:57] You do need design professionals to actually help you with that. But equally, within an organization, if an organization can be taught prototyping techniques, for example, there's a huge amount that a lot of people across the organization can do in terms of thinking through problems that they have within the organization, and also that their clients have. They can use some of those techniques to surface some problems and try to come up with some lean prototypes, take them to people, and again get some signals as to whether or not this might be a good idea. And do those things quite quickly and quite inexpensively. And then that helps you get more support for bringing in some expert UX people.

[00:15:53] In a lot of the organizations that I've worked in, I've gone in as the first person to build up a product lab or an innovation lab. So you're really scrambling for proof points, and bringing in a UX person is not often the first hiring decision that's made. So you have to be really clever about how you can uncouple the skill set. And then, when you know that you're going to be able to really prove the UX concepts, bring in some experts to really shine. Once you can do that, you can really sell the UX concept. Because unfortunately, I'd love to always be able to have fabulous UX people on all the teams, but it's not always the thing that people understand the easiest.

[00:17:00] Rory: Yeah, we'll probably come back to that, because that's a really interesting topic, trying to convince people of the value. It seems every talk comes back to convincing stakeholders, but it is what happens in the real world. Damien, to you, on that question: you were saying that in your government and corporate life there's a lot of profit motive, a lot of just getting it done. Are you seeing any value from teams proving that if they put UX people in, or have they been trying that in your context, to drive up innovation?

[00:17:44] Damien: Yeah, I think Penelope's uncoupling of the skill sets is really interesting. And I'd also agree that it does depend on the project or the industry that you're in, and maybe there isn't one solution. In one of my previous roles we adopted a Spotify model, so we had chapters and guilds, and we had a UX person in every team, and that was really beneficial. But also, I think anyone can learn basic UX fundamentals. We all probably have a real understanding of it, whether we realize it or not, just through interaction with our devices and our technology. We know if something is a good experience or not. Whether non-designers can fully articulate that or not, it's something they can learn.

[00:18:34] In one of our previous roles we had copywriters that wanted to learn a bit of UX. It's really tied together: copy, UX writing and design. So we had copywriters that wanted to do a bit of the design. And ourselves, the same as you, Paya, we had one UX copywriter to service everyone, so the designers were picking it up themselves a little bit as well. We just organically started trying that out. We had to have discussions about it, because obviously the designers are responsible for design and the copywriters are responsible for the copy. But we had discussions about it, and I think we determined that there could be a copy-led project or a UX-led project.

[00:19:17] If it's copy-led, the copywriters could play around with the design a bit, and we would just check in with them and guide them. It wasn't a dictatorship or anything; it was more just guidance, mentoring. And vice versa, we would learn a bit about copywriting that way as well. It happened organically, but we allowed room for people to learn, even though we knew they might not be doing it perfectly. We set up some rules to check in with each other if we were working in someone else's space, and we just started to really learn from that. There were some copywriters that wanted to learn UX and some that didn't, and the ones that did got more involved. I think having that flexible, open-minded approach really helped with getting that UX thinking right across the board.

[00:20:11] Rory: That comes back to the trendy world, whether it's T-shaped, or people are saying cone-shaped now: you have that broader skill set. It's not, "You're a copywriter and that's all you can do; you're only ever going to do copywriting." It's also, "Well, yes, you could actually do some UX research and different pieces." So I really like that.

[00:20:36] Damien: Can I just add: going back to what Penelope said, I think it's still important that you keep the standard of the work as well. That's really important. But definitely allowing other people to grow into that space is a good thing.

Upskilling people into new roles

[00:20:49] Rory: Everybody's touched on training at some point in their answers. You mentioned that cross-pollination there, Damien, so I'll start with you. How do you actually facilitate that? How did you ensure that it wasn't just somebody saying, "Oh, I'll take on this bit," but they don't actually know what they're doing and they don't perform it well? How do you facilitate the actual upskilling of people?

[00:21:19] Damien: I think it probably needs to come on several levels. From the business level, again, as Penelope was touching on earlier [?], it's about the business recognizing the need, or even just the desire, for time and budget being spent on projects that may not have immediate returns. Team leads can do the same thing: they can make time and allow their team to have a bit of time to explore those areas and then play it back. Individuals: you don't have to wait for the business to give you time to do that. You can do it in your own time and bring it back into some sort of discussion space.

[00:21:58] I think it's probably really important not to let that work get lost, though. Give it a bit of structure. Say, "Okay, if we're going to dedicate some space and time, and that's budget, to this innovation work, perhaps we have some structure, so every sprint people bring back what they've looked at." Then you could implement the kiss, kick, kill [?] mentality, the folk idea [?], which I think is great. That way the innovation gets into the process and doesn't just get lost in the time that people might be allocated to it.

[00:22:36] Rory: Excellent. And Paya, you touched on almost a more structured way, where for your training you've got directors in particular areas. Is there a structured way of trying to train people up in those areas? How do you go about making sure that people are picking up these skills?

[00:22:57] Paya: I think documentation. I'm lucky right now, because we do have a team dealing with this type of operational thing when it comes to training and onboarding. We have to have a place to store all the documentation: "Okay, this is the how-to. This is what our Klarna writing style is going to be," for example. Those documents, I think, are a great way to start. But when it comes to the real world, every product team is different, and every product is moving at a different speed as well, at least in my case. And then we have to deal with different human beings, who expect different things when it comes to training and UX.

[00:23:46] So I like to have a startup mindset when it comes to this type of training, where I'm just going to run, let's say, a single user test. I'm not going to tell the PM, for example; I'm just going to show them the result: "Okay, this is what I just did. What do you think?" And usually the PM is like, "Wow, you can do this really fast. I didn't know the result could be so interesting and beneficial for our team." So just trial and error, and trying to do something based on your team's budget and time as well. So again, I think documentation, and then starting small with training, and bringing people in, is what I believe in.

[00:24:33] Rory: Excellent. And Penelope, do you have any other insights on how you get that training for people who are doing new roles that they haven't done before?

[00:24:42] Penelope: Yeah. I think a combination of what Paya and Damien have said. One of the things for me is that I started working a long time ago, when big training budgets actually existed and you could really get trained. More recently, a lot of companies don't really have training budgets, so I've had to get really creative with training teams. For me, a lot of training is built on the model of training from the back of the room, which is that quite often people in the room actually know so much, and giving people the space to share with others is really powerful. So building in lightning talks, where members of the team can note what they can share and what they want to learn, is actually a really great way of sharing, and building that into team touchpoints. Quite often big groups have touchpoints on a monthly basis, so enabling it at that touchpoint level.

[00:25:48] Again, individual team time. A lot of teams think that they have to ask permission for learning. You can structure your days to manage your time, for most people, however they want to manage their time, so creating some learning time is really important. There's so much free learning available, so many free webinars. Pretty much everything you want to learn is available for free online, and you can really upskill yourself. I always have a book club going with whichever team I'm in, and people are variously interested in that or not, but I'm a lifelong reader, so that's always a great thing to do.

[00:26:41] And then setting up internal mentors; that's always a good thing. Really being clear about what it is that the person wants to learn, and then enabling them to increase their profile and learn internally, because so much of work is about how you navigate an organization or how you navigate an industry. And then bring in lunchtime speakers. So often there are people around who are interested in sharing something, and people have got books to spruik [?] or talks they want to test. Quite often, before a conference, people want to practice their talks. So that's always a good way of understanding what new, interesting and different ideas there are. There are lots and lots of ways; you've just got to think more broadly. Because I don't often work in organizations that have a lot of money for training these days, I've had to think creatively.

Culture that lets people take chances

[00:27:40] Rory: Excellent. You touched on a good point, and a few people have mentioned it, particularly, coming back to Damien, about profit: it's all about profit at the start. When people are trying to learn something new, there's a bit of anxiety: "Can I do this new way of working? Can I do this new thing?" So if companies are all about profit and delivery, it almost shuts people down from taking a stab at trying something new. Damien, in your experience, what can companies do to make it a better culture that enables people to take these chances?

[00:28:21] Damien: I guess it's about helping people be comfortable with disagreement. You're going to raise an idea, and people have a different perspective on it. So it's fostering that comfort in having those discussions. At Vodafone, as a design team, we had talks about giving and receiving feedback, and we discussed how you best do it. Because it's about recognizing that everyone has their own opinions and assumptions and bias. Receiving feedback in a design process is learning to filter what's been said that's really validated and comes from experience, and what's just an opinion. But I think you can relate that to probably any company-wide discussion, design or not.

[00:29:13] It's being able to have that comfortable space, knowing how to give and receive feedback, knowing how to discuss when you don't agree. And it also helps people really think about validating what they're saying, so you don't just come from an opinion: how have you validated that thought? So I think it's taking those receive-and-give-feedback skills from design, perhaps, company-wide to all teams, and just getting comfortable with having those discussions where people don't agree.

[00:29:49] Rory: Excellent. I'm just looking at the time. Unfortunately I lost track of time, and we're already slightly over, so apologies for that. But Paya or Penelope, do you have any final thoughts to add on that last one, about how you create the culture that enables teams to actually take these risks? Anything quick to share?

[00:30:10] Paya: I can share that in my teams I've been working with a lot of personalities. Some can be a bit more outspoken and more comfortable with talking about new ideas and convincing people; some are not. I think what a team or company can do is enable psychological safety for everyone, with no punishment. Every idea is an idea. We might not do it, but every idea is a good idea, in my opinion. At least in the design team where I'm a lead, I try to promote that: it's okay, feel safe to speak about what you believe in. So the key word I want to make here is psychological safety, I think.

[00:31:01] Rory: Brilliant, thank you. And Penelope, anything to add, or have they covered it off?

[00:31:05] Penelope: Yeah, that's fine. Thanks.

[00:31:08] Rory: All right. Well, thanks very much for your time, Paya, Penelope and Damien. I really enjoyed that chat. To sum up: it's about making sure the teams have the time and the budget to start looking at the underlying problems. You don't always need that budget; you can carve it out yourself and take that into your own hands. You can start looking at ways that you can upskill in areas that you need to, either online or through more structured internal ones. And I like the point to finish on: psychological safety within the organization, to let people take that chance. So thank you very much.