Turning Motivation into Action

Rory Madden at UXDX USA. Video: https://www.youtube.com/watch?v=KIijXYbRcDU

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.

Motivation is high, but ability is missing

[00:00:01] What I want to talk about is turning motivation into action. I'll take this off to make it a bit clearer. The reason why I want to talk about that today is that every time we run a UXDX event, and we've been running them since 2016, we ask people afterwards: did you learn something? Were you really motivated to make a change after something that you learned from one of the talks or panels or sessions or speakers or attendees that you met? And 88% of people have said that they're really motivated to make a change.

[00:00:38] So with that level of motivation, and really what we're talking about is a bit of a process change. We're not talking about reinventing the wheel. We're taking something like waterfall, which has very clear stage gates and handovers, and we're just shrinking it down. We're still doing pretty much all the same steps, with a couple of little tweaks here and there, but we're not talking about anything dramatic.

[00:00:57] There's a professor, BJ Fogg, and he has the change curve. At Stanford, this is what he teaches. He says you have two axes for making a change happen. Motivation is on one axis, but the other axis is the ability to make the change. You would hope, with all the motivation, with 88% of people saying, "I'm really motivated, I want to implement," whether it's the latest design system changes that we've just heard about or any of the other topics that we've talked about, that we'd be able to get things implemented.

[00:01:31] But whenever we talk to people a month later, six weeks later, and ask how much progress they've made, it tends to be more around here. The motivation has dipped. It's no longer 88% after six or eight weeks, because you've been back in the office, you've got your deadline, you've got the things that need to be done. There's always pressure to keep delivering. So motivation starts to wane, and the ability just isn't there. The motivation side was made easy, but the ability side hasn't been delivered.

A stack of coffee cups: how a lot of companies work

[00:02:03] Why I think this is: I just use this as my analogy for how a lot of companies work. You want to pour a cup of coffee. This stack works; the person is able to pour a cup of coffee. So technically this is a functioning way of doing it. It's not the best way. It's definitely not efficient. It's brittle: any small changes and things start breaking. And it's really hard to maintain. That's why I like it as an example of how a lot of companies work.

[00:02:36] But can you imagine you then come in and start saying, "I want to change things around," when you are working in a brittle system? People are going to be nervous, because they know that if you start making some changes here, what are the ripple effects going to be? If I just take something simple: I want to change to doing really quick cycles. Instead of doing six weeks, or even two weeks, maybe you want to start delivering every day. Well, how do we document the work? In the past, we would have done a business case. We would have written up lots of documentation. We would have put together a big benefits realization case, put our finger in the air and said, "We're going to make 10 million if we do this." How are we going to document it if we don't do that business case?

[00:03:25] Or: we're understaffed, we can't do small busy work. "I need to give somebody a few days to work on something. I can't just be asking somebody to go and do a little bit here, a little bit there, a little bit there." And other things, like teams can only move as fast as the pipeline. One team is really geared up, you've made an effort to get one team ready, but then when you try to integrate with the rest of the platform that you're working on, you just get blocked by that. These are the challenges that I've faced whenever I've been trying to get any changes through.

[00:03:57] And it results in what I call water-scrum-fall, or fake agile, those kinds of things, where you're still doing waterfall and you go, "What we can do is, instead of trying to change the stack of cups, we'll just change one little bit, and we'll say that we're agile now because we changed that little step. We'll ignore the rest of it, because that's just a bit too awkward to change, and we don't know what the effects are going to be. So we're just going to change that." And the problem here is that you don't get any of the benefits.

[00:04:26] You might go to the talk and people will be saying, "We're releasing 10,000 times a day, we're running X amount of experiments, we're really learning." And then you go back and you try to implement your version, and you end up with water-scrum-fall, where you're actually getting the worst of it: the overhead of extra meetings and admin, without the benefit of being able to iterate quickly and take that feedback that you're learning and change things around.

Using product techniques to change how we work

[00:04:57] So now we're faced with this problem. The motivation is there. People want to change. They've heard the case studies about how things are better and how they can get improvements. What are the steps we can take? As a group, I'm just going to ask a question: have we ever faced a situation where we're trying to implement behavioral changes in complex environments? I'm hoping everybody realizes that's what we're doing in building products.

[00:05:32] We're trying to change people's behaviors in a complex environment. The market out there is complex. We don't know if people are interested in our products, if they care about them. So we have to follow a process when we're building our products to implement behavioral changes in our customers and users, and it's a complex environment where we don't know what's influencing it. We're incredibly skilled in this space as a group of people, in this room and watching online. So why don't we start adopting some of the techniques that we're used to using in product development, try to use them in our own environments, and see whether we can use them to improve that ability, make it easier to move, so that we can start getting change to happen?

