Everyone's onboard. So why isn't change happening?

Rory Madden at UXDX EMEA. Video: https://youtu.be/2naDtoFCxP8

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's on board but nothing's happening

[00:00:07] And on that I'll move into what my talk is actually going to be about. I hope, and this is the goal for the conference, that you all come out of here super excited. You're going to hear from some amazing speakers over the next few days. The goal is that you'll be brimming with ideas, bursting with motivation to try out the next best thing that you've discovered, and you're going to get back to your office. And when we've asked people a few weeks later, because we tried to track what's happened, there were deadlines, and there was "we had to get the project that was going over the line first," and things like that. That motivation just teeters out. So I want to talk about this common problem that we have of everyone's on board, but nothing's happening.

[00:00:53] I'm going to give an example of when I worked at a company a couple of years back. They had a very traditional tech stack. You've got your UI layers, so they had web and mobile apps. Then you had your services underneath that. They had a middleware bus for moving data around, and they had multiple backends, because this was a well-established, traditional enterprise that had been around for years. Things had just grown organically. Now the problem was everything was a project. A project touched every part of that stack every time. But we weren't doing one project. We weren't doing 10 projects. We weren't doing 50. We were doing 90 to 100 projects in parallel at any given time.

[00:01:34] And that just led to so much conflict between teams. One team gets delayed, and it just domino-effects on everybody else. It was really frustrating, really slow, really painful. And you can understand then why the business would say it is just expensive and slow and nothing gets done. We had a designer quit because he said, "I just want to see one of my designs make it to production." So these are the challenges we had.

[00:02:00] So what we did was we said, okay, we're going to try a cross-functional team. Now we didn't do it the traditional vertical slice. It just wasn't possible with the tech stack, the people, the politics, all that. So we did the next best thing, which was a horizontal slice. We took away mobile apps and we said, "Okay, they're going to be able to decide exactly how they work. No more following process, no more anything else. They decide how they work." Customer satisfaction went up and we reduced time to delivery by 30% within two months. So it was a phenomenal success. And still, we had only just ticked off the low-hanging fruit. We had so many ideas on how we could keep improving.

[00:02:41] So we got everybody together after that. It was only two months, and we said, look, that was a good success story. Let's replicate that with web. We talked about, yes, we want to get into a vertical slice, but we said let's just start carving out different bits of our stack first, and then we can worry about the more autonomous vertical slices. Everybody agreed to this. It wasn't really controversial. It was quite easy. They could see the benefits, they could see the value. It was easy. Who could be against it?

[00:03:12] So my next question then, when everybody agreed, is, can we start tomorrow? Let's get on this. There's so much value just waiting to be taken there. And what do you think happened? Did we start tomorrow? Hands up. No, you have to put up your hand if you think... okay. We didn't start tomorrow, because we just need to get our projects finished first. We had those 90-odd projects in the pipeline and they were delayed and people were giving out to us, and we had to make sure, because we needed to be predictable. We said we'd get them done.

[00:03:45] But if we put together a business case, we can get the funding to put it in the queue of the 99 projects, and we might be able to deliver it in 2028 or something like that. Because now is not the right time. The economy, and you don't want to rock the boat. We'll keep things a little bit simple. We'll park it, but we're going to come right back to it. I promise. I promise you we'll come back to it. Has anybody experienced anything like that? Now, I'm seeing some hands.

It's not a motivation problem

[00:04:17] So the problem is they don't get it. That's the problem. I didn't explain it well enough, because the value was obviously there. So it must be that they don't understand. So what I'm going to do is I'm going to double down harder and I'm going to keep explaining. Did you not hear me when I said we reduced time to market by 30%? Customer satisfaction has gone up. Obviously, it's a motivational problem. They don't understand.

[00:04:41] I like to think of it as like the value of design. I just Googled this. In 2003, there's some great articles about it. In 2006, in 2014, in 2020, 25, we're still talking about the value, because they don't get it. They don't understand. But what's the definition of insanity? It's trying the same thing over and over again and hoping that somehow it's going to be different. But this is the thing that I'm going to talk about now. We've been going about it completely wrong. It's not a motivation problem at all.

[00:05:18] And the other thing, I just love this, because so many times I've had a colleague, and you're complaining with your colleague about all these problems with management: they're just blocking us and it's really hard to get anything done. And then they get promoted, and they suddenly lose all memory of all of those problems when they were an IC, and now they're the ones blocking it. You're like, what happened? We used to talk about this. So I'd like to know, why is this happening?

