Turning Motivation Into Action

Rory Madden at UXDX Community: Germany. Video: https://youtu.be/sNB3bbL7IX4

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 isn't enough

[00:00:00] Welcome to my talk about turning motivation into action at UXDX. One of the big things that we focus on is that it's great to get the motivation of new ideas and new ways of working, and all of the talks over the last few days have been great at doing that. But the key challenge is then to actually implement those changes in your organizations, and that's where a lot of the challenge lies. I've talked to people who are incredibly motivated, but they really struggled with the implementation aspect. Because as soon as you go back to your organization, your company, you're going to get hit with those deadlines. You're going to get hit with the resistance to change that is natural in any organization. So this talk today is to try and give you some ideas and ways that you can implement whatever new ideas you have in your organizations.

[00:00:52] First off, I want to touch on the motivation side of things, because often that's what people think you need to focus on to make change happen: if you're motivated enough, you'll be able to do it. Well, if you listen to any smokers as they're trying to quit smoking, motivation often isn't enough, unfortunately. We survey people after every UXDX, and we'll be sending out a survey after this one. We ask how motivated you are to implement some new process or concept that you've heard of during the conference, and 88% of people said that they were motivated to implement some change. Another 8% said that they were motivated to keep going on the same change they were already doing. So motivation isn't lacking, but when we follow up later, we find that people are really struggling with actually making it happen.

[00:01:40] I think a great way of looking at this comes from a professor at Stanford named BJ Fogg, who looks a lot at how to influence behavior. He came up with the Fogg Behavior Model. He said that motivation is incredibly important, but he sees that as only one of the axes of the problem. The other is the ease of doing it, or the ability to do it. What he's saying here is that if you have incredibly high motivation but it's still really difficult to do, then the change isn't going to happen. The trigger line is that curve that we see coming down. The easier you make something, the less motivation you need to get it across the line. So for the rest of this talk, I'm not going to be talking about motivation. I'm going to focus in on ability: how can we make it easy to make this change happen?

Why process change gets stuck

[00:02:30] At a high level, we're talking about a process change. In theory, it shouldn't be too complex, because we're not throwing everything away. We're doing all, or a lot, of the same steps that are already happening. We're just shuffling around the timelines, and we're shuffling around a little bit the people who are responsible for those different steps, but we're not doing something completely brand new. So you would think that it wouldn't be too complex to change. But the challenge is that organizations are in a current state of stability. Organizations are constantly changing, but at any given time they're in a state of stability, and it's never going to be optimal. No company has an optimal structure.

[00:03:14] I liken it to this picture of the coffee cups, because that is definitely not the best way to pour yourself a cup of coffee. It's really unstable and it's really inefficient, but it works. You can pour yourself a cup of coffee with this stack of cups. So if somebody comes in and suggests moving things around, naturally there'll be a bit of reticence, because people know that it is a little bit fragile and it could all come crashing down.

[00:03:43] How does this manifest itself in an organization? I always get the "what about" questions. When I'm proposing a change, people will do the, "Well, what about this? If you want to change that, how are we going to deal with the knock-on effects here?" Or, "Okay, if you fix that there, what about this over here?" And you go in these never-ending loops of what about, what about, what about, until you basically get tired. There's a great book, Never Split the Difference, written by a hostage negotiator. He said that in his hostage negotiations, he can't split the difference. He can't say, "You take one hostage, I'll take the other, and we'll call it quits." He always has to win, and this is his main tactic: he always asks questions of the hostage taker. If they ask for a getaway car: "Well, how would that work, and where would it go?" He never offers a solution. He always just asks a question, and it gets very mentally taxing and tiring, and then eventually the hostage takers make a mistake. That's a very similar process to what's happening in a lot of organizations.

[00:04:57] I'm going to give you a quick example of that in practice too, to try and make it a bit more tangible. Let's say we wanted to move from a large project to very small, iterative pieces of work. The first thing we need to do is change how we're breaking down the work. So we get our BAs or product owners on board, and they're going to write some small stories. But then our architects might say, "Wait a minute. I need to review all of these things before I can give a design. And if you're going to give me really small pieces of work, it's going to be too much, because I'll be bouncing everywhere doing really small pieces of work." So the architects and the developers need to change how they work together to enable these smaller stories.

