Turning Motivation into Action

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

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.

Motivated, but not making progress

[00:00:00] You're going to learn a lot of things, or hopefully you're going to learn a lot of things, at this conference over the next few days. I was watching some of the pre-recorded talks that I hope you've seen, and there are just so many insights, from product prioritization strategy down to design systems, down to different ways of getting research approved. So there are lots of ideas. And then in one of the forums we were talking about a woman who works in a company with a thousand people, and any time she tries to suggest making a change, it just gets pushed back.

[00:00:32] What I want to talk about is turning motivation into action: what can you do about what you've learned to try to actually get it applied where you are? When we survey people after UXDX, 88% of people say they've learned something and they're super motivated, and they're really going to go back and try to get it implemented in their company. The challenge is that when we ask them a month later, "How's it going? Where did you get to?", it's deadlines, and, "Oh, we have to get something done," and, "It's not the right time," or something comes up. So the progress isn't being made.

[00:01:11] And when you think about it, we're not saying do something completely different. We're not saying it's radically different. If we have waterfall across the top there, we're doing the same thing in product teams. We're just changing little tweaks around. We're shrinking down the timelines, we're making it a lot simpler. So the changes shouldn't actually be that complex, and yet they are. That's the challenge that we face: why is it so difficult to make even small changes in your process, and what can we do about that?

Motivation is only one axis

[00:01:47] I like this model from a professor in Stanford called BJ Fogg. He created a model, and he's taught a lot of people; I think people kept dropping out of his class to set up companies that did really successfully. He was talking about habits, how you build habits, and how you make change happen. Loads of people think it's about motivation, but motivation is only one of the axes. You can be super motivated, but if it's really hard to do, you're not going to do it. And equally, if something is really easy to do, you don't need that much motivation to do it.

[00:02:25] So there's a sliding curve where, if you're really motivated, you don't need it to be massively easy, but you need it to be a little bit easy. When it comes back to the stats, are people motivated? Well, yes, 88% of people said that they were motivated, so I think we're good on that axis. But then the ability, the ease of doing it, that's where we obviously have the problems. If your triggers are there you succeed, and otherwise you don't.

Companies are a brittle cup of coffee

[00:02:57] Why is it so hard to do? This is what I was chatting about with, I must get the lady's name, I didn't catch it, but she works at the City of Reykjavik [?]. She was explaining that when she proposes a change, somebody else will go, "Oh, but that breaks us," and, "If you do that, then that's going to cause problems over here," and, "What about this?" or, "Have you thought about something else?"

[00:03:21] The way I think about it is companies are a mess. I haven't found a company that's actually structured in a really nice way, and this cup of coffee is my metaphor for how most companies operate. You can pour this cup of coffee, it works. You can build software products; it works in your companies, you're producing software. But it's brittle, and any small nudge is going to knock it over, and it's all going to collapse. People are nervous, because people recognize that if you change that, then it's going to have this effect here, or it's going to knock on there, and how are we supposed to manage that? Because they're not going to do that, and we're going to have these gaps and those kinds of problems.

[00:04:01] So you get these questions, like, how does documentation work? I can't remember them off the top of my head, so I have to turn around. Teams can only move as fast as the pipeline: that's one that frustrates me, when you have lots of teams working separately but then they have to merge back into the same code base, so you just get blocked by each other. It doesn't really matter if you start doing something better; you're going to get blocked. How do we know we're solving the right problem?

[00:04:28] What is my role? That's a big one that I've met with a lot of functional managers. When you say, "Let's try to have a bit more autonomy in teams, and they can decide some of the processes," it suddenly becomes, "Well, if I'm not allocating people to the team, and I'm not telling them how to work, and I'm not in control of the budgets, you're really slicing away at my role here. What are you leaving with me?" So there can be a lot of that, people saying, "What is my position in all of this?"

[00:04:57] And what ends up happening is you end up with water-scrum-fall, or something like that, where we're so agile: we do our sprints and we do our standups and we do our retros, and we're just not moving very fast, and I don't know why, and it must be because agile doesn't work.

Two classes of problem in a retro