Does your boss really care? Culture is KPIs

[00:05:45] And I'm going to start with, does your boss really care? Now, obviously, they're going to say they care. They're going to say, "Oh, wow. That's amazing. 30% reduction in time to market. Woohoo. That's great." But do they really care? I love the saying, "Culture eats strategy for breakfast," because you might have the best strategy in the world, but if the culture of your company isn't set up to deliver on that, you're going to end up not achieving your strategy. That's the saying: the culture of the company will win every time.

[00:06:20] I used to always hate this, because culture was this amorphous thing. How can I change culture? It's just something that can't be done. But it's easy. It's actually really easy to change culture. You change the KPIs. As soon as you change somebody's KPIs, the culture can change overnight. Microsoft is a perfect example of that. Satya Nadella came in and Microsoft just seemed to flip on a dime. It went from being a stuffy old Ballmer corporation to being this innovative, new-wave tech Microsoft, because he changed the KPIs.

[00:06:52] People are focused on, where's my bonus coming from? How am I getting promoted? And in most companies, that's your predictability. Are you on time? Are you on budget? People get promoted for being on time and on budget. People get promoted for the utilization of their resources. It's a capex-opex thing that I won't go into, but a lot of managers have to make sure that they're charging enough people to projects. So that's their biggest priority. Doing something like these change initiatives is going to make it really hard for them to hit those KPIs. It's actually going to work against hitting those KPIs.

[00:07:28] Just to give an example: if your KPI is time and cost, and let's say we were pitching continuous research or continuous design, one of those things that you're going to hear a lot about over this conference, because that's what we talk about. What your boss is hearing is that I'm going to keep talking to people the whole way through, and I'm going to learn something, and that's great, because I'm going to find out that we were going the wrong way. Whatever we were trying wasn't right and we have to pivot and we have to fix it, because we're going to end up in that 8% who aren't achieving their business objectives. But that means I'm going to keep changing things, and if I keep changing things, how am I going to be predictable? They go against each other. And there's actually a name for that. It's called scope creep. Any project manager will know that that is the number one thing that you have to stamp out in a project, because you do not want scope creep. It's the opposite of predictability.

[00:08:22] There's a brilliant quote: it's difficult to get a man to understand something when his salary depends on not understanding it. So that's where you get people going, "That's a brilliant idea. It's fantastic. It's the best idea ever." But in the back of their mind: my bonus and my promotion and my career, that's working on the KPIs that I have right now. So lesson number one is we need to start with KPIs.

Which KPIs: hours, output, outcomes, impact

[00:08:47] Now, I know that's not the easiest thing to do, but I'm hoping that this is going to at least give you a bit of understanding when you're having these conversations, because you can start doing research, empathizing with your manager, to see where they're coming from. It's like all research. People will tell you one thing and then act in a different way. You need to understand the underlying motivations.

[00:09:08] But when you say, "Okay, we're going to flip to KPIs," what's the number one thing that usually happens in companies? They say, "Okay, you're now on track for managing revenue. If you're going to move away from predictability, we'll give you an outcome. You have to bump revenue by 3% or whatever," because that makes sense to business people. Predictability is one thing, but if not, let's go with revenue. Maybe it's reduce costs or something along those lines. But the problem with that is it's so removed from our day-to-day work in product, because we don't know, when we're building a product and we're doing a small test, is that really going to result six months down the line in a bump in revenue? Because revenue isn't instantaneous. So it's a really difficult metric to use to validate against whether we're working or not.

[00:09:58] And there's really four ways of tracking metrics. The most basic and simple one is hours. How many hours is somebody working? This comes back from factory days, where people would clock in and clock out. So you're just tracking how many hours they were working. You were hoping hours would turn into productivity. But there's a difference between somebody sitting down and being lazy on the job and somebody working really hard. So output is the next step. How much output is somebody producing during those hours? And that's where we are with most of our software projects. It's the output. Have you built the product yet?