[00:05:34] Then, in governance, your PMO buddy might be thinking, "Well, I track things based on completion. If you're going to be doing small iterations, it's going to be a lot of overhead for tracking." So suddenly we have to change how we're tracking our completion and our story process. And that has a knock-on effect on how the teams themselves track their progress, because they're no longer just checking, "Are we 80% through the project, or 20%?" They need to be looking at, "Are we validating or invalidating assumptions?" And then as soon as they want to release those to validate in the real world, you enter a situation where you've got to change how the release process works, and that impacts your functional structure, because you want people to be jumping in and out a lot more quickly, and it impacts funding. That was just a quick example of how a seemingly small change can involve 20 or 30 different people in different departments and functions around the organization, and that's where you can get stuck.

A user story map for organizational change

[00:06:41] The way I think about this problem is actually very similar to building a product. When you've got an idea in your head for a product, you've got the best idea you can think of. It's going to be amazing. But the challenge is that the product with all the bells and whistles would take years to build. So you need to start small and you need to iterate, and that's where the MVP process has come to shine, by enabling quick feedback and progress. We need to do something similar with change management.

[00:07:10] One of the first things that I like to use is user story maps. I'm not sure if you've come across these before, but at a high level, it shows you the user journey across the top of whatever you're trying to build. These are the very high-level steps that a user is going to need to complete as they go through the journey. We have the blue Post-its here representing that high-level journey, and then the yellow Post-its are all of the different features that you need to build in order to enable those different pieces. Then with the team, you sort them higher or lower, and that's where you determine what's in release one, what's in release two, et cetera.

[00:08:02] The real power of this is twofold. One, it gives that high-level view to anybody, so they can look at it and see, "Okay, here's the high-level journey, and here's everything that we've already considered that needs to go into it," but it shows what we're focusing on. We acknowledge that all of these other pieces need to be done, but we're going to focus here. And the second thing is that the action of building this gets buy-in across the team, and that's incredibly important if you're trying to make sure that you're going to succeed.

[00:08:31] So what we need to do is develop a user story map, but for changing an organization. This is actually what I've been working on for a number of months. We were hoping to release this at the conference, but unfortunately 2020 had different plans, and we had to focus on pivoting to an online conference. But we'll be getting back to working on this. It's probably about 75% ready, and we'll be publishing it before Christmas. At a high level, the user journey map covers all of those different areas of the business that are going to be impacted by a change.

[00:09:09] Then for our releases, it's not a linear maturity model, but it's a step-by-step process as people want to move through from agile development, continuous integration, deployment, delivery, continuous value, product teams, et cetera. We're going to give you two things with this. It'll be a way of assessing where a team is currently at, and then the building blocks, so you can have all of the different Post-its ready, start agreeing where to put them, and agree amongst yourselves, for that team within that context, what is the most appropriate thing to work on. I'm going to give you a couple of examples where I put this into practice, so you can hopefully understand how it would work a bit better.

The Aer Lingus mobile apps team

[00:09:57] As I was saying, making it easy also means making it specific. One size will not fit all. You can't go into your organization and say, "These are the steps that we're going to do as an organization," because there'll be different teams at different levels in the same organization. To show what I mean by that, I'm going to give you an example of two different teams that I worked with at Aer Lingus: the mobile apps team, and the B2B team, which was an API backend platform team.

[00:10:28] Looking at the mobile apps first. The background there was that it was an agile team. They had had incredible success moving very quickly, with a very highly rated application, but some challenges had started to creep in and things were starting to slow down. So we were looking to see how they could improve further. The first thing that we needed to do was get buy-in. If we went and said, "This is what we want to achieve," people would push back. In fact, that's what I did first, and people did push back. So I changed tactic, to get the buy-in from the team themselves.

[00:11:04] What we did was put everybody in a room, put this up on the board, and say to the team: where do you want to be? What do you think is the optimal process for this team, given the product that we're delivering? After a lot of discussion and back and forth, they chose continuous delivery. The rationale was that with a mobile app, you don't want to be releasing constantly, because people have to download it from the app store. So if we were at a point of continuous delivery, that would be much more efficient.

[00:11:37] After we got that buy-in, we were able to put together a map of where we are and where we want to get to. Continuous delivery is where we wanted to get to, but we needed to go through some of the steps in continuous integration first. We started doing a lot of smaller, different pieces in parallel, but we really focused on two areas. The first area was funding. As the mobile apps team had grown and was becoming more prominent in the organization, it had gone from a small little experiment to needing to adhere to all of the rules in the organization, and a big one was around funding.

