Everyone's Onboard. So Why Isn't Change Happening?

May 139:05 am – 9:40 amStage: Main StageTalk
Slides

Checking session availability…

Hang tight while we load the latest updates.

Have you spent week's pulling together the data to make a compelling case for changing your processes or adopting a new way of working. Your manager congratulates you on doing a great job and everyone is on board.

But then nothing happens.

It's clear that we will make more money or save more costs if we go for it but there are always competing priorities and deadlines that seem to trump your change.

We'll talk through why this is happening, and what you can do about it.

Everyone's Onboard. So Why Isn't Change Happening?

Rory Madden at UXDX USA. Video: https://youtu.be/eFmBNnuuoAU

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.

Everyone is motivated, so why doesn't the change happen?

[00:00:08] You're all here because you're motivated. I'm preaching to the choir right now. You're all super excited to try out new ideas. You're the people who are coming here to figure out what's the next best thing, how can you improve the ways you're working. But then you get back to your company and you get frustrated because you just can't get that change through. I don't know about everybody here, but I definitely have felt those frustrations when I'm trying to get changes pushed through.

[00:00:31] I'm going to give a story about when I worked at an airline back in Ireland a few years back. They had a very traditional IT stack. You had your UI layers, you had services, you had an enterprise service bus, you had backends, multiple different backends. And the way they worked, everything was a project. Everything involved every single layer at the same time, and you just had all of these projects overlapping with each other. What ended up happening then is that one project would get delayed and it would have this domino effect on all of our projects. We were constantly replanning and there were constant delays. It just meant everything was slow and expensive.

[00:01:09] So what we did was we said, okay, we're going to pull out mobile apps. The reason we did that: it's not the classical pure way of pulling out, because it's not a vertical slice, but it was the best we could do with the situation and the politics and the technology that we had. And with that, we managed to increase customer satisfaction and reduce our time to delivery by 30% for mobile releases in the span of two months. It didn't take us long at all, once we got the authority to work the way we wanted to work, to start implementing and seeing some real value.

[00:01:44] We then got all of the functional managers together and said, look, this pilot that we did, it was great. We showed it worked, and it took a really long time to get agreement to do that pilot. We said the value is clear. Let's do web. And everybody in the room said, yeah, makes sense. That makes perfect sense. You've sold us. It's brilliant. The value was right there. If we can get the same similar kind of reduction in cost for releasing, the speed increase, it's perfect.

[00:02:13] So then my next question is, okay, will we do it tomorrow? And what do you reckon the reaction was? Everybody was bought in. Everybody was on board. What do you think happens? Who thought we started tomorrow? No. No. Well, we just need to get a couple of projects finished first. All those overlapping bars, they need to get finished because they're a little behind schedule. We've had a few delays and a few problems. But we're going to put together a business case, because that sounds like a really good idea, and we'll just get the funding to do it, because it's going to cost a bit of money. And we'll have to schedule that in with all of our other projects, because now is not a great time. Finance are breathing down our necks, and the quarter results and stuff. But we're going to park it and we're going to come right back to it. So has anybody experienced that when they're trying to pitch a change? Yeah, we're seeing some hands come up.

[00:03:03] They just don't get it. That's the problem. The problem is I understand it. The value was clear. They didn't understand it. They didn't understand the value well enough. That was the problem. So you know what I'm going to do? I'm going to pitch them harder. That's the best way. I'm going to tell them. We all talk about the value of UX, the value of design, the value of DevOps. Let's keep pitching people. So I just looked up some articles: 2003, 2020, 2006, 2014. What's the definition of insanity? It's trying the same thing over and over again and expecting a different result. It's not that people don't get the value. They understood the value. Everybody in that room saw clearly the value of it. But yet we still couldn't get that change to happen.

[00:03:52] I've worked with so many people, and you'd be chatting at lunch break going, ah, management just don't get it, it's so frustrating, why won't they let us do it. And then they get promoted and it's like they've had their memory wiped, because suddenly they're the person objecting to all the changes. You're like, what happened here? So we need to figure out what's going on, because we can't keep bashing our heads against the wall trying to make change happen if it's not working.

Challenge one: does your boss really care?

[00:04:18] So challenge one: does your boss really care? Of course they're going to say, oh yeah, that'll reduce time and increase revenue and profits are going to be great. But do they really care?