[00:10:37] I'm going to jump to the last one. Impact. That's what the business really cares about. They're here to make money. So whether you're making money, you're reducing cost, maybe it's a strategic initiative that they want to do. That's the ultimate goal. But we need to get into that sweet spot in the middle, which is outcomes, which is around the usage and the customer behaviors on our products. Because we're going to assume, and it is an assumption, that if people start using or acting or behaving in a certain way, it will lead to that impact. And we're going to have to test that and make sure that that actually works. But that's what we need to do. We need to set those goals for teams and say, "Okay, track these product behavioral actions."

[00:11:20] It's not easy. If it was easy, we'd already be doing it. All our KPIs would be aligned like this. It involves a huge amount of trust, and trust has to go both ways. This is a huge thing for managers. They're putting their neck on the line if they start empowering teams, because it's so easy, and you're not going to get fired, for just following a project that everybody else has already signed off. But if you start putting your neck out there and saying, "Okay, I'm going to trust the team," it can be really scary. So that's why teams do have to work closely and be almost completely transparent about everything that's happening, to try and repay that trust.

[00:11:58] It's not easy, but unless we start and get our KPIs changed, you're going to keep running into that "we have to get this project done, it's not a good time," because nobody's actually... they don't really care. They say they do, but they don't really care.

What are you really asking?

[00:12:16] And the second challenge is, what are you really asking? We'll go back to that continuous discovery example, and we'll translate that. Pretend I'm a manager trying to figure out what's involved in this. So we're going to come along and say, well, we're doing continuous discovery, so we don't want to lock down our scope early. We're going to just keep talking to our customers and we're going to pivot and figure out the right way of getting there, and it'll be much better. We'll have much better outcomes. So we decide as a team what we're going to build, because as soon as you start telling us what to build, then we're not learning. We're just following orders, and we're not going to have that learning cycle, and we're going to end up with that 8% of effectiveness.

[00:12:59] So what your boss just heard is, "I'm not a big fan of these reviews that we're doing around the company. I'm not a big fan of signing off business cases, because that's locking in scope. We're just going to keep asking or adding scope here as we go and just keep talking to people. And we're going to be efficient. We promise." It's incredibly scary, because all of the checks and balances that have made companies successful, we're saying we want to remove all of those checks and balances. We want to just go to this complete trust.

[00:13:35] And it's not just the process that changes, because if you think about it: can you just go ahead and talk to every marketing lead, every operations lead, every finance lead, everybody else, get them to agree to this? Can you also confirm it with the C-suite, because we need to make sure that our funding is going to change, because we're not going to fund business cases, we're going to fund teams. PMO, all of their processes, can you just tell them we're ignoring them? Who else have we got? We've got architecture. Yeah, we don't like that delay of going to architecture. We'll just do that in-house as well. Engineering lead. Yeah, trust us. We've got this. So can you go and just confirm with all these people that we're going to ignore every process that we have in the business, and we're just going to do it this way now. So, thanks. Thanks. That's great. So, just leaving aside the politics, which is probably the bigger challenge.

[00:14:25] What you've asked your boss to do is they need to come up with a new process, because you can't just say we're going to throw out our old process and not have a process in place. I have been so guilty of this in the past, of "oh, agile's a mindset, it isn't locked down, people and interaction over process," and all this kind of stuff. But you have to have a process, because otherwise, if that manager agrees to it and it all falls apart, they're going to come to him, or her, and go, well, what did you do? And you're like, oh, I trusted the team. Well, prepare your CV, because you're going to be out of a job.

[00:15:00] But then it's structure as well, because we can't have teams of functions like we do today. You have to have true cross-functional teams. So that actually involves changing from a functional structure to a cross-functional structure. But how do you do that? And who's in charge? What about alignment? If you have all these empowered teams and they're all going in different directions and nobody's solving the business strategy... Alignment is really easy with business cases. The managers sign off and they tell you, go do this. Alignment sorted. Funding. Business case gets funding. Go build this product. But now, how much do we fund? Team A more money than team B? Why? Who should be on each team?

[00:15:39] What about governance? Time and cost is brilliant for governance, because you want to make sure that you're spending your limited budget where it's best. You don't want people running off and doing crazy things. You don't want people spending money where they shouldn't, because we all have more ideas than we can execute on. And then scaling, because all of the frameworks talk about one team, but we're not one team. We're hundreds of teams. It's back to that model that I showed you at the start, of all of those projects that were overlapping and interacting and causing conflict with each other. How do you scale when you don't even have the luxury of knowing what everybody's going to be working on up front?