[00:05:16] We were chatting about this as well. A lot of teams do retros, and retros are fantastic, and I really advocate for them. But in my personal experience of doing retros, I found that there are two classes of problem that come up in a retro. There's one that's within the team's control. It could be about, "If you're handing over there, I'd prefer this," or, "Can we sort this out?" That's fine, because it's just within the room there, within the retro, and people can agree on making some changes.

[00:05:43] But often the real value comes when you're trying to change what's outside of the team. Can we release independently? Can we as a team get our code to production and test something? We've got an experiment we want to run; can we just get it into production and test it? "Oh well, no, because you have to go through the change control board, you have to get it signed off, you have to get it merged into the code, it has to then go through production testing." That's the real value-add, when you can start working autonomously, but that's when you start interacting with a lot more people. From my experience of retros, that's where a lot of those go in the parking lot, and you work on the ones that you can do. So you are improving, but you're not making that big step forward.

Change is about real people

[00:06:30] So, implementing behavioral changes in a complex environment. Why I say this is that I'm probably the worst person for just trying to break things down into logical steps. I love maths, I did all sciences, I did computer engineering in university, so my brain is very logical and focused. I look at a problem and I think, how can I break this down, how can I get it fixed? That works perfectly with a waterfall way of working, because it's, "Let's do a big plan, let's get everything right, because we don't want to do any rework."

[00:07:07] But when you're changing a company's culture, or trying to change how they work, you're not changing a system. It's not a separate entity. It's real people, and it's their status with their jobs. Do you have fear? If you're an expert in something and somebody asks you to do something else, there's fear in that: "What if I'm not good at this? What if I can't work in that way?" So there are a lot of human elements involved in change. It's not as simple as, "I'm just changing this." You have to start thinking about the human side of it.

[00:07:50] And the three key things that I say, and if you notice, this looks a little bit like product development, because product development is changing customers' behavior. This probably isn't my best example of a product development workflow, but it's similar, because if you are releasing a product, you want users to change their behavior. What we need to do there is have a vision of what we're trying to achieve. But we're not going to be able to do that all in one go. As Manu said, you shouldn't try to change everything in one go, because it won't work. It's too much for people to take on.

[00:08:27] So it's great to have the vision of where you're trying to get to, but you need to be able to share how we're going to get there. So a roadmap, and a vague roadmap, not a very detailed Gantt chart. And then start iterating, because you know it's going to change as soon as you do. But how do you do that with your brittle coffee cup situation?

[00:08:53] I was going to say it's happily ever after: if you follow those three steps you'll get your changes done, so you don't have to worry, and I hope everybody can get whatever you've learned implemented. But as we all know, it doesn't happen that easily, because it is that human side. It's nothing that you can plan up front. It's about creating connections with people, figuring out their problems, figuring out where you can start small, and then getting the ball rolling.

KPIs eat culture

[00:09:20] A lot of people say this phrase: you might have a strategy and a plan, but culture eats strategy for breakfast. I don't know if you've ever heard that phrase before. The concept there is that a lot of companies might say that they want, and psychological safety is a good example, "We need empowered product teams, and we want them to be able to speak up and contribute and share their ideas." But if you sit in a meeting in that company and you see what happens when a problem arises, and it's shouting and pointing fingers and it can be quite aggressive, that's where the culture is. You might say the words that you want empowered teams, but your culture is not enabling empowered teams.

[00:10:09] My problem with culture as the answer to this, because a lot of people go, "You have to change the company culture, start with the culture," is that it's nebulous. What is culture? How do I change that? I have to go in and start making people happier, but how do I do that? Luckily there's a cheat, because KPIs eat culture. People are just reacting to the incentives that they have in front of them.

[00:10:36] If we can start looking at the incentives that are leading to particular behavior: if somebody is a particularly aggressive manager and they get promoted, that's telling you that that is valued in that company, so that's what people are looking for. Whereas if you're trying to enable it, you need to put in KPIs that are all about how you can empower the teams, and put in place things like 360 stats on how much the teams feel that they can control, or other metrics to try to figure it out. It's about actively thinking: if we want this culture, what are we going to do, and how are we going to put in place KPIs for people that will lead to the culture? Because only then will we be able to get to the strategy that we're trying to get to.

