Turning Motivation into Action

So what I want to talk about is actually by "Turning Motivation into Action". And so I'll take this off to make it a bit clearer. The reason why I want to talk about that today is, every time we run a UXDX event, we've been running them since 2016. When we kind of asked people afterwards, did you learn something? Were you really motivated to make a change? After something that you've learned from one of the talks or panels or sessions or speakers or attendees that you've met, and 88% of people have said that they're really motivated to make a change. 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, a couple of little tweaks here and there, but we're not talking about anything dramatic.
So if you look at there's a professor BJ Fogg, and he has the change curve. In Stanford, this what he teaches. He basically says, you have two axes for making a change happen. Motivation is on one axis, but the other axis is the ability to do the change. So you would think, hopefully, with all the motivation that 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. So you'd hope that we will be able to get things implemented. But whenever we talk to people, and then say, well, so a month later, six weeks later, how much progress have you made, it tends to be more around here.
So the motivation is dipped, it's no longer at 8%, after six or eight weeks, because you've been back into the office, you've got your deadline, you've got the things that need to be done, there's always kind of pressure to keep kind of delivering, so motivation starts to wane, and the ability just isn't there. So the motivation side was made easy, but the ability side hasn't been delivered. And why I think this is, I just use this as my kind of analogy for how I think how a lot of companies work, it's kind of 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 kind of way of doing it. It's not the best way. It's definitely not efficient, it's brittle, any kind of small changes, and things start breaking, and it's really hard to maintain. Which that's why I kind of like it as the kind of an example of how companies, a lot of companies, work. But can you imagine then you come in and you start saying I want to change things around.
When you are working in a brittle system, well people are going to be nervous, because they know that okay, if you start making some changes here, well, what are the ripple effects going to be? And some of the things that have kind of like, if I just take something simple, like, I want to change to doing kind of really quick cycles.
So instead of doing a kind of six week or even two week, or maybe you want to start delivering every day, well, how do we document the work? So in the past, we would have done a business case, we would have kind of written up lots of documentation, we would have put together a big benefits realization case and put our finger in the air and said we're going to make 10 million if we do this. But how are we going to document it if we don't do that business case or what like we're understaffed, we can't, kind of, do small busy work like I need to give somebody a few days to work on something, I can't be just 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.
So yeah, one team is really geared up, you've made kind of effort to get one team ready, but then when you tried to integrate with the rest of the platform that you're working on, you just get blocked by that. So these are the kinds of challenges that I've faced whenever I've been trying to kind of get any changes through, and it kind of results in what I call water-scrum-fall, or fake agile or those kinds of things where it's kind of, you're still doing waterfall and you go, well 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 stuff.
We will ignore the rest of it, because that's just a bit too awkward to change. And yeah, there's, 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. So instead of kind of, you might go to the talk and people be saying, yeah, 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, which it just you actually are getting the worst of the kind of the overhead of extra kind of meetings and admin without the benefit of being able to iterate quickly and kind of take that feedback that you're learning and change it around.
So now that we're kind of faced with this problem, we want to..., the motivation is there. People want to change people know, and they've heard the case studies about how things are better, and how they, it can just get better kind of improvements. What are the steps we can do? And I think 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?, and that I'm hoping everybody realizes that's what we're doing in building products. So we're trying to change people's behaviors.
In a complex environment, the markets out there is complex, we don't know if our products, people are interested in them, 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. So we're incredibly skilled in this space as a group of people in this room and watching online. So it's kind of, why don't we start adopting some of the techniques that we're used to using in product development, and try to use that in our own environments and try to see whether we can use that to make it that ability, make it easier to move, so that we can start getting change to happen.
So it's kind of three things there. If you kind of look at a traditional product development, you inspire people, you come up with your vision, this is what we want, this is going to be our vision of how the world is going to be infinitely better after we do what we're trying to do. And this is your kind of grand, big vision. Of course, you can't get from 0 to 100 immediately, so you need a roadmap. Now I know roadmaps are a little contentious, because I'm not talking about a Gantt chart, I'm not talking about fixed dates, just a kind of 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 start iterating. So 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. I'm glad you came to the talk. Any questions?
So the way I think about it is, that's our strategy, that's what we're going to choose to do. And there's that old saying that "Culture eats strategy for breakfast". And so while you might be thinking, Okay, this is a great approach, I've got my like, vision, I've really inspired and got everybody excited about what we're trying to achieve. But then you start getting blocked by just, oh, that's not how we do things around here, or just to kind of not right now, we've got so much on. And it's kind of a lot of cultures are actually set up to maintain the status quo, rather than to try change. Because a lot of companies, particularly established ones, they're successful. So anything that rocks the boat, is potentially a risk to the success.
But I always think that's always... I get frustrated by that answer when people say it's all about the culture. Because to me, it's kind of a little bit of a copy. You're like, well, what can I do with that? So 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? So there's always a bigger fish. But what it means is kind of 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. So that's kind of what we want to do then is we need to think if we want to make some change in our environments. What are the incentives that people are being incentivized to do today? And how can we try to use that or maybe not use it? Maybe it's just definitely it's going to be a roadblock? How can we try to work around that, so that we can try to get some of these changes made? So I'm going to jump into kind of digging in, and I'm going to use some examples of kind of work that I've done in the past to try to put a bit more context on it.
So it's setting the vision. And this was one of the first mistakes that I really made. I just went in gung-ho, and I was working with a company called Aer Lingus, which is the national airline of Ireland, and I just went in gung-ho thinking, okay, everybody wants to adopt all of these modern practices, there isn't going to be any kind of difference of opinions there, but I kept getting all these meetings and stuff. And we were all saying the same words, but we definitely were not meaning the same things, and it would just lead to a lot of confusion, and then circular meetings. I don't know if you've experienced those, pretty sure you've agreed something, you move on to something else, and then you end up right back to the start. So what we did was we got everybody into a room, and we put this slide up on the board, and there's 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?
So it was kind of, are we doing Agile Development where we're starting to kind of build a lot more quickly, more focused on the development side? So this slide is very much heavily on the development. We were quite immature in that phase, we were still trying to build in the product and designer aspects, but what this did was this removed so many meetings. It took a while we did this, I think it took us three sessions of like a couple of hours each, but that actually, even though that's a huge amount of time, after we had done it, we had so many debates internally, we had so many kind of agreements on what exactly everything meant that after this, most of those disagreements disappeared, because we could instantly say, well, is that moving us towards our vision. So what they agreed here, just probably not super important, but they didn't want to go the whole way.
They didn't think that that was the right thing for their team to do. So you might think that they'll say, oh, well, we want to be at that bottom one where we're it's kind of a single team across everything, we're doing continuous delivery, we're releasing every kind of the Amazon 10,000 times a day, and they were saying they didn't want that. What they wanted is the ability to release at any point, because this was a mobile app. And 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 it. So that was just the context. And it was great. Except for things started to unravel a little bit, it created a huge alignments, but it wasn't perfect. And what happened was, the QA team, felt really pressurized by this. Because what it was, if you looked at those last steps, it was all about automating tests, it was being able to like write a bit of code, write a test, have it pass all your tests, and then it's like the system just works through the pipeline is removing as much manual intervention as you can.
So you're thinking if you're the QA person in the room hearing that, you kind of go, well, number one, that's my job, and number two, it's kind of well, you're completely misunderstanding, the role that I that I play here, and it's, I don't know if you've ever felt that, and I know I have in the past people go, you're not really adding anything here like we could easily move past that like happens a lot with research happens a lot with design. And 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 kind of absolve themselves of all blame. So if any change was made, at any point, it would just kick-start another six-week testing cycle. So their incentive was self-preservation, because if you get kicked every time is a bug comes in, and then somebody says, oh, well, now we're going to really shrink it down.
You'd be thinking, okay, well, more bugs are going to make it through, so I have to push back on this. So how we approached this was, we made it clear that bugs are the team's responsibility. So there is no owner of quality in a product team. Everybody owns quality. And that was a great message to say and kind of felt proud of okay, I've told everybody, everybody owns quality, and it didn't work. Because that's all a great thing to say, but at the end of the day QA, we're saying we're still going to get kicked if there's a bug that makes it to production.
And it took months, because what happened is we kept kind of going quicker and quicker, couple of bugs made it through, we 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. And then after a few months, they were kind of going okay, wait a second you've never once blamed QA for a book, 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 have to do, and that took a lot of time, and sometimes that's what happens, you do have to just spend time with people to build that trust to establish that, okay, this actually might make sense. So we were able to move forward.
On to creating a roadmap. So what I like here about creating a roadmap, I don't like Gantt charts, because as soon as you lock them in, then that is it's fixed, and it's kind of set in stone, and I love the now next later kind of type. But I also really am a fan of and I know some people might disagree that this is a roadmap, but user story mapping. So I'm not sure if you've come across user story mapping before, but the concept is that you have at the top here you've got those orange stickies, which are the big things that people a customer is doing or a user of your system is doing. So these are the high level kind of they might be searching for a flight. 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, so that would be the high level things and then you can break it down because that's probably too high level to work with.
So be kind of you get to the site, you can explore different areas you can do different types of searching and filtering, you can book do you want your seat your bike? Or kind of, do you want to get your meal on board? So that's how you kind of break it down and you just draw the user journey across the top. And then what you're doing is you're breaking down, what's my MVP? What's my next iterations? And the reason why I really liked this tool, is because what I've always had is that challenge of, okay, so 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 straightaway. So this is helping 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 this seemingly irrelevant or not, maybe not irrelevant, but why arbitrary kind of starting points. But by doing this, like a lot of times teams just jump straight in and do those arbitrary starting points, not arbitrary, but it does look like that to an external person.
So the user story map takes a lot of time, and it's a lot of like, jigging around on whether which goes where, but then it's a great tool for not just alignment within your team, but alignment with stakeholders and people outside of your team. So what we did was we actually took a little format and got a little funky. But we took this look to kind of the flow of work. And back to those questions of kind of how do we document work? What about architecture? Like we kind of have our architects going in? And kind of designing things for every little tiny piece of work? How do we govern it? How do we make sure that people aren't spending money willy nilly? We just kind of did a user journey for the work, like as piece of work if it went from idea through, and again, I know this is quite technical, rather than the kind of 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.
And this was great tool for kind of getting buy-in, in the team, as well as buying across for what steps we were going to make to start making kind of our journey through. And it's not happy ever after. So after we agreed this in the team, we did an experiment, things were working really well. What we started doing, we shrunk our six-week testing cycle into three weeks with zero impact on quality. We were kind of performing really well, I thought, okay, this is going to be great, and then we were presenting it back to the rest of the organization. I wasn't ready for the kind of the assault that was coming my way, and what I had done, though, that I hadn't thought about was I was challenging people's authority. So in a...
I was looking at it from okay, just focus on the work, don't focus on the functions, focus on the work and the lifecycle of the work. But the people who were in the functions, who designed the system, that the old system, when I was presenting about how much time we had saved, how much kind of everyone was on board, person is sitting there going, I design that process that you're just attacking. So it's not you're attacking the process, you're attacking me, and I'm not going to take that. And the other thing is, in a lot of organizations, I'm not saying everywhere but team size can equal the social status in the organization.
What I mean by that is that you'll often hear somebody kind of going, okay, because your team, I've got 100 of my team, or I'm leading 200 people. And that's a kind of a sign of social status in the new organization. And if you then come along and say, okay, so what we've done is we've kind of shifted around, and we're not going to have all these functions doing things, we're going to have a cross-functional team, they're going to work together. So you remember those 200 people that you had that like good social status. So now you don't, you don't have those people and the process that you design, we're going to just change that. So how we came about this and kind of tried to tackle this was practicing empathy.
It was the first one. I went into that meeting a little bit blind, but I shouldn't have been. I should have thought about the audience and the message that I was going to be conveying to them. So I should have thought, you know what, these people are not going to like this, because I'm going to be kind of tackling their systems and their ways of working. And the other thing that we did was, because it was not just I guess removing the team and stuff, but they're going okay, well my role as functional manager, I allocate 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 of work, you've taken away tracking? Are you taking away my job? And what we did was we had to sell the new role, which like, personally, I don't like that administration side of things. I'd prefer to be doing the strategy. I'd prefer to be doing the craft and this is where the kind of in agile organizations you have to split in the functional manager. Do you want to go down that kind of management career path? So stop doing whatever, whether you're a designer or developer or researcher, you're going to stop your craft and you're going to go down the people management route? Or do you want to get super kind of good at your craft, and a lot of organizations, the only way was the management route, whereas now we're seeing and this kind of structure enables that split between, do you want to stay in your craft? Or do you want to go down the strategy route? And either of those options to most people is more entertaining than being an administrator, just kind of allocating people around. That wasn't quick.
So I'm saying that this was a long couple of months of trying to just using political capital to try to get people on board. So then the third section is about starting to iterate. So 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 just kind of learn. The user story map is supposed to be a living document, you're not supposed to kind of just set it and it's done. After each iteration, you should try figure out well, did that work? Did it not? What do I need to change? So when we started this, I got hit with the, where's your TPS report? Or also known as who's going to pay for that? So we hadn't done a business case, we hadn't put together our big design of everything that we were going to do and how much money it was going to make us and how much it was going to cost and get it signed off? And so we kind of hit a bit of a roadblock of, well, okay, we've got everybody involved, we've kind of got buy in, but now we have to get past finance. And, again, it was kind of thinking about, well, what is their incentives? So why?
Because we were kind of saying, well, trust us. It's not it's not the best answer, but it's kind of going like we've known the research, there's the book accelerate, there's lots of these kinds of research documents that are 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. So to the finance team, governance was kind of their way of keeping control. So it was kind of have you done your business case? Are you aligned to the strategy? So they had to prove the business case, if it was aligned to the strategy, and it would give enough ROI. And then their incentives were as well, like, so 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. And utilization being the other one, the finance, so 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 kind of challenging their way of doing governance. And this one, again, kind of just sat down with a few people and had a conversation about what is governance? So yes, there's a business case. Yes, there's the approval. Yes, there's the strategy meetings are the rice prioritization, 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? So can we answer those questions in a different way without relying on a business case? And what we came up with was, where were we spending our money? With a cross functional team, that's where you're spending the money. So that team are delivering some business value. I know, we've been talking about kind of changing our ways of working, but the team that we were working on, we're 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 asking the team, does this align to the strategy? Do we want to invest? At this case, it was a mobile apps team. Mobile had more traffic than web, we were a smaller team than the web team. So it seems like it wasn't that excessive to be asking what we were looking for. And then the second one was, is it working? So they said, okay, we can agree that what you're asking for the amount of money 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 say, well, you told me you were going to do this and deliver these features and have it by this date. And we said there is what we need to shift it around. Value is obviously the what you want to be proving. But that's often very difficult for a product team to be able to demonstrate value, because it's very hard. Often, 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, are they impacting the value proposition?
So we agreed was, well, let's convert value into products metrics. And we'll say, okay, these are the metrics that we care about; our number of users, number of flights, look to book ratio, these kind of metrics, and 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. So 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, a cut the funding, do whatever needs to be done. But there is ways of holding people accountable without needing that business case approach.
So what were the key learnings from that? I think the number one thing if you could take away; change is the exact same thing, whether you're talking about internally, the way you work, or whether you're talking about the customers of your products and users, you're trying to influence behavior in a complex environments. And so we can use the same tools that we use for building our products and testing and experimenting and iterating that we can use internally. Aligning on the vision saves so much meetings. I don't know if you can tell but I just get a relief from just all those circular meetings, I didn't have to go to any more and all of the kind of just like arguments and miscommunication that saves so much time.
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 to kind of well, that doesn't make sense, why don't you do this, why don't you do that? And you kind of, you'd be able to point to it going, well, we think that belongs here, we think that belongs there. And then practice the UX strategies of empathy on your own team. So I think this has come up a few times where people will say, as UX research is 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? And not practicing the empathy of trying to figure out where they're coming from? What are their incentives?
Because there's the, quote, "Never attribute to malice that which can be attributed to". And I just changed the last word to instead of ignorance to incentives, because often it's kind of the you'll never convince somebody of something if their job depends on believing the opposite. So look at what the incentives are, try come at it from their perspective and see how you can manage around those incentives. So that was my impromptu talk on "Turning Motivation into Action". Thanks to the Carbon Cure team last night after the walking tour in the pub. I hope you enjoyed it. And we have time for a few questions. Yep. There's a question here.