[00:16:13] So this is a really, really difficult problem to solve. And it just started with saying, can we do continuous discovery? It was a very seemingly innocuous request that has turned into this whole organization restructure. So what your boss just heard is, "I'm really busy and you're giving me a lot of work to do." So they're not going to be as invested in doing this, because they already have a full plate of work. So yes, oh, 30% improvement in delivery, that's great, but yeah, let's just keep our current projects. Let's just do what we're currently doing, because I don't have capacity to take this on.

Motivation versus ability: make it easy

[00:16:53] There's a brilliant professor in Stanford, BJ Fogg, and he came up with this change chart. He said there's two axes to change. There's motivation, which is where I started with. They don't get it. We have to sell it. We have to sell the value. We have to convince them, because that's the problem. That's why change isn't happening. But he said there's a second axis of ability. How easy is it to adopt what change we're suggesting? And he argues that they're kind of equivalent.

[00:17:26] And I actually argue, and it was funny, we had a Berlin meetup where Miro were talking about this exact same thing. They would talk to customers, everybody was super pumped, but they didn't make the features easy to use, so they got poor adoption. I think that's true as well with change. Unless we make it easy to do, we're never going to get these changes happening. So we think, oh, 30% improvement, everybody's going to want to do it. We just demonstrated it with one team. We demonstrated it. So it's easy. But where we actually are is we're in the bottom corner, because people don't really care and it's really hard to do. It's easy to do in those pilots off in the corner, but when you're trying to roll that out across a whole organization, that's when it gets really tough.

[00:18:15] So lesson two. Lesson one was KPIs. Lesson two is we have to make it easy. But this isn't easy. And this is the challenge. If it was easy, I keep saying it, everyone would already be doing it.

Process is good, if it's the right process

[00:18:30] So I'm going to go with a controversial opinion alert. I might lose half the audience now in a second. Process is good. I like process. I'm a process nerd. What I mean by that is process has a bad rap, because we're thinking of the processes that have been forced on us, which were fantastic in old days in different kinds of industries but don't fit what we're doing today. But process is just literally watching people work and then writing it down and saying, okay, this is how we want you to work. So process by itself isn't inherently good or bad. It's whether it fits your current context or it does not fit your current context. So I argue that we should be pushing process, but we need to be pushing the right process.

[00:19:25] Waterfall came from mass manufacturing, because it was the most efficient way of repeatedly building the same thing over and over again. Instead of having a craftsperson who could take months to build something, you slice it into the tiniest little jobs and you get experts who can really do that job over and over and over again, but they're actually building the same thing over and over again. We can copy and paste code. So if we ever wanted to build the same thing twice, we would just copy and paste. We never build the same thing twice. And that's where, if you're building something new, you need that cross-functional. You need multiple inputs, different skill sets, different ideas, different vantage points working together. But that's a process. That's still a process. But it's a process that encourages cross-functional collaboration versus one that discourages it.

[00:20:18] The problem is we don't have a cross-functional framework for product development. We've got Scrum, we've got Waterfall, we've got Kanban, but they focus on from the point that you know what you're going to build until you build it. They don't focus backwards. We do have frameworks that focus on the other side. We've got design thinking, we've got Lean UX, we've got double diamond. That's all about trying to figure out what to build. So that's our research: zoom in on our problem point. Okay, let's figure out what's the best solution. Zoom in. And then it's, okay, now we'll pass over to the delivery side. But what we really need is to be cross-functional the whole way. We shouldn't even have this divide between us. And again, that's why we have product, UX design and dev here today.

[00:21:05] I don't know if you've ever Googled "how do you integrate UX and agile," but the fact that there's millions of results here says that we have not made it easy. If we had made it easy, we wouldn't be having people talk at conferences about how to do it. We wouldn't be having people writing articles. We wouldn't have all of these problems of how do you get these teams working together. So, have we made it easy yet? I don't think so.

[00:21:30] Then there's the scaling side, which is kind of left separately, because all these other frameworks are more focused on a single team. How does a single team work? But it's almost as hard of a problem to scale this across a large organization. So we have scaling frameworks. We have SAFe. We have LeSS Huge, Nexus, DAD. They're mostly based around Scrum and how do you scale Scrum across an organization. But if you ever read them, it's basically, we're going to just cross out the word waterfall and write agile and then say done, because we're not going to change any of our processes. We're not going to change anything. We're locking in our scope up front. We're doing big upfront planning. And we're just going to call it agile, because somebody wants to tick a box to say they're agile. These aren't actual agile frameworks.