Setting the vision at Aer Lingus

[00:11:26] So that's a bit of the intro to it. The first step, as I said, was setting the vision, and I'm going to give an example here of when I worked with a team in Aer Lingus. We got the whole team together and we just said something simple: where do we want to be? We put this chart up on the screen, and we probably had two hours just chatting about this chart on its own.

[00:11:48] At a high level, across the top, it's just got the typical steps of releasing code out to the system. You code, you build it, you integrate it with all the other components, you test, deploy, operate. And then the arrows are the different buzzwords in the tech industry: continuous integration, deployment, delivery, et cetera. We asked them, "What does that mean for each of you, and where do you want to be?"

[00:12:18] They didn't actually want to get down to that bottom line. They said that wouldn't work for them, because they're a mobile app team. If you're doing continuous deployment, where every line of code that you write gets released, that's going to be a million updates on your app store. So they didn't want to be releasing to the public every single line of code that they write. Whereas if you're on a website, maybe you do, because you want to get that line of code out to the customer as quickly as possible. But they were thinking about the usability of that. What they agreed on was, "Let's get to continuous delivery, where we get to choose to press the button, and the system just doesn't press that button for us."

[00:12:57] That seems like such a simple thing. It's just one chart and it's just one line. But that led to so many debates. How would QA fit into that? Because there's a lot of automation: are QA getting replaced by automated tests? How does it work that we can guarantee that after a developer pushes some code, it is in a releasable state, and all we have to do is press the button?

Bugs are the team's responsibility

[00:13:22] That's where it comes down to some of the challenges you feel, and I'm going to dig into that QA one a little bit more, because it comes down to what I said at the start. This is people's jobs. Your job, as much as we all say it isn't, often becomes part of your identity. So when somebody starts suggesting making changes, that can almost feel like a personal attack, even though it's not. Even if somebody's just looking at how we can change some process, the other person can feel like they're being personally attacked.

[00:13:55] In this example, QA felt that they were being underappreciated. They thought they were being blamed. They were getting pressure from both sides. It was, "You have to get quicker, let's automate things, you're taking too long." But also, whenever anything went wrong, "How did you let that slip through? Why didn't you catch that bug? What are you going to do next time?" So all they'd do is add longer weeks onto their estimates, and there was this friction.

[00:14:25] Where we got to, and this took literally months, was that we said in every meeting from then on: bugs are the team's responsibility. It's no one person's responsibility. It's not QA's fault, and it's not even the dev who wrote the code. We weren't trying to just shift the blame. It was the team, and as a team we had to figure out how to solve this. And that's great: we said that in the room, and nothing changed. Absolutely nothing changed until we started living it. We had to go through a few releases, we had to get bugs to come up, we had to get people to see that it wasn't just words, that we actually meant it, and that every time it came up we weren't reverting back to the old ways of working.

A user story map for process change

[00:15:12] That was just a sideways step into setting the vision. As a team we agreed where we wanted to get to. Now the challenge is that we've all agreed, but we can't just start working there today or tomorrow. We can't change overnight, because there's too much going on. It's back to what Manu said: you don't want to change too much. Let's change little bits, and we can increment.

[00:15:35] My favorite tool for this is a user story map. I don't know if you're familiar with user story maps, but the high level concept is you create your flow across the top, and this is your high level flow of what the user is doing through the process. In this process, our users were actually the development team, and it was the steps that they were doing as they were going through the process. Then you get everybody together and they put in all the stickies about what would need to change, and when, and what happens there. So we had a big brainstorming session, but then we said, "Look, we can't change everything." So we did a prioritization and lifted things up, and that's where you get the swim lanes: release one, release two, release three. I love this as a practice for product development, but we adopted it for changing process as well.