[00:12:17] For good reason, the finance department were saying, "If we're going to allocate this budget, we need to be looking at the ROI. We need to be validating that we're fulfilling our fiduciary responsibility for the organization and making sure that we're going to get value for money." But what this meant was that we would have to do a business case and agree up front exactly what we were going to deliver, and that took a lot of the autonomy away from the team. So what we did here was fake it till you make it. What I mean by this is we put together a business case, and we cherry-picked some of the more simplistic things that we knew needed to be done and that would give a high return. We put those into the business case and got it signed off. But then we left the team to actually uncover the problems and solve the problems that needed to be solved. If it happened to align, that was great. Otherwise we would have some explaining to do at the business case review.

[00:13:15] The second area was dev and QA integration. While we were trying to release more quickly, there was a big pushback on those quicker releases. This came from a number of different areas, but it really boiled down to a lack of ownership of quality across the team. Quality was seen as being owned by the QA department, and they were very worried that if we started moving quicker, they would get pressured and squeezed to release quicker and cut corners, and they would be the ones held responsible and blamed should anything go wrong. So they saw themselves as having to slow us down and police us, to make sure that we adhered to the process so that we couldn't jeopardize the quality of the application.

[00:14:02] It was coming from a very good position, but we needed to work through that, and the problem was that without people taking ownership of quality, there was no incentive to change. So we proposed an experiment. We said: for three months you will have zero blame, and even afterwards we will give zero blame for anything that goes wrong, but we want to test out a new way of working. What we did was just parallelize some of the tests. We didn't even change things around, and we didn't cut testing. We managed to get a 30% reduction in elapsed time over that three-month period. After we had that win, we were able to keep iterating and improving and get even better performance improvements.

The B2B API team

[00:14:50] That was a team that was moving on from agile development, getting more into the DevOps space. The second example was a B2B API team, and they already had a very mature, automated pipeline in place. They were able to make some changes, run their automated test suite and know whether it passed or failed. When we chatted with that team, they said their next step would be moving into more of a continuous delivery model, which meant that they needed to be able to do feature flags, to turn different new features on and off, and also be able to spin up and tear down environments as they needed.

[00:15:24] But one thing that we needed to focus on just before we could get there was the speed of the testing. While the tests were great, they were taking a long time to run. They ran for nine hours, which meant that you could make a change first thing in the morning and you wouldn't know whether it worked until the next day. So that became our first challenge. Because the team were already high-performing, it was very light touch. We just said, "Okay, it's currently nine hours. It needs to be 30 minutes. Go away, figure out what needs to be done, and come back to me when it is at 30 minutes."

[00:16:00] Within about two months, the test suite was down to two hours. And again, that was without cutting tests and cutting corners. It was just through exploring new ways of parallelization, as well as removing redundant duplication. After they had hit two hours, they didn't stop. They kept going, because the goal never changed; it was still to get to 30 minutes. But what it did enable was that we could get three or four changes released in a given day, without having to wait until the next day.

The trigger, and four takeaways

[00:16:35] We've spent a lot of the time talking about making it easy. There's a third element of BJ Fogg's Behavior Model. The motivation is there, we've made it easy, and then there's the trigger. Something needs to actually kick it off to make the change happen. I think there's never a good time. There's always a deadline. There's always something else that needs to be done: as soon as we finish this project, or as soon as this release goes out, then we'll focus on it. But there's always something after that. So you need to take ownership of carving out a bit of time to work on the process as well as the product, because it's only by improving the process that you'll be able to speed up and make the delivery of your product even better.

[00:17:20] Just to recap, the four things that I'd like you to take away from this talk. One, don't focus purely on motivation. You have to make it easy to change. That involves bringing people along and making sure you get the team's buy-in, because if you just come along and dictate a solution to people, A, they're going to push back, because they're not going to believe in it, and B, even if they do go along, they're not going to put in as much effort as if they had come up with it as their own idea. So make sure that you get the team's buy-in.

[00:17:55] Create a map. The biggest pushback that I always get, as I said, is the what about this, what about that, what about the other. If you create a map, you can show people that you've thought about those problems, but they're not in the current release. So yes, there is going to be an impact there, and we'll solve that later. This is how we can deal with it right now. It's not optimal, but we'll get to that later. And then finally, start now. There's no time like the present. My favorite quote: "The best time to do it was last year. The second-best time is now."

[00:18:28] I hope that this gives you some tools that you can use to turn the motivation that you'll hopefully be getting over the last few days of the conference into action that you can implement in your company. If you have any questions, please reach out on the Slack, and I'll be in there over the next few days answering any questions that you have. And also, as I said, we'll be releasing all those assessments and the template maps for change at the end of the year, so please subscribe to UXDX to find them. Thank you very much. I hope you enjoy the rest of the conference.