[00:06:18] There are three things there. If you look at traditional product development, you inspire people: you come up with your vision. "This is what we want. This is our vision of how the world is going to be infinitely better after we do what we're trying to do." This is your grand, big vision. Of course, you can't get from zero to 100 immediately, so you need a roadmap. Now, I know roadmaps are a little contentious, but I'm not talking about a Gantt chart. I'm not talking about fixed dates. Just a way to say, "Okay, look, we've had a bit of thought about this. This is how we're going to make some steps." And then you start iterating.

[00:06:55] Considering we all know how to do products, I'm assuming you all know how to do those steps, so everything will work perfectly, happy ever after, and I'm glad you came to the talk. Any questions?

Culture eats strategy, and KPIs eat culture

[00:07:08] The way I think about it, that's our strategy. That's what we're going to choose to do. And there's that old saying, "Culture eats strategy for breakfast." So while you might be thinking, "Okay, this is a great approach, I've got my vision, I'm really inspired and I've got everybody excited about what we're trying to achieve," then you start getting blocked by "That's not how we do things around here," or just "Not right now, we've got so much on." A lot of cultures are actually set up to maintain the status quo rather than to try to change, because a lot of companies, particularly established ones, are successful. So anything that rocks the boat is potentially a risk to that success.

[00:07:54] But I always get frustrated by that answer, when people say it's all about the culture, because to me it's a little bit of a cop-out. You're like, "Well, what can I do with that?" Yes, it's about the culture, and that's true, but what's my next step? How do I manage this? And KPIs eat culture. There's always a bigger fish. What it means is: look at the incentives. What are people being incentivized to do? Because that's going to influence how they're behaving, and that's going to influence what you can achieve.

[00:08:33] So what we need to think about, if we want to make some change in our environments, is: what are people being incentivized to do today, and how can we try to use that? Or maybe not use it. Maybe it's definitely going to be a roadblock, so how can we try to work around that, so that we can get some of these changes made? I'm going to jump into digging in, and I'm going to use some examples of work that I've done in the past to try to put a bit more context on it.

Setting the vision at Aer Lingus

[00:09:05] First, setting the vision. This was one of the first mistakes that I really made. I just went in gung-ho. I was working with a company called Aer Lingus, which is the national airline of Ireland, and I went in thinking, "Okay, everybody wants to adopt all of these modern practices. There isn't going to be any difference of opinion there." But I kept getting all these meetings, and we were all saying the same words, but we definitely were not meaning the same things. It just led to a lot of confusion and circular meetings. I don't know if you've experienced those, where you're pretty sure you've agreed something, you move on to something else, and then you end up right back at the start.

[00:09:43] So what we did was we got everybody into a room and we put this slide up on the board. There are a couple of different versions of this and different types of things, but we said: what do we want to do as a team, and where do we think we are today? Are we doing agile development, where we're starting to build a lot more quickly? This slide is very much heavily on the development side. We were quite immature in that phase; we were still trying to build in the product and design aspects.

[00:10:18] But what this did was remove so many meetings. It took a while. I think it took us three sessions of a couple of hours each. Even though that's a huge amount of time, before we had done it we'd had so many debates internally, so many arguments about what exactly everything meant. After this, most of those disagreements disappeared, because we could instantly say, "Well, is that moving us towards our vision?"

[00:10:46] What they agreed here is probably not super important, but they didn't want to go the whole way. They didn't think that was the right thing for their team to do. You might think that they'd say, "We want to be at that bottom one, where it's a single team across everything, we're doing continuous delivery, we're releasing the Amazon 10,000 times a day." And they were saying they didn't want that. What they wanted was the ability to release at any point. Because this was a mobile app, they said if you were trying to get people to download 10,000 mobile app versions every day, they wouldn't be very happy with you. So that was just the context.

QA's incentive was self-preservation

[00:11:18] It was great, except things started to unravel a little bit. It created huge alignment, but it wasn't perfect. What happened was the QA team felt really pressurized by this, because if you looked at those last steps, it was all about automating tests. It was being able to write a bit of code, write a test, have it pass all your tests, and then the system just works through the pipeline. It's removing as much manual intervention as you can. So if you're the QA person in the room hearing that, you're going, "Well, number one, that's my job. And number two, you're completely misunderstanding the role that I play here."