[00:16:25] Then we were able as a team to say, "We're going to change this." And yes, there are those valid questions: what about this, who's going to do that, and what about the other? But we were able to point to this and say, "That's a valid concern. We're capturing it here, and we've thought about it. In the interim there's going to be this little hassle that we're going to have to deal with, but we have addressed it. We're thinking about it; we're just not going to solve it right now." That was our way of getting people to buy in.

[00:16:57] Because the fear a lot of people were communicating back to us when we were proposing this was that it's all going to turn into a nightmare. Particularly some functional managers were saying they were going to have to swoop in and clean up the mess after we had made a giant mess. Doing this communicated and built trust: we have thought about it, we're not just flying by the seat of our pants. But it's not 100% worked out. I can't tell you how anything in release two is actually going to happen. We've just got a few words on a note saying it's something that we definitely have to solve.

[00:17:33] If I run through very quickly how we did this, trying to break it down: we put this one together, and what we started looking at was agile development, where you could do user story mapping, the approach that I just described. Then we realized that if I do my user story mapping and break down my ideas, instead of having a feature where traditionally we would have put together a big project plan and thought about all the moving pieces, now I'm saying, "We're only going to do this little sliver at the top." That becomes really hard for architecture in a company, because the architects typically like to do big blocks of work, and they don't have enough capacity to keep flipping every day to look at something else. So we needed to flip to more of an evolutionary architecture.

[00:18:26] And then how do we do the governance? Because it's back to a business case. I can't tell you how much time and money we're going to save when we're just in release one, because I don't actually know how many users are going to use this, or if they even like it. But that's the point: if we find out that they don't like it, then we should stop doing it. So give some interim measures. We can't measure the value directly at this point in time, but we can give some other metrics, cycle time, release frequency, that show that we're moving in the right direction.

[00:18:56] I won't go through every single piece of this, but the idea was to show people that we've started to think about it. We can't just do user story mapping, because that impacts architecture. How do we deal then with governance? How do we deal with all these other bits? It was about the concept of putting in place, "This is how we're going to tackle it." We don't have the answers for the lower level ones; we're just going to start here and we'll figure it out as we go along.

Authority and governance challenged

[00:19:20] It didn't go well. I presented that, and you think, "We've thought it out." But this is what I was saying about the functional manager role. It was, "You're taking my team, you're taking my process, you're taking everything away from me. What are you leaving with me?" That's where authority was challenged. What we realized was that team size equals social status. People in there would say, "I've got 100 devs in my team," or, "I've got 50 QA." They'd talk about their team size as a relative social status. So if we said we're going to carve out teams and put them in separate teams, then suddenly somebody who had 100 people now doesn't, and they don't have as much authority and control. That feels like a social attack.

[00:20:12] So try to approach it with empathy. The sales pitch I love is that I much prefer the job of a functional manager after you have product teams, because you get to focus more on strategy, you get to focus more on the long-term vision, and you're not doing admin. It's a nightmare, I don't know if you've ever had to do it, but if you're working in a project structure and a project gets delayed, those people were supposed to move somewhere else, but now they can't, and people get dragged into weeks of these reorgs, which deliver no value. That's what we tried to pitch.

[00:20:49] It worked not so well. That's when we went to the KPIs. We went a step up and said, "Look, this is the culture we're trying to build. We're not getting much progress. Can we do something to try to shift that culture?" And then start iterating.

[00:21:07] And again we had problems. It was great, you've done that, and then finance came along and said, "You do whatever you want. I just need the business case with the scope, the sign-off, the exact amount of money you're going to spend, and how much we're going to return, and then you can do whatever you want." Which didn't really leave us with much scope to iterate. So we did what any good people would do: fake it till you make it. We worked with their system, we made these business cases, and then they'd come back and check how we did. Of course, what we had built would be completely different to what we had put in, but it bought us a little bit of time, and then we could demonstrate some value.

[00:21:50] So governance was challenged. They wanted predictability. They wanted utilization; that was a really important one. You put these people in a team, and in the project world it's always, "This is a more important project, I'm going to steal people from here and put them over there." But if they're ring-fenced in a team, you can't do that. What if one team's really busy and one team isn't as busy? That was a big pushback.