[00:04:32] This is a famous thing: culture eats strategy for breakfast. I don't know if you've heard of that saying before, but you can have the best strategy in the world, and if your company culture isn't set up to deliver on it, it's not going to happen. I always thought that was really weird, because culture sounded like this awkward concept of, how do I change a culture? It's easy. KPIs. KPIs change culture. People behave in their own self-interest. If I'm going to get a bonus for hitting a particular KPI, I'm going to do that. If I'm not getting a bonus for a different task, I'm not going to do it. And Satya Nadella, the speed that he turned around Microsoft when he took over, because he changed the KPIs and he changed what mattered. So you all have a t-shirt with that. Hope you enjoy it.

[00:05:19] The KPIs that most people are using are predictability. Are we on time and on budget? People get promoted for being on time and on budget. So if you come along and say, you know what, I'm going to do something that's really disruptive, and all those projects that need to be on time and on budget, we have to pause or delay or do something, so you're not getting your bonus this year, but it's going to be great for the company. Of course nobody's going to do that. And the same with utilization of resources. If you're trying to get people onto capex projects and you're saying, well, no, we have to do this reorg, it makes things difficult.

[00:05:58] So you have a KPI: did I deliver on time and budget? If you promote something like, let's do continuous research, continuous discovery, and you're saying, well, I want to keep talking to customers. Well, that's scope creep. That's the opposite of delivering on time and budget. So yes, we'll end up with better outcomes for the business, but that's not my bonus. That's not my KPI. My KPI is on time and on budget. So I'll tell you how amazing your idea is, but I'm not going to support it. It's difficult to get a man to understand when his salary depends on not understanding. It's a great quote.

[00:06:35] Lesson one: you have to start with KPIs. It's not motivation, it's KPIs. That's what drives real change. And revenue is the worst possible KPI you can choose, because that's the default. When everyone goes, okay, we're going to shift from outputs to outcomes, revenue. Let's see, can we increase revenue? The reason it's a terrible KPI is because it's so far removed from the work that we do day to day.

[00:06:59] There are four different types of metrics you can use when you're tracking work. You can track the effort, how many hours are people working. You can track the output that they build. But our problem is back to that first slide. Our outputs are not delivering. They're not achieving the business objectives that we're hoping they can. So that's why you move into the outcome. You start looking at what's the customer behavior. If I release this and we're expecting X percentage of customers to use it, or a certain amount of conversions or something like that, that's the behavior that we need to be tracking. But if we try to skip that step and jump straight to revenue or cost reduction, it's too lagging. It's too far removed. When somebody releases a new feature, it takes too long to figure out did it work or did it not work. That's why we need to get that sweet spot in the middle.

[00:07:51] And it's really easy to say, just change your KPIs. That's not going to be very easy to do at all. If you walk into your company and just say, you know what, we should change everybody's KPIs because it doesn't achieve our goals, you're not going to have an easy time. But that's the critical first step, because until then you'll get all of that, oh yeah, everybody's on board, everybody can clearly see the value, but it's not going to happen because it's competing with their KPIs.

Challenge two: what are you really asking for?

[00:08:22] The second thing is, what are you really asking? Let's take that example of continuous research or continuous discovery, where you want to keep talking to customers the whole way through. Let's just take an example of that and see what we are really asking of our boss.

[00:08:37] What we're saying is we want to get rid of that idea of here's a very fixed scope. We want to have it so that it's quite open, because maybe we go on a slight tangent and we learn something as we're going, and we figure out our original idea wasn't the best and now we have to go a slightly different way. What that means is we have to get rid of locking down our scope in a business case or something like that.

[00:09:00] We get to decide what we build and we get to decide how we build it. That's what you're really asking. And what your boss is hearing is: not a big fan of all of these reviews that other departments are doing, really have to get rid of the business case process. We're just going to keep adding scope and changing things as we go the whole way and just spin our tires the whole time. And you know what, we have no scope, so you can't measure time and cost anymore, because there is no fixed scope to measure against. But we promise we'll be efficient. What they're hearing is, well, I can't support this, because it goes against every concept that we've learned and how we've operated about being predictable, being on time and on cost.