[00:22:15] And again, if you're looking to really empower and scale cross-functional teams, when you Google it... I just love Jeff Gothelf. He wrote the book about Lean UX. He got sick of so many people asking him, how do you integrate Lean UX into SAFe? Because it's in there. They have a big chart and they've written Lean UX. He's like, it doesn't work. They're two completely different concepts. So again, we have this scaling, but it doesn't work. It's not easy, because we haven't figured out how to get a process that works for everybody. Have we made it easy? No, we haven't.

[00:22:54] But just to go back to SAFe, why is it so popular? Because it's something people can take off the shelf and do. There's two things people are looking at in management. They're looking at your business outcomes: where are we in the market? How can we get better? How can we beat the competition? How can we get more market share? How can we increase profits? And that's where they want to focus their time. The other side is, how do we operate our company in order to achieve these goals? And they don't want to spend as much time there, because it's more important to be focusing externally than internally. So they just go, okay, process, who's doing it? SAFe. Okay, let's do that. Or LeSS, or Scrum at Scale, or something else. Let's just copy that. Paste. Done. Okay, that problem's solved. Let's move on to what I want to focus on. So that's why I'm saying process is good, because it helps companies. No company can go and reinvent everything from scratch. It would just take too long, and be too slow, and too distracting from the real business goals.

The Zero Blockers framework

[00:23:53] So we have to solve all of these problems, process, structure, alignment, governance, funding, scaling, in a single way that works across from idea until satisfied customers. And that's what I've been working on for the last few years. But I haven't been doing it myself. I would say standing on the shoulders of giants, because we've been running UXDX for 10 years now. And I would go to Katherine: I've been researching something, I don't know how to fix a problem, can you find a company that have solved this and get them to talk at UXDX? Because what we've done is we've looked at literally a thousand, we have over a thousand talks, and we've tried to pull out what are the common threads and how are people solving all of these problems, and trying to put that into a single framework. So we literally have hundreds of case studies that you can read through. These are all talks from previous UXDX events.

[00:24:45] And what we have is, you've probably seen this symbol on our website. The idea behind this: you might have heard of dual-track agile, where you have design and development sprints in parallel. But my problem is that's still designers are over here and developers are over here. So we want a function or a process that highlights that there is no separation in a truly cross-functional team. Designers are helping out with dev, devs are helping out in research, designers are moving around. You need that ability to move around in a true cross-functional team. You need to develop your T-shaped skills. All of that kind of stuff.

[00:25:22] Then when it comes to structure, looking at things, there's a lot in domain-driven design or Team Topologies where they talk about value streams. So you break down a product into multiple value streams. The blue teams would be your designers, your researchers, your developers building the products, and then you need a layer above them who are looking at the consistency of the product. They're looking at the product vision, the product strategy, making sure that all the teams are moving in a single alignment. Not telling them exactly what to do, but giving them the boundaries in which they can work within.

[00:25:55] That's the same with alignment. So that team, that product team, is the one defining the values and principles, the product strategy. They're the ones defining the objectives for all of the teams. They're even defining the boundaries for the teams and who's on them. And they're the ones hiring people. So all of these things, once you put all those together, you get high-quality decisions, because people understand the context of the situation they're working within.

[00:26:19] For funding, you fund the value streams based on your current strategy, your market differentiation, and the cognitive load of whatever they're working on. So there's a framework for figuring out how to fund, how many people need to be on each team. And then once you have funding for value streams, then you allocate people to the value streams. There's a framework around governance and how you track, to make sure, because there is that assumption of the outcomes. Amazon have a great example in their book Working Backwards, where they thought that they had really good outcomes, but they kept missing their impact. They weren't working. So they just kept iterating with their outcomes until they found the correlation between the outcomes teams had and the business impacts they were expecting.

[00:27:03] And then for scaling, there's five different team types. You need internal teams, like a platform team or a design system, or even your finance and legal teams. You need enabling teams, because one of the problems is in cross-functional teams, people are dispersed. So you need functional enabling teams, and their job is to train and coach people and bring the quality bar of the skill sets up across the organization. And then an ecosystem team, giving that business strategy for everybody.