[00:22:13] What we did was ask, "What is governance?" We broke it down to its principles, and governance is two things. Where are we spending our money? And is it working? What we were able to do with a product team is say, "This team is building this particular thing because that's part of our company strategy. How much do we want to invest in that? That's up to you. You can tell me how much we want to invest in this space, and we'll build a team or multiple teams around that." So now we know how much money we are spending, and we know it's aligned to strategy, because you're going to tell me how much you want to invest in different areas.

[00:22:48] Is it working? This is my biggest bugbear of a question, because I don't know if anybody has ever done a business case, and the lies that people put into it about how much money you're going to make after you release something. There is zero predictability. I was chatting to a CFO: if they had made the money that they predicted from every business case for the last three years, I think they would have been one of the richest companies in the world. So it's not predictable. It's a false predictability with business cases.

[00:23:18] Whereas with agile teams who are actually really delivering, what you're starting to see, when you get to the stage where they're able to control their own destiny and deliver quickly, is real predictability, because you're seeing what's happening. Then they can course correct, or learn, "Look, we thought this would work and it's not, so let's kill that baby and move on to something else." Which is the hardest thing to do when you get emotionally invested in some project, but you have to make the decision to move on.

Key learnings

[00:23:49] So what are the key learnings to take away from this? Change is the same whether it's internal or customers. What I mean by that is I think product development and internal change management are the same problem, and we can use the same tools to address them. When you're building a product for customers, you need to make sure that they actually care about it. You need to understand their needs. You need to understand what the pitch is that will get them to adopt it. And that's the same thing that you're doing in internal change. You need to understand who the key players are, you need to understand their concerns and their motivations, and you need to get your pitch right for those people. That's positive, because everybody in this room has the tool set of product development, so we can just reuse that.

[00:24:41] The second one is that aligning on the vision saves countless meetings. This to me was so true. I don't know if anybody else has felt this, where you agree something, everything's great, you go on, a week later you go into a meeting, it comes back up again, and you have the same rehashed arguments over and over again. It wasn't until we literally had that chart, and it's such a simple chart, but it worked really effectively, that everybody started saying, "Okay, this is what we mean, this is what we're getting towards." That was our vision of where we wanted to be, and we just didn't know how we would get there yet.

[00:25:18] A roadmap can share the bigger picture, allowing teams to iterate. That's where the user story map comes in. I wouldn't put dates on it. I know there's the everlasting argument between product managers, a roadmap with dates, and sales teams. And you will probably have a bit of, "How much time and effort will we invest in this before we're spending too much money?" So you need to make sure that you're as lean as possible.

[00:25:48] But the user story map lends itself to building trust. One, it's transparent about what you're trying to achieve. Two, you're saying that you're only going to bite off a small chunk initially. And three, you can demonstrate that you're delivering over time. Because if you just say, "We're going to deliver this," and then a month, two months, three months later you're still not really making any progress, then you're not building the trust that you need to. This way of demonstrating and sharing the transparency gets the buy-in, but also keeps people a little bit accountable for following through and actually making change happen.

[00:26:25] And then, practice UX strategies and empathy with your own team. As I said, you have the tool set in the room. I've chatted to so many people and they're like, "Oh, the manager just doesn't get it." Well, what would you do if somebody said, "Oh, the customer just doesn't get it, they don't know how to use the product, and we just need to train the customer more"? You wouldn't accept that as an answer. If the customer isn't accepting what we're building as a product, we have to say the same thing about the process change that we're pitching. Why is the customer, being our manager or somebody else, pushing back? Because that's telling us something about how we're going about it, or what those changes are going to do.

[00:27:07] With that, I'd like to open up for questions. Apologies again that Sam wasn't able to join us, but I hope that was somewhat valuable as a quick replacement. Thank you.

Q&A

[00:27:26] Audience: I didn't expect to have to ask this so soon. Just before the pandemic started, we were doing a lot of story maps. We had sticky notes on walls and glass walls and writing everywhere, and it was great. Then the pandemic hit, we all went home, and we started using a thing called Cardboard for doing our story maps. We were using the free one for a little while, and then we started paying for it, but it became very expensive, so we stopped using it. Then the pandemic raged on and we just forgot about story maps. What's a good online tool for collaborating on story maps, in your experience?