[00:09:43] But also you've just asked your boss, now can you just go to every stakeholder around the business and tell them all, the marketing leads, sales leads, that their whole way of getting software built is changed, and now it's going to be an influence role rather than an authority role, and they can't tell us exactly what to build but they can influence it. And can you get the senior execs to agree on a change of funding? Also our governance processes, get those changed. Maybe we need to re-architect our organization, because the structures don't work, I don't want those silos. Yeah, can you just go ahead and do all of that process, all that structure, all of that alignment, all of that funding, governance, scaling. Yeah, I really just want to do this continuous research. Can you look at that other stuff?

[00:10:32] And that's impossible. That's incredibly difficult. The amount of political will that you would need to try to make a change like that, with so many different departments, with so many different stakeholders, unless you had absolute top level support, you're not going to get it done.

[00:10:46] So your boss is hearing this going, you're just giving me a hell of a lot of work to do. So you know what, we're going to park it right now. It's a brilliant idea. I love your initiative, by the way. Thanks for bringing this to me. But we've got a few things on the plate at the moment and we will come back to it. I promise. I promise.

Motivation versus ability

[00:11:04] There's a brilliant model by a professor in Stanford called the BJ Fogg model, and he says you can map change on two axes. There's motivation and there's ability. Everybody spends too much time on motivation. You keep thinking, can we sell it? They don't understand it. I need to pitch it. What's the value of it? They just don't get it. But that's the worst way. It's so difficult: even with ridiculously high motivation, if it's not easy to do the change, it's not going to happen.

[00:11:36] What a lot of people are starting to realize, and I was chatting to Miro, head of design there, and he was saying that they are shifting all of their work, because they kept talking to people and they're like, oh, all these people are really super motivated, they love our ideas, and then our traction just isn't there. So they're shifting completely to focus on making it easier to do.

[00:11:58] We think we're in the top quadrant, but we're actually in the bottom right, because our KPIs, they say they're motivated but they aren't really, and we haven't made it easy for them to do it. So you have to make it easy. You have to start with your KPIs and you have to make it easy.

Process is not the problem, bad process is

[00:12:15] Here's a controversial opinion. I'm about to get shot, but I am a process geek. I actually love process. Everybody always hears, process is terrible, we have to get less process, it's more individuals and interactions over processes. But process isn't the problem. Process is literally just seeing how people interact when they're trying to do something, and writing that down and saying, okay, this is the best way of doing it. You can have good processes and you can have terrible processes. But if we tell everybody, you have to go and figure this out yourself, agile is a mindset, you just have to go with the flow, that's not making it easy for somebody to do it. So I think you do need process to make it easy.

[00:13:00] When you're repeatedly building the same thing in mass manufacturing, the siloed waterfall way of working is the most efficient way of working. But when you're working on something brand new for the first time, it's cross-functional. It's get multiple different ideas into the room and iterate on an idea. So both of those are processes. The problem is, when we hear process we automatically think of waterfall on the left, whereas we should be thinking, well, let's get a process that can do the best cross-functional kind of way of working.

[00:13:32] Now the problem is we don't have anything in the market that can help there. You've got scrum and waterfall and kanban, and they focus on one section. You've got design thinking, lean UX, and they focus on another section. And then you get all of these, like, how do I merge UX and scrum and design thinking. And if you look, there's millions of responses, because this isn't easy. Again, we failed at the make it easy step.

[00:13:55] So we're not making it easy. And then there are the scaling frameworks. I think that they have agile in their names, but they're waterfall frameworks. If you actually look at how they work, it's very waterfall. It's very top down, heavy planning. So you're not really encouraging cross-functional teams. Again, it's an easier way to work, because somebody can adopt it. They don't have to change their practices internally. They were working waterfall. They're still working waterfall, but they can tick a box to say they're agile. But it's not helping us actually empower cross-functional teams.

[00:14:31] So what we're looking to do is scale empowered cross-functional teams. And yeah, loads of people asking the same thing. If you Google about SAFe and agile, and SAFe and UX, and SAFe and all these things, they just don't work together. Have we made it easy?

Standing on the shoulders of giants

[00:14:51] Back to when I said your boss has to solve process, they have to solve structure, they have to solve alignment, they have to solve governance, funding and scaling, if you want to make just a simple change like continuous research and continuous discovery.

[00:15:07] What we've done at UXDX is what I call standing on the shoulders of giants. We've literally had over a thousand talks of people sharing how they are changing their companies, because I don't want to have just a complete theory of this would be the best way. We wanted to study how people are actually doing this in the real world in real companies, and we've taken those case studies and best practices and we've distilled that into a process framework that you can adopt.