[00:12:03] I don't know if you've ever felt that. I know I have in the past, where people go, "You're not really adding anything here. We could easily move past that." It happens a lot with research, it happens a lot with design. So they were feeling really underappreciated. And their incentives were that they were the ones who kept getting kicked whenever a bug made it through to production. So their whole process was about protecting themselves, to make sure that they could absolve themselves of all blame. If any change was made at any point, it would just kick-start another six-week testing cycle.

[00:12:40] Their incentive was self-preservation. If you get kicked every time a bug comes in, and then somebody says, "Now we're going to really shrink it down," you'd be thinking, "Okay, more bugs are going to make it through, so I have to push back on this." How we approached this was that we made it clear that bugs are the team's responsibility. There is no owner of quality in a product team; everybody owns quality. That was a great message, and I felt proud: "Okay, I've told everybody that everybody owns quality." And it didn't work.

[00:13:14] Because that's a great thing to say, but at the end of the day, QA were saying, "We're still going to get kicked if there's a bug that makes it to production." And it took months. What happened is we kept going quicker and quicker. A couple of bugs made it through. We'd do a retro and figure out what went wrong in our process to let that through, and try to fix it earlier in the process. After a few months, they were going, "Okay, wait a sec, you've never once blamed QA for a bug." Because it's not QA's fault if there's a bug in the code. They didn't write the code, so why blame them? But that was what we had to do, and it took a lot of time. Sometimes that's what happens: you do have to just spend time with people to build that trust, to establish that this actually might make sense. So we were able to move forward.

A user story map as a roadmap

[00:14:04] On to creating a roadmap. I don't like Gantt charts, because as soon as you lock them in, it's fixed, it's set in stone. I love the Now, Next, Later type. But I'm also really a fan of, and I know some people might disagree that this is a roadmap, user story mapping. I'm not sure if you've come across user story mapping before, but the concept is that at the top here you've got those orange stickies, which are the big things that a customer or a user of your system is doing. These are high level. If you're talking about an airline, you'd be searching for your flight, you go through your booking flow, you pay for your ticket, you board your flight. Those would be the high-level things.

[00:14:51] Then you can break it down, because that's probably too high-level to work with. You get to the site, you can explore different areas, you can do different types of searching and filtering, and you can book: do you want your seat, your bag, do you want to get your meal on board? That's how you break it down. You just draw the user journey across the top, and then you're breaking down: what's my MVP, what are my next, next, next iterations?

[00:15:17] The reason why I really like this tool is because I've always had that challenge of: okay, you've just sold somebody on the big vision, this is what we want to achieve, but we know that we can't do that straight away. What this helps people do is go, "Yes, I can see that you're still focusing on the big vision, because you've shown me how you're going to get there, but I can see now why we're starting with these seemingly," maybe not irrelevant, but "arbitrary starting points." A lot of the time teams just jump straight in and do those starting points. They're not arbitrary, but they do look like that to an external person.

[00:15:53] The user story map takes a lot of time, and there's a lot of jigging around on which goes where, but it's a great tool for not just alignment within your team, but alignment with stakeholders and people outside of your team. What we did was, the formatting got a little funky, but we looked at the flow of work, and back to those questions of how we document work. What about architecture? We have our architects going in and designing things for every tiny piece of work. How do we govern it? How do we make sure that people aren't spending money willy-nilly? We just did a user journey for the work, as a piece of work went from idea through. And again, I know this is quite a technical journey rather than the UX journey. But we looked at that and we said, "Okay, what can we do here?" And we came up with our user story map. This was a great tool for getting buy-in in the team, as well as buy-in across the organization for what steps we were going to make on our journey.

Challenging authority and status

[00:17:03] And it's not a happy ever after. After we'd agreed this in the team, we did an experiment, and things were working really well. We'd shrunk our six-week testing cycle into three weeks, with zero impact on quality. We were performing really well, and I thought, "Okay, this is going to be great." Then when we were presenting it back to the rest of the organization, I wasn't ready for the assault that was coming my way. What I'd done, that I hadn't thought about, was I was challenging people's authority.

[00:17:37] I was looking at it from the angle of: just focus on the work, don't focus on the functions, focus on the work and the life cycle of the work. But the people who were in the functions, who had designed the old system: when I was presenting about how much time we'd saved and how everyone was on board, a person is sitting there going, "I designed that process that you're attacking. So you're not attacking the process, you're attacking me, and I'm not going to take that."

