Turning Motivation Into Action

So welcome to my talk about Turning Motivation into Action at UXDX. So one of the big things that we focus on is, 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 challenges then to actually implement those change in your organizations. And that's where a lot of the challenge lies. I've talked to so many people they are incredibly motivated but they really struggle with the implementation aspect because as soon as you go back to your organization or your company, you're going to get hit with those deadlines. You're going to get hit with just the resistance to change that is natural in any organization. So this talk today is to try to give you some ideas and ways that you can try to implement whatever new ideas that you have in your organizations.
So, first of all, I want to just touch on the motivation side of things because often that's what people think you need to focus on to make change happen. So if you're motivated enough, you'll be able to do it. 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 and we ask how motivated are you 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 as they already were doing. So motivation isn't lacking but then when we follow up later, we find that people are really struggling with actually making it happen.
What I think is a great way of looking at this is, there is a professor named BJ Fogg at Stanford who looks a lot about how to influence behavior and he came up with the Fogg behavior model. So he said that motivation is incredibly important but he only sees that as one of the axes of the problem the other is the ease of doing it or the ability to do it. So what he is 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 and the trigger line is that kind of curve that we see coming down. So the easier you make something the less motivation you need to have 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 on that ability. How can we make it easy to make this change happen?
At a high level, we're talking about a process change. So it's not 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 kind of shuffling around the timelines and we're shuffling around a little bit of 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 it's in a state of stability and it's never going to be optimal. No company is an optimal structure. So I liken it to this kind of 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 starts coming in and suggests moving things around, naturally there will be a bit of reticence because people know that it is a little bit fragile and it could all come crashing down. So how does this manifest itself in an organization? I always get the “what about” questions. So when I'm proposing a change, people will ask, "What about this?”, “So if you want to change that, how are we going to deal with the knock-on effects here?”, “So 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 is a great book, "Never Split the Difference". It's written by a hostage negotiator and 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. So if they ask for a getaway car, "Well, how would that work and where would it go?" And he never offers a solution. He always just asks a question and it just gets very mentally taxing and tiring and then eventually the hostage-takers make a mistake. So that's a very similar process that's happening in a lot of organizations.
So I'm going to just give you a quick example of that in practice to try and make it a bit more tangible. So let's say we wanted to move from a large project to a very small iterative piece of work. So the first thing we need to do is change how we are breaking down the work. So we get our BAs or our product owners on board and they are going to write some small stories. Then our architects might go, "Well, wait a minute, I need to review you all of these things before I can give a design and if you are going to give me really small pieces of work, it's going to be too much because I'll be bouncing everywhere, doing a really small piece of work." So the architects and the developers need to change how they work together to enable these smaller stories and then governance, your PMO might be thinking, "Well, I track things based on completion.” Now, if you're going to be doing small iterations, it's going to be a lot of overhead for tracking it. So now we suddenly have to change how we're tracking, our completion and our story process.
And then 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% through” etc. They need to be looking at, "Are we validating the assumptions or invalidating assumptions?" Then as soon as they want to release those to validate in the real world you now enter a situation where you've got to change how the release process works and that impacts on your functional structure because you want people to be jumping in and out a lot more quickly and it impacts on funding. So that was just a quick example how a seemingly small change can involve 20 to 30 different people in different departments and functions around the organization.
That's where you can get stuck. So 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 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 that kind of MVP process has come to shine with enabling quick feedback and progress. We need to do something similar with change management. So, one of the first things that I like you to think of and use are user story maps. So I'm not sure if you've come across these before but at a high level, what it does is show you the user journey across the top of whatever you're trying to build.
So these are the very high-level steps that a user is going to need to complete as they are going through the journey and then underneath we have the blue post-its here representing that high-level journey and then all the yellow post-its are all of the different features that you need to build in order to enable those different pieces. And then with the team, you sort them higher or lower and that's where you determine what's in our release one, what's in our release two, etc. Now the real power of this is twofold.
One, it gives that kind of high-level view to anybody so they can look at it and see, "Okay, here is the high-level journey and here is everything that we've already considered that needs to go into it." But it's showing what we're focusing on. So we acknowledge that all of these other pieces need to be done but we're going to focus here.
The second thing is that action of building this gets binding across the team and that is incredibly important if you're trying to make sure that you're going to succeed. So what we need to do is develop a user story map but for changing an organization and 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 onto working on this. It's probably about 75% ready to publish and we'll be publishing it before Christmas.
At a high level, the user journey map is all of those different areas of the business that are going to be impacted by a change.
And then for our releases, we actually kind of have, it's not a linear maturity model but it is a step-by-step process as people want to move through from agile development, continuous integration, deployment delivery, continuous value, product teams, etc. Then 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 to 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? So I'm going to give you a couple of examples where we put this into practice so you can hopefully understand how it will work a bit better.
So, as I was saying there, making it easy also means making it specific. One size will not fit all. So 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. And what do I mean by that? I'm going to give you an example of two different teams that I worked with at Aer Lingus. So there was the mobile apps team and the B2B team, which was an API back-end platform team.
So looking at the mobile apps first, the background there is, it was an agile team. They had had incredible success moving very quickly, very highly rated application but some challenges had started to creep in and things were starting to slow down. So looking to see how they could improve further.
So the first thing that we needed to do was get buy-in. If we went and said, "This is what we wanted to achieve." People would push back and in fact, that's what I did first and people did push back. So change tact to get the buy-in from the team themselves. So what we did, we put everybody in a room and we put this up on the board and we said 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? They chose after a lot of discussions and back and forth, continuous delivery. And the rationale was with a mobile app you don't want it to be released continuously 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.
After we had gotten that buy-in, we then were able to put together a map of where we are and where we want to get to. So continuous delivery is where we wanted to get to but we needed to go through kind of some of the steps in continuous integration first and we started doing a lot of smaller different pieces in parallel but we really focused on two areas. So the first area was around funding. As the mobile apps team had grown and was becoming more prominent in the organization, it had gone from this small little experiment to the need to adhere to all of the rules in the organization and a big one was around funding. For good reason, the finance department was 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 doing our fidiciary responsibility for the organization and making sure that we're going to get the value for money.
What this meant was that we would have to do a business case and agree to upfront exactly what we were going to deliver and that then took a lot of the autonomy away from the team. So what we did here was, we did a fake it, till you make it. So what I mean by this was we put together a business case and we cherry-picked some of the more simplistic things we knew needed to be done that would give a high return and 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. And if it happened to align, that was great. Otherwise, we would have some explaining to do once the business case review came in.
The second area was around Dev & QA integration. So while we were trying to release more quickly, there was a big push back on those quicker releases and this came from a number of different areas but it really boiled down to a lack of ownership of quality across the team. So 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. They would be the ones who'd be responsible and blamed should anything go wrong. So they saw themselves as having to slow a stand and police us to make sure that we adhered to the process so that we couldn't jeopardize the quality of the application. So it was coming from a very good position but we needed to work through that and the problem was without people taking ownership of quality there was no incentive to change.
So what we did was we proposed an experiment and we said, "For three months you will have zero blame and even afterward 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 we just parallelised some of the tests. So we didn't even change things around and we didn't cut testing. We manage to get a 30% reduction in lap time over those three months and after we had that win, we were able to keep iterating and improving and get even better performance improvements.
So that was kind of talking about a team that was kind of moving from agile development but needing to get more into that DevOps space. The second example was a B2B API team but they already had a very mature, automated pipeline in place. So they were able to make some changes, run their automated test suite and know whether it passed or failed. So when we chatted with that team, they were saying, "Well, our 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 the environments as they needed. One thing that we needed to focus on just before we could get, there was the speed of the testing. So, while the tests were great, it was 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 or not until the next day. So that became our first challenge and what we did because the team was already high performing, it was a very light touch. We just said, "Okay, it's currently nine hours. It needs to be 30 minutes. So go away, figure out what needs to be done and come back to me when it is at 30 minutes." So within about two months, the test suite was down to two hours. Again, that was without cutting tests and cutting corners. It was just through exploring new ways of parallelisation as well as kind of removing redundant duplication. And after they had hit that two hours they didn't stop. They kept going because the goal never changed. It was still to get to that 30 minutes but what it did enable was that we could get three or four changes throughout a given day without having to wait till that next day.
So we've spent a lot of the time talking about making it easy. There is the third element of, BJ Fogg's behavioral model. So the motivation is there. We've made it easy. There's the trigger. Something needs to actually kick it off to make the change happen. The thing is, there is never a good time. There is always a deadline. There is always something else that needs to be done, there is always “As soon as we finish this project or 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 that you'll be able to speed up and make your delivery of your product even better.
So 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. So that involves bringing people along and making sure you get the team buy-in because if you just come along and dictate a solution to people, they're going to push back because they're not going to believe in it and 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. Create a map. The biggest pushback that I always get as I said was “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 not in the current release. So yes, there is going to be an impact there - 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 is no time like the present. It's my favorite quote, the best time to do it was last year. The second best time is now.
So I hope that this gives you some tools that you can use to turn the motivation that hopefully, you'll be getting over the last few days at 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 of the questions that you have and also as I said we'll be releasing all of those assessments and the template maps for change at the end of the year. So please subscribe to UXDX to find out when. Thank you very much. I hope you enjoy the rest of the conference.