[00:28:00] Rory: Well, I'm going to plug Figma, our sponsor here today.

[00:28:05] Audience: We use Figma as well, yeah.

[00:28:08] Rory: They can talk to you about FigJam. No, I don't think you have to go overly complicated with the tool that you use. I like those infinite-space whiteboards, because it doesn't need a crazy structure. It just needs to be there so that people can reference it. The challenge I find, though, is that the physical ones are great because it's, I don't know if you'd say serendipitous or just subconscious: you're seeing it because it's just there on the wall, so it's hard to ignore. Whereas if it's just another file in another folder in some shared document, people don't see it as much.

[00:28:52] So I think there are two things. One, I think the online tools are fantastic, because you can get a broader reach. But two, you have to think about what your comms strategy for it is, because if you just make it, they won't come. So you have to be thinking, if we do a standup every day, maybe we'll just put it on the Zoom share, and people can see it as we're chatting. Or just try to think of different ways that you can get it seen. You don't have to talk directly to it, but if you were in a room and you had it on the wall, it'd be the same thing as sharing it on the screen. It's trying to just get people to think, "Yeah, this is what it's here for," because there is the risk of it disappearing. In terms of the tool, I personally just use those Miro, FigJam, Mural type of tools, and the free versions are pretty good.

[00:29:46] Audience: Hi, I'm way at the back. I was really interested in your slide where it said KPIs eat culture for breakfast. What I felt wasn't in there was team psychology, and the psychology of individuals in our team, because KPIs will only really work with people who are externally motivated, motivated by external factors. You'll always have people in your team who are there for internal motivation. They enjoy the job, they enjoy being passionate about the product and about their role. You can put KPIs around that that run counter [?] to that, and it will disenfranchise them and demotivate them. So the makeup of your team has to change when you drive it to being KPI driven as opposed to culture driven, because you lose those people who are internally motivated to do the job they do.

[00:30:49] Rory: Yeah, that's a fantastic question. I think there are different types of KPIs, and it's down to that motivation: there's intrinsic and extrinsic. The carrot and stick, as they say: you're going to get a bonus if you do this, or you're going to get fired if you don't. They're terrible KPIs in creative work. They don't work. But what does work: there are the internal ones, the three that are popular, which are mastery, autonomy, purpose. But the fourth one gets dropped a lot, which is relatedness.

[00:31:28] That's one thing that I've seen a lot of teams do, trying to figure out, "The KPI is about how we work better as a team. How can we do that?" So we're building in KPIs about communication or sharing. There isn't a simple answer, but you need to make it about the team collaboration, because that's often what it normally is: it's about shutting down certain behaviors. You make it a value, even, that if somebody sees a particular behavior they address it.

[00:32:00] In Amazon, for example, they make their values into KPIs. One of their values is the openness of teams, and if they see somebody reacting against that, that aggression of putting somebody down, part of your KPIs is to be living the values. That's one of the ways that they try to address it. I hope that answered the question a little bit. It is a big challenge. You don't want to make it a metric where you're going to get a bonus or you're going to get fired if you don't do this. It's more about trying to tie into the relatedness: as a team we're in this together, and this is how we have to work.

[00:32:39] There's one here.

[00:32:42] Audience: Yeah, Rory, you said you had a simple chart to align people on a vision. I would love to hear more about the simple chart.

[00:32:50] Rory: Oh, that was the image that I showed. I was just using one example of a team that I worked with, where it had code, release, integrate, test, deploy, and then the options. Because we were talking about the process we wanted to agree on: did we want to be just agile development, did we want to be continuous integration, did we want to be continuous delivery, deployment, and then the 10,000 deploys a day type level. But that's not for every team. That was just that one team in that one example, because I thought it was a great example of, where do we actually really see ourselves as a team? What would be excellent to us? And then we could start trying to get to it.

[00:33:35] Great. I'm around obviously for the next few days. We're out of time, but if you do have any questions, I'd love to hear from you.