[00:18:06] The other thing is, in a lot of organizations, and I'm not saying everywhere, team size can equal social status in the organization. What I mean by that is you'll often hear somebody going, "How big is your team?" "Oh, I've got 100 in my team," or "I'm leading 200 people," and that's a sign of social status in the organization. And if you then come along and say, "Okay, what we've done is we've shifted things around. We're not going to have all these functions doing things; we're going to have a cross-functional team, and they're going to work together. So you remember those 200 people that you had, and that good social status? Now you don't have those people. And the process that you designed, we're going to change that."

[00:18:45] How we tried to tackle this was by practicing empathy. That was the first one. I went into that meeting a little bit blind, but I shouldn't have. I should have thought about the audience and the message that I was going to be conveying to them. I should have thought, "You know what, these people are not going to like this, because I'm going to be tackling their systems and their ways of working."

[00:19:12] And it was not just removing the team and so on. They were going, "Okay, my role as a functional manager: I allocate out my team, I tell them how to work, I track. So what do I do now? You've taken away allocation, you've taken away the way of working, you've taken away tracking. Are you taking away my job?" What we did was we had to sell the new role. Personally, I don't like the administration side of things. I'd prefer to be doing the strategy, I'd prefer to be doing the craft. This is where, in agile organizations, the functional manager path splits. Do you want to go down the management career path, so whether you're a designer or developer or researcher, you're going to stop your craft and go down the people management route? Or do you want to get super good at your craft?

[00:20:01] In a lot of organizations, the only way was the management route, whereas now this kind of structure enables that split: do you want to stay in your craft, or do you want to go down the strategy route? Either of those options, to most people, is more entertaining than being an administrator just allocating people around. That wasn't quick. This was a long couple of months of using political capital to try to get people on board.

Iterating, and who's going to pay for that

[00:20:33] Then the third section is about starting to iterate. You've got your big vision, you've broken it down into your user story map, you know what you need to do. Let's get started, let's iterate and learn. The user story map is supposed to be a living document. You're not supposed to just set it and it's done. After each iteration, you should try to figure out: did that work, did it not, what do I need to change?

[00:20:57] When we started this, we got hit with the "Where's your TPS report?", also known as "Who's going to pay for that?" We hadn't done a business case. We hadn't put together our big design of everything that we were going to do, how much money it was going to make us and how much it was going to cost, and got it signed off. So we hit a bit of a roadblock. We'd got everybody involved, we'd got buy-in, but now we had to get it past finance.

[00:21:27] Again, it was thinking about what their incentives were. We were saying, "Trust us." It's not the best answer, but we know the research. There's the book Accelerate. There are lots of research documents out there that say this is a better, more effective, more efficient way of working. But it's very hard to put that into a tangible business case. And governance was being challenged. To the finance team, governance was their way of keeping control: have you done your business case, are you aligned to the strategy? They'd approve the business case if it was aligned to the strategy and it would give enough ROI.

[00:22:11] And then their incentives were also: "No, I don't care about your iterations. You can go do that. I just need to know when you're done and how much it's going to cost, so that I can work that into my calculation of ROI." Utilization was the other one. Finance were like, "I don't really get how everybody's utilized if they're staying in one team. Wouldn't it be more efficient to move people around to different teams?" So we were challenging their way of doing governance.

Governance: where are we spending our money, and is it working?

[00:22:38] With this one, again, we just sat down with a few people and had a conversation about what governance is. Yes, there's a business case, yes, there's the approval, yes, there are the strategy meetings or the RICE [?] prioritization or whatever. But what are we really trying to achieve, if we just break it down to two simple questions for governance? Where are we spending our money, and is it working? Can we answer those questions in a different way, without relying on a business case?

[00:23:08] What we came up with was: where are we spending our money? With a cross-functional team, that's where you're spending the money. That team is delivering some business value. I know we've been talking about changing our ways of working, but the team that we were working on was building business features. So we were saying, "You're investing this amount of money," how much the team costs, "and is that a good idea or not? Well, that's up to your strategy." So we asked: does this align to the strategy? Do we want to invest? In this case, it was a mobile apps team, and mobile had more traffic than web, and we were a smaller team than the web team, so it didn't seem excessive to be asking for what we were looking for.

[00:23:51] And then the second one was: is it working? They said, "Okay, we can agree that the amount of money you're asking for is reasonable, but we have no way of knowing that you're not going to spend a year, burn through all this money, and then we have no business case that we can come back to and say, 'You told me you were going to do this and deliver these features and have it by this date.'" What we said there was that we need to shift it around.