[00:27:30] Our goal: I don't think that motivation is the right way to go at all. The goal of this framework is to try and make it easier for people to adopt it. So it's free. It's at docs.zeroblockers.com. If anybody wants to read it, go ahead. If anybody wants to ask me any questions, I'm around for the next few days. But I'm just going to wrap up quickly. KPIs win every time. You have to think, does this person really care about what I'm asking? We need to make it as easy as possible, because it's not easy. These things aren't easy. We're asking for a lot of change when we ask for these things. And then process isn't the problem. Bad process is. So thank you very much. I think we have time for some questions.

Q&A

[00:28:20] Host: Thank you, Rory. That's exactly how we kick things off here on the first day of UXDX. Anyone have any questions? Can we flip to the AhaSlides with the questions? So everybody, if you can be typing in... Oh, okay. We need to make sure that we go to the question slide a little bit quicker from now. Can we go back to the question slide, please? Yeah. So can you just type in some questions. But do you have a question while we're waiting? I felt very seen during your talk. I was one of those people on the front lines constantly arguing, trying to make my argument sharper. Using Fogg's framework, the idea of making it simple. Can you think of one, I think everyone got the principles, can you think of one great example of something that you made easier, and then you saw people suddenly, it didn't matter how motivated they were?

[00:29:09] Rory: Trying to think of one. With products it's kind of easier than with change. I'll think of one and I'll come back to you. But with products it's easier. It's back to what I said, that example with Miro. They launched all these products. They've done the research. They validated that people wanted it. But when they released it, they were getting poor adoption. So what they then started doing is, okay, it's obscurely hidden in some weird navigation flow and it's not very obvious. So they just kept iterating and making it obvious in the right flow, where people were, and they just saw adoption grow from there. So it's easy to get people to use things if it's easy.

[00:29:47] Host: Exactly. All right. So we've got our first questions in. How do you deal with resistance within the company when it comes to change? I feel like you outlined that, but it's a great moment to recap.

[00:29:57] Rory: Yeah, resistance always is going to happen. One of the things in that framework is I say you have to have a vision. We all talk about having a product vision, but we also need to have a process vision, because otherwise it's going to become a battle of opinions. I think that cross-functional is the best way to do it. You think that the functional structure is the best way to do it. Whichever of us has the more political power is going to win. We need to take it away from that battle of opinions to being something like we do with product. So the process vision that we have is zero blocking dependencies from idea to satisfied customer, and it's basically stolen from Toyota's single-piece flow. And the idea is that means every new initiative that we try to suggest for change, because you don't go from zero to 100 overnight on this, you iterate slowly, and you say, is it getting us closer to our vision of having one team have zero blocking dependencies? So it means they can release software from idea to satisfied customers without talking to anybody else. Zero blocking dependencies.

[00:30:57] Host: I think your brand name Zero Blockers is catching on. It's already crept up to the top of the chart. So have you seen some real-world success yet with the Zero Blockers framework?

[00:31:06] Rory: As it is right now, we're still very early days. What I would say is yes, because if you look at those case studies, the Zero Blockers framework, it's not something new. It's not something that we've invented. I've taken it from other people who are doing this in production in companies around the world. So we've basically just seen the patterns that companies are using and written down those patterns. So it's not a completely theoretical framework. It's based on real-life things. Now, has anybody taken Zero Blockers? No, because we haven't released all of our training courses that are coming out soon. But we're hoping over the next few months and years that we will be starting to push that and actually work with companies to implement this as a single process.

[00:31:53] Host: And this can also be a call to arms. So if we don't have those real-world case studies yet as it's getting rolled out, you know who to talk to, and maybe you'll be on the stage at some point. Let's do one last fast one. Can you give any examples of outcome-driven KPIs?

[00:32:06] Rory: This would be, if you've got a team that's responsible for search, it's your search-to-book ratio or your look-to-search. So you're looking at what's the action that people are taking in your part of the product, and what can you do to improve that? Can you reduce the churn in a particular flow? Can you increase the conversion rate? So it's very specific to whatever value stream that you're working on. And then you would need to see, so a value stream being maybe the search part, maybe it's the order flow, maybe it's the fulfillment part, maybe it's the post-success. Looking at those KPIs.

[00:32:41] Host: Wonderful. All right, another round of applause for Rory. Thank you very much.