[00:15:36] So we have a process that is continuous research, continuous design, continuous delivery. We have a structure that encourages cross-functional teams. We have a way of ensuring alignment between teams. We have funding models for cross-functional teams that don't rely on business cases and fixed scope. We have governance models that focus on outcomes over outputs. And we have a scaling framework that helps people to grow this into super large enterprises. Our goal, we don't have aspirations for thinking this is going to be too easy, but we want to get it easy enough to help you. And this is all free on docs.zeroblockers.com. So you can access all of this information, read through it. I'd love to hear your feedback. And if you're interested in learning more, please reach out.

[00:16:27] To summarize on my talk: why doesn't change happen? KPIs win every time. We think people are motivated, but in the back of their head they're thinking, what does my bonus rely on, how am I going to get promoted? Number two, we have to make it easy. Motivation is not the answer. We have to try to figure out how we can make it easy to do what we want to do. And then the last one is, process is not the problem. Bad process is. If you have a process that people can follow and it's easy, that's why SAFe is successful. That's why scrum is successful. It was easy for people to just take these processes off the shelf and use them, because they want to think about their business problems, not how to run internally. So I think if we can have a good process that encourages cross-functional teams, we can start improving the industry. Thank you very much.

Q&A

[00:17:25] Host: Thank you, Rory. Rory, do we want to, we are running quite behind time, so maybe we'll have one or two questions. One or two questions. I think we could do one or two questions. Really, it's, oh man. House lights, lot of pressure on the audience here. So, questions for Rory. Rory, you covered so much ground. I'm assuming we're going to run the gamut here. I think a real, not easy, easy question is connecting outcomes with business KPIs, tools and methods.

[00:18:00] Rory: Amazon have a brilliant one for this. They call it the weekly business review. And what you do, it's not a status report. You're not talking about what you're building. You're talking about what are my product outcomes and what are my business outcomes, my revenue and my cost. Because what they found is, so many times when they came up with product outcomes around customer adoption, churn, all those, whatever their metrics were on their products, they didn't correlate. So they thought, oh, this will increase revenue, and it didn't. By doing this weekly review where they look at both of the metrics together, they were able to see, okay, we need to tweak this, we need to tweak it, we need to tweak it. Now we've got correlation. And that's how they were aligning their business and their product outcomes.

[00:18:43] Host: Wonderful. That took one minute. All right. Oh man, we'll go with the top one. All right, every stakeholder.

[00:18:49] Rory: So yeah, everybody wants to say these cross-functional teams. I explained in a bit more detail in our workshop yesterday, they're not tech teams. They're cross-functional, truly business cross-functional teams. Depending on the scope of the team, you might have marketing on that team, you might have operations, you might have customer support, you might have legal, depending on what the scope of that piece of work is. So the teams are not like tech over here, business over here. It's cross-functional together.

[00:19:18] Host: It's party over here. Party in the middle. Yeah. Yeah. I really appreciate Ben's question citing bloated timelines. There's a lot of pain in that statement. Rory, I think we could take one more, but you've got to be able to take it in 30 seconds or less.

[00:19:35] Rory: I'll try to be as quick.

[00:19:36] Host: Are we going the top one? Let's go with the top one. How do you give that much decision-making power to cross-functional teams in a highly regulated and risk-averse company?

[00:19:44] Rory: One of the things I skipped over super quick, there is literally a thousand pages of documentation on that site. One of them is around how do you get alignment? Because the biggest fear for management when you empower a team is, who says they're just going to flit off in some random direction and do random scary unregulated things. What's key there is there's a structure around a product team and a stream team. And the product team set the product vision, the product strategy. They share the values and principles of the company. They share the objectives for the teams. So it's not complete anarchy. You have what I call enabling constraint. This is what you need to work on. These are your KPIs and this is what we're going to track you against. So it's not a free-for-all, but you do have the ability. The big difference is nobody's telling you, I want this feature with exactly these things. They're telling you, you need to get this amount of customer adoption, you need to get this amount of churn reduction, or whatever the goal is.

[00:20:41] Host: Mic drop with not total anarchy. Thank you, Rory. Really appreciate it.

[00:20:48] Rory: Thank you very much.

Speaker