[00:24:14] Value is obviously what you want to be proving, but it's often very difficult for a product team to demonstrate value, because if you're talking about a team in a large organization, you're having one little impact on that organization, and value is a lagging indicator. So it's really hard to find out: are the changes that I'm making right now impacting the value proposition? What we agreed was, "Let's convert value into product metrics." We said, "Okay, these are the metrics that we care about: number of users, number of flights, look-to-book ratio, these kinds of metrics. We're going to improve these metrics, and if we are improving them, then that's positive, because we're making a positive business impact."

[00:25:00] That's how we got agreement. We said: does the spending align to strategy, and can we agree on product metrics that we can track? And if we don't hit them, then yes, call us up on it, cut the funding, do whatever needs to be done. There are ways of holding people accountable without needing that business case approach.

Key learnings

[00:25:18] So what were the key learnings from that? I think the number one thing, if you could take one away: change is the exact same thing whether you're talking about the way you work internally or about the customers and users of your products. You're trying to influence behavior in a complex environment. So we can use the same tools internally that we use for building our products, testing, experimenting and iterating.

[00:25:45] Aligning on the vision saves so many meetings. I don't know if you can tell, but I just get a relief from all those circular meetings I didn't have to go to anymore, and all the arguments and miscommunication. That saves so much time. And the roadmap was able to share the big picture of what we're trying to achieve, but also, in a digestible format, say, "This is why we're doing this little bit first," and not have the "Well, that doesn't make sense, why don't you do this, why don't you do that?" You'll be able to point to it and go, "Well, we think that belongs here, we think that belongs there."

[00:26:19] And then practice the UX strategies of empathy on your own team. I think this has come up a few times, where people say that as UX researchers it's all about empathizing with your customer, and then you get to your own teams and you're like, "Why are these idiots not doing what they should do?" You're not practicing the empathy of trying to figure out where they're coming from and what their incentives are. There's the quote, "Never attribute to malice that which can be attributed to ignorance," and I just changed the last word from ignorance to incentives. Because often it's that you'll never convince somebody of something if their job depends on believing the opposite. So look at what the incentives are, try coming from their perspective, and see how you can manage around those incentives.

[00:27:06] So that was my impromptu talk on turning motivation into action, thanks to the CarbonCure team last night after the walking tour, in the pub. I hope you enjoyed it, and we have time for a few questions.

Q&A

[00:27:25] Rory: We'll use the throw mic. Oh, there's a question here.

[00:27:33] Audience: I have a question. I'm an agile coach. I try not to use the word agile anymore, because the community, in my opinion, is dying. But tying this talk with the previous talk: the millennials [?], they've only seen agile, they've never seen waterfall. So moving forward, what are your thoughts on how we adapt better? Obviously the upcoming generations have only seen startups that are only using agile practices. In that respect, what are your thoughts on how we create the concept of what you said, breaking down the vision and roadmap? In your opinion, what are the next steps? Where should we be focusing? What's that next iteration, if you will?

[00:28:18] Rory: To paraphrase, and tell me if I'm wrong on this: waterfall was the 2000s, early 2000s; everything's agile now; where are we going next? Product teams, to me, are the next thing. A lot of people, when they say they're agile, I always ask one or two follow-up questions, particularly around: are you able to change the design after you've done a sprint? And most of the time it's, "No, no, the design is done, and then we do our iterations." And you're like, "Okay, so you're not agile."

[00:28:55] But yes, you're right, there are some people who think that waterfall is a straw man argument, because nobody would work that way. But to me, agile is that diagram that I showed, and I have another one that goes a lot broader and encompasses a lot more of the product, the UX and the design elements of it. And that's what we've seen. John Schrag is actually in the audience somewhere. He gave a great talk about how design shifted across the barrier in the business, the friction, is how he phrased it. Developers went over to agile, and then there was friction with designers and product managers and everybody, because the developers weren't going to do estimates and things; they were just going to iterate.

[00:29:37] But then John, who leads the design and UX team, brought design and UX across the barrier, so they were doing that iterative way of working. But now they had friction with content, they had friction with marketing, they had friction with other aspects of the business. And over time, more people come over that barrier of friction. That's what we're seeing. We're seeing a lot of movement now with marketing, because marketing is a little bit of that barrier for a lot of teams, where there's a bit of friction between the way marketing works and the way the product teams work. Particularly because when you launch your product, you really do need to be iterative with your marketing as well, and bring those insights into your product. So to me, there's going to be more of a shift to larger responsibility within cross-functional teams.