Audience 1
So I have a question. So 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. 38% millennials, right? They've only seen agile, they've never seen waterfall. So moving forward, what are your thoughts on how do we adapt? Kind of better? And obviously, upcoming generations, right? They've only seen startups are only using agile practices. So kind of in that aspect, what are your thoughts on, how do we kind of create, you know, this, the concept of what you said, you know, breaking down the vision roadmap, kind of, in your opinion, like, what are kind of the next steps? Like where should we be focusing? What's the next iteration, if you will?

Rory
So to paraphrase and tell me if I'm wrong on this, it's is kind of, so waterfall was kind of the 2000s, early 2000s. Everything's agile now. Where are we going next? Product teams, to me, is the next thing. So a lot of people when they say they're agile, I always ask one or two follow-up questions, particularly around like, okay, so, like, are you able to change the design after you've like, done a sprint? And most of the time, you're like, no, no, the design is done. And then we do our iterations. And you're like, okay, so you're not agile. But yeah, so you're right there.
There are some people who think that waterfall is a straw man argument, because nobody would work that way. But to me agile, it's kind of that diagram that I showed him, I have another one that goes a lot broader, that encompasses a lot more of the products, the UX, the design elements of it, and that's what we've seen. The shift has been that. And John Schrag, actually is in the audience somewhere. He gave a great talk about how design shifted on the barrier in the business on the kind of the friction is how he phrased it. So with developers, developers went over to Agile, and then there was friction with designers and product managers and everybody because they weren't going to do estimates and stuff. They were just going to iterate. But then John, who leads the design UX team, he 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 kind of other aspects of the business. And just over time, more people come over that kind of barrier of friction.
And that's what we're seeing. We're seeing a lot of movement now with marketing because marketing are kind of a little bit of that barrier with a lot of teams where there's a bit of friction with the way marketing work 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 in that those kinds of insights into your product. So to me, it's going to be that there's a more of a shift to cross-functional, kind of larger responsibility within cross-functional teams.