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

Rory Madden at UXDX EMEA. Video: https://youtu.be/WlG-xFfYV2Q

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.

Why UXDX exists: the process is the problem, not the people

[00:00:08] Thanks everyone. I'm just going to set a quick scene for why we put together UXDX and what we're hoping to achieve over the next few days. At UXDX, where it all started from was really working in software. My background, I've had 20 years working in software development. I had worked for big enterprises and then thought, I can do this, so I went into startups, realized that waterfall way of working doesn't quite work very well if you're just thinking you know what the customer wants. After that I went back to enterprise and realized they're still ignoring all the research, they're still ignoring all of the upfront design and iteration, and we're seeing that in the outcomes.

[00:00:47] You're seeing back in 2009 it was at 33%, and it's actually creeping lower and lower whenever they test. Ronny Kohavi here, pictured, he is the ultimate guru in the world for A/B testing, and he's just seeing it sliding in terms of effectiveness. That's a bit because things are getting harder. We're not just replacing old paper processes, so it's a bit more difficult because we're always having to create something new. That's where it's difficult, because customers, you can't just ask them, or expect that if I write up front, this is how they'll behave.

[00:01:24] But I really feel that our processes are the problem. It's nothing to do with the people. It's not because we've got really bad people and that's why our effectiveness rate is so low. I really believe it's how we're working, or not working together, that is the problem, and that's why we created UXDX. It's to get multiple disciplines together to figure out how to work better.

[00:01:46] The typical one would be you might have the business and IT divide. The business come up with the idea, management sign it off, and then it is all just focused about are we on time, on budget, are we on time, on budget. The challenge there is that you end up not agile. You're doing waterfall the whole way through until you get to development and you do a few sprints, so then you're super agile. But because it's all about time and cost, any changes or anything you learn from customers, that's scope creep and that's going to cause problems, so let's just ignore that and let's just keep going with our original plan, because we have to be on time, we have to be on budget.

[00:02:28] Instead of looking at develop as where we need to get agile, we need to look at the end to end. We need to be thinking about where ideas are coming from right through until we have satisfied customers. We need to make this short and iterative so that it can move around quickly. You can go from idea to validated solution as quickly as possible.

[00:02:53] This is why we have product, UX, design and dev at this conference, because this process involves everybody. You do that upfront research to try to figure out what do you actually need. You do design to iterate on different prototypes and validate different ideas, or evaluate and kick out the ones that don't work. You can see here that they're overlapping phases, because it's not quite clear, there's a little bit of boundaries, and that's why we wanted a cross-functional conference for people to work together. So we have product, UX, design and dev.

My goal: making change happen when you get back to the office

[00:03:32] Now I'm going to jump into my talk. That was just to give you a little bit of a background about why we are hosting the conference and what we're trying to achieve. My goal is to actually make change happen. A lot of conferences, you're going to leave here and you're going to hear some amazing talks over the next few days and you're going to be super pumped, you're going to be inspired. You're going to go back to your office and you go, there's this brilliant new methodology that I just learned about, it's doing wonders in JP Morgan Chase and all these things, let's implement it. And you're going to just get a little bit of pushback, and a week or two later your motivation will be down, and then you've got your deadlines so you focus on that.

[00:04:17] My goal is to try to figure out, and this is our whole thing that we're doing at UXDX, how can we get to that next step? How do we get to the point where we're actually implementing all these changes? My talk is, is everybody's on board? Because I'm sure when you go back and you say how amazing it is, you're going to hear people go, yeah, that sounds great, let's do it. But it still doesn't happen. As I said, we have this problem, we have very low effectiveness rates.

[00:04:46] I'm going to do an example now as I go through this, and I'm just going to imagine that you're pitching to your boss. Let's say you've just come back and you're like, we need to do discovery as part of our development process, because it's going to give us better products, better ROI. It's going to be less rework, because when we deliver it to customers it's going to be what they actually want instead of us having to go back and do V2, V3. It's going to be better team buy-in, because it's going to be more empowering for the team, so everybody's going to get pumped. This sounds amazing.

[00:05:17] Who thinks it's a good idea in the room? Show of hands. Yep, most people, I think. So everybody, when back in your office, is going to think it's a great idea as well. How many people have tried this already? Okay, a good few hands. How many have actually implemented it? A lot less hands.

[00:05:41] So, great, when should we start? We just need to get this project finished right now. We're halfway through, let's just finish this one and then we'll look at that. Or let's put a business case together, because it's going to cost a little bit of money, so let's put a business case together and we'll pitch it. But I'm really on board, I think it's a brilliant idea and I'll help you put the business case together. But right now isn't good, because the economy and the market's a little bit down, so let's just keep our heads down because we don't want to rock the boat too much. We'll park it for now, but we will come back to it, I promise. Any responses like that when you've tried to pitch an idea? Yeah.

"They don't get it" and the seat at the table

[00:06:24] But the thing is, they don't get it. It's not your fault, it's okay. They don't get it, they don't understand. We need to convince them of the value. You'll hear lots of, how do I convince somebody of the value of UX, the value of design, the value of DevOps, the value of discovery, the value of... There's so much stuff out there of how to convince people of the value, because it's not us, it's them. They don't understand the value and that's why we're not getting it across.

[00:06:53] Back in 2003, I just looked at things like, let's see what's the return on investment for usability. We were pitching it in 2003, in 2006, in 2014, in 2015, and every year. That's been going on for 20 plus years. Have we convinced people of the value yet? No, because it's not the right way to go. What's the definition of insanity? Trying the same thing over and over and thinking that we'll end up with a different outcome.

[00:07:26] So I know, we don't need to convince them, we need to get somebody in there. We need a seat at the table, because they're never going to understand, because they don't come from our background. If we get a seat at the table it'll be sorted. We just need somebody with the right background. In 2014 we've been saying this, we need somebody at the seat at the table. 2018, designers finally have a seat at the table. Designers, stop asking for a seat at the table. Design lost its seat at the table.

[00:08:03] What happened here is everyone's pitching about the value of the process, but we need to be thinking about the value of the business. It's not that people don't get it, it's that their incentives are not aligned.

Does your boss really care? KPIs and scope creep

[00:08:20] So why is this happening? What I want to do for the second half of this is try to figure out, put yourself on the other side of the table now and imagine somebody's coming to you asking for this. The challenge we have to do is figure out, does your boss really care? We all know from research, don't ask somebody, do you like my new product? I just built this, I have a lot emotionally invested in this, please don't hurt my feelings. If you ask somebody in research what they think of something, of course they're going to say brilliant, it's amazing, your baby's beautiful. But do they really care?

[00:09:01] What are the KPIs that your manager is being tracked on? I've spoken to so many different companies, all of the super agile ones, or claiming to be super agile, it's still: did I deliver on time and on budget? Am I predictable? If I tell you we're going to deliver, we're going to deliver. That is by far the most common. And then there's the utilization of resources, so how much percentage of time are people billing to capex projects versus opex admin work.

[00:09:35] You're coming along and you're saying, I want to talk to customers during these phases, all the way from new idea, but you're getting down into the detailed analysis and design. You're saying, rather than having this big plan up here in our business case, rather than sticking with that, I want to keep talking to customers the whole way through, because I want to really understand, is this what we're trying to achieve, or is this what you need, is this solving your problem? Actually, I want to keep doing it. I don't want to just do it up front, I need to be doing it the whole way through, because things change, we learn new information. And there's a name for that, and it's called scope creep. Your manager is hearing that going, I'm being tasked for predictability and you want to keep changing things over and over and over again. I'll never get anything delivered.

[00:10:30] Immediately this is coming up with the culture eats strategy for breakfast. You've probably already heard that, but the strategy sounds great: let's build these amazing products our customers love. Who's not going to be on board for that? But the culture is on time, on budget, predictable, and that's going to win out every single time, because KPIs drive your culture. It's why I'm wearing it as my t-shirt. The point here is, if your KPIs are around on time and on budget, no matter what you try to do, anything around continuous discovery, talking to customers, that's scope creep and that's going to make it hard to be on time and on budget and predictable.

[00:11:20] It's difficult to get a man to understand something when his salary depends on not understanding it. It's just a brilliant quote, but that's the gist of it. People aren't bad, they're not actively against it, but they're trying to reconcile this: okay, that's a great idea, but it's going to cause me a lot of pain and a lot of political problems, and I'm going to have to try to solve this. What we need to do is we need to start with KPIs. That's been my lesson that I've learned, because I've gone the wrong way of trying to do the motivation, sell the value, do all of that, and you're just hitting your head against a brick wall.

Software is not an assembly line

[00:12:02] So many companies think of software as an assembly line, because that's how the most successful companies were structured in the 20th century. That's where our divisions came from, marketing, sales, operations. It came from the concept of an assembly line: somebody does something, hands it to the next person, hands it to the next person. You have a bit of design when you're coming up with the new ideas about what will we do, and then you've got the assembly line of, once that's done, it goes step by step. We approve it, we create our business case, we do our big design, we sign it off, we then do our development, release it, in a one-way flow. You don't want work going back.

[00:12:44] But it only makes sense if we're building something repeatedly. It's perfect, assembly lines are amazing in manufacturing where you're just churning out the same product time after time after time. But in software we have copy and paste, so we're never building the same thing twice. We're always trying to figure out something, so our design phase is right up until the customer tells us that they actually want it, and then we can do some DevOps stuff like an automated CI/CD pipeline to get that code into customers' hands. That's our assembly line. But all of the steps up to that point, actually that's design, and design is messy, design is squiggly lines, design is all of that dead ends and trying things and restarting.

[00:13:31] Imagine that we get to the point, so I'm going to skip ahead, you've got KPIs, everybody's rowing in the same direction, we want outcomes over outputs. I've talked to a lot of companies again where they say, oh yeah, we are, we're outcomes over outputs, we're definitely there. But then when you look at it and you dig a little bit deeper, it's still, oh well, obviously we have to be predictable, we can't lose face, we can't lose that. If somebody says something and they're the ones paying for it, so we have the business will fund the project and then we have to be predictable, because we're always just getting attacked for how slow and how expensive we are.

What we're really asking of the boss

[00:14:13] But let's say we're there. Let's go again, let's pitch it again. We want to do discovery. It's going to be great for our products, great for our customers, great for everybody, great for the team. What are we really asking? We're asking for an upfront process that we do, but what are we really asking? Let's just do it like a little back and forth.

[00:14:38] We want to do an upfront research phase before a project starts, so we make sure that we're building the right thing. Well, actually the business do that before their business case. They do research beforehand, so are we not just doubling up there on the research that they're doing? Well, actually our phase is a little bit different, because we do generative research to understand the pain points, and then we do evaluative research to validate those needs. So we're going a lot deeper into it than maybe the high level that the business would be doing.

[00:15:14] But that's sounding awful time consuming if you're going into that deep level of research and all that. How much time is this going to take? And what happens if we get halfway through and we just keep hitting dead ends and we find out it's not working? What happens to all that spend? We can do it fairly quickly. It's a little bit vague, people get here around how quickly can we do this research. And no, it's great if customers don't like it, that's great, it's a winning thing. But it just comes back to, okay, how much is this going to cost me and what's the ROI? That's where the boss is thinking. They're thinking, okay, I'm going to need to pitch this, it's going to cost money, what's the ROI, how am I going to sell this to my peers and my managers?

[00:16:07] What your boss just heard during that conversation is: I'm not a big fan of this upfront approval of signing off the scope, because that locks us in too much, so I don't really like that. The business case signing off, well, that's making it even stricter, because that's getting into a lower level of detail, so I really don't like that one. And we're going to keep adding scope here as we build. So just forget about time and cost, and we'll be efficient, we promise. Scout's honor, we'll do our best to be as efficient as possible.

[00:16:44] This is a really difficult position for your manager to be in, who's just heard this, because what they're thinking is: I need to go talk to the development leads or department leads in different areas and say, okay, we're going to do this new thing, you can't just give us a full package solution. I need to sell it to them. Then I need to go to the senior exec about the whole funding model and the business case. I need to sell it to them. Then I need to go to PMO-headed delivery, because their whole structure is around time and cost management and project reporting, so I need to sell it to them. I need to convince architecture and engineering, instead of doing these big upfront architecture layouts and designs, that we need it to be a lot more... so I need to sell it to them.

[00:17:29] That's a lot of political capital that you're asking somebody to go around the business and try to sell this idea to every single one of them. And I've tried this. You cannot do that. I have literally gone around offices trying to convince people, and there's always a few people who just flat out disagree. They don't believe that that approach is the right way. They think the current way of working is the best way.

[00:17:59] Leaving aside the politics, what we're asking is, what is the process? Okay, we want to do upfront discovery, but now we have to change it, because if you're going to be doing these continuous changes we need developers to be on board, we need designers to be, we need to be working together, not handoffs. How do we structure the teams? Because we don't want two teams working on the same thing, but if they're all iterating in their own areas, how do we make sure they don't accidentally creep into each other's areas? How do we align on strategy? Because if the teams are iterating and they're a bit more empowered to figure it out, well, we have our business and product strategy, how do we make sure that they don't just start going off in weird tangents?

[00:18:39] How much should we fund each team? Projects are easy. We put together a project, we say it's going to cost this much, we're going to get this ROI, so I know how many people I can put on that team. But it gets a little bit more awkward when we're saying, well, we don't quite know what we're going to build, but we're going to do the best we can. How do we govern them? Time and cost is a great way of governance, because are we on time, are we on cost, but what do we do now? What's our new governance model? And how do we scale this across the business? Because, yeah, okay, we might have a test team where we just loosen the rules a little bit around this test team just to get them up and running, but what do we do when we need to scale this across all the teams, because of all those problems that I said of, well, maybe now we've got duplication, teams are doing the same thing.

[00:19:25] What your boss just heard was, you're giving me a lot more work to do and I'm already super busy. Even though we think we've gone with the best pitch ever, we're going to build better products, we're going to improve ROI, we're going to make customers happy, we're going to make the teams happier, this is a slam dunk, this is amazing, when the boss is hearing and trying to figure out what they need to do to get this embedded, it's really, really hard.

The Fogg model: start with KPIs, then make it easy

[00:19:54] There's a great model from a professor in Stanford, BJ Fogg, and he's come up with this model for how to get behavioral changes adopted. You have one axis which is motivation. If you're super motivated, you don't need to make something easy to do, which is the second axis. If you're super motivated, and this is typically what would happen when a company's about to go under, they literally have no other option, this is everybody jump on this, let's give it a shot and hopefully it'll work. But it's very, very rare. If a company isn't literally about to go under, it's very rare to get that high motivation.

[00:20:37] So while we think we're high motivation and we've talked about the process that we want to do, in reality we're down at the bottom left, because your manager doesn't have the right KPIs, so they're not actually super motivated to do this because it will conflict with their KPIs, and it's really hard for them to do it because they have to convince everybody across the business. Lesson one, we'll start with the KPIs. Lesson two is make it easy.

[00:21:08] Now, this isn't easy. It's not an easy problem. If it was, we'd all be doing it. This is where I go a little bit against the orthodoxy in agile circles of people and interaction over process. We don't ask people to reinvent programming languages from first principles. We have layers of abstraction to make it easier. We have machine language where people are doing ones and zeros, we have assembly language, which is barely any more complex than that, and we go all the way up to high-level languages because it makes it easier to do things. Yes, you're constrained. You can do a hell of a lot more the lower you go down, but you can move a hell of a lot faster the higher you go up. You're trading constraints for speed.

Frameworks help, but our frameworks have gaps

[00:22:01] This is where I actually am a big fan of frameworks, because frameworks are the exact same thing. We don't want people to have to figure out all of those process, structure, alignment, funding, governance, all of those things themselves. They don't have time, they don't have capacity to do that. So I think frameworks are actually a great way to help people get started, but the problem is our frameworks have gaps.

[00:22:29] We have product development frameworks, but they don't talk about the upfront ideation. They don't talk about where the ideas come from. We have Scrum, waterfall, Kanban, and they start with the developers because they were created by developers. That's the start of, we have our scope, what's the best way of actually building that out. We also have problem solving frameworks, so we have things like design thinking, Lean UX, Double Diamond, all those, and they're solving that ideation problem up front. They're coming up with, where do we come up with ideas, how do we evaluate those ideas. And we have scaling frameworks, so we have things like SAFe and LeSS and Nexus and all these scaling frameworks, but they're a little bit separate from the other three.

[00:23:21] We have these three different things that we need to get together, and essentially we're giving people Lego blocks and we're saying, you try to figure out how. So we have Double Diamond and we have Scrum and we have SAFe, and yeah, there you go, that should be enough to scale this across your organization. But if you look online, it's like, how do you integrate UX and agile? There's hundreds of thousands of people giving their ideas, because it's not straightforward. Nobody has... everybody's focused still on their silo and they're going, okay, well, this is how we solve the ideation problem, but they're not doing the cross-functional sharing of how do we actually get the idea into dev, and how devs get into the ideation, and that mixture.

[00:24:12] Maybe scaling frameworks will be easier, but like SAFe, I don't know if anybody has tried SAFe. I think it should be more like waterfall described rather than agile. It's institutionalizing waterfall, but with SAFe, with agile words. There's a mountain of people just complaining about how strict and how it's basically just locking in waterfall, which is a great way, if you're selling a framework, call it agile, don't change any processes, easy to adopt. But it doesn't make it easy, because we're still giving people these Lego blocks. As you can see, people are having difficulty trying to figure out how to put them together. I don't know if you're working in companies where they're trying, and you'll definitely be feeling the pain of trying to do that, merging them together.

Six areas to solve, and 700 case studies to draw on

[00:25:02] To solve this problem we need to look end to end, from coming up with the idea until we have satisfied customers, and it needs to solve these six areas. It needs to solve process: how do teams actually work on the ground? How do we structure those teams? How do we get alignment with our business and product and company strategy? How do we do governance? How do we fund these teams? And how do we scale? This is not easy.

[00:25:31] But at UXDX we've been blessed, because over the last nine years we have been doing case studies on this stage and in New York and in all of our community events around the world. I've pulled together about 700 different case studies and we've pulled out the insights from all of those different companies, because I didn't want to come up with something theoretical that hasn't been proven in the real world. If you go to zeroblockers.com you can scroll through all of these hundreds of case studies, and they're all grouped into different areas of solving different ones of these problems. What we had the beauty of doing there is, because there's so much duplication in different areas, we were able to see the patterns that worked. That's what we've done, we've pulled out all of those patterns so that people can learn from the best practices.

[00:26:17] Our idea is that we need to just make it easy for people to adopt this, so we're going super opinionated, which is the opposite of agile, of ignore process. But I don't think process is the problem. Bad process is the problem. Process is just basically tracking what people are doing, and that could be a lot of cross-functional interaction or it could be complete silos. So the process in itself isn't a problem, but a process that stops people from talking, or is trying to be an assembly line in a design problem, that's a problem.

Zero Blockers: one team from idea to satisfied customers

[00:26:56] Zero Blockers is what we've published from our UXDX research, and it covers the end to end. The idea, why it's called Zero Blockers, is because we need zero blocking dependencies from idea to satisfied customers. What do I mean by a blocking dependency? One team should own this and they should not need to talk to anybody else in the organization to go from idea until they're releasing that software to customers. Because every time you have a handoff to somebody else in the organization, for approvals, for okay, well, we've built it, now we need to hand it over to the operations team to release it, or we need to do any kind of internal handover, once you have dependencies you have lack of accountability. It's not my fault, I did my job, I built it, I did exactly what it was asked to do, but it got delayed because of these guys. So you have to have one team owning end to end.

[00:27:55] We have a process that describes how the team's building the products. At that product level they're doing the research, design, development iteratively together. What I mean by that, I don't know if you've heard of pair programming before. It's the concept of two people sitting at one computer, and the idea behind it is it's not the typing speed of developers that is showing their productivity, it's how quickly they can think through and solve conceptual problems. So two people having a chat will actually produce less bugs, have higher quality code, that kind of thing.

[00:28:32] Then one team said, well, what do we do when we have a crisis? We get everybody in the same room together and we basically pair, but as a whole team. So why don't we try that on our software team? Woody Zuill tested out this idea he calls teaming, and they found that yes, they were slower than individuals working separately, but they were much faster because they had so much less rework. They didn't have a bug in production for two years, because with that many eyes and that quick of a turnaround, if your designer is in the same room as your developers, is in the same room as your researchers, and they're going, okay, what did you mean by this, and have instant answers to what they need, they were able to solve things at a higher quality than otherwise.

[00:29:18] How do we structure it? I've talked about the teams. We call these stream teams, where you've got your researchers, your designers, your developers. We call them streams because there's a concept of value stream modeling that was popularized by Toyota, but you essentially look at how the customer journey is for your product and you just find your logical boundaries. It's never perfect, but you can figure out where you can start slicing your products, and then you give teams ownership of that little sliver. But it's a vertical slice of the product, so they own the catalog. That could be a team who are responsible for sourcing new products and getting them up online. You could have a search team who are just responsible for getting all the filters and the data right for the searching and all that kind of stuff.

[00:30:06] But we need another team above them to get that alignment. You have the structure of, you can slice up these stream teams, but we also need some layer of managerial oversight to make sure that we have alignment with the strategy. Now, this is where it can get a little bit difficult. It's not telling the teams what to do, but telling them the strategy and the areas to play, and what they can do and what they can't. You're setting the guardrails, but you're not telling the teams what to do.

[00:30:38] The next thing on alignment is that you need to have four elements to make sure that teams can make high quality decisions, because the biggest fear for managers is that we give these teams control and then they do stupid things. I use the example of middle seats on an airline. I worked in two airlines, two very different segments, Ryanair and Aer Lingus. Ryanair decided people hate the middle seat, so we'll put them there, and if we put everybody in the middle they'll pay to get out of it. Whereas Aer Lingus, which is a value carrier, said we'll do a product where you can buy an empty middle seat, so you just pay a little bit extra and we'll guarantee the middle seat is empty so you have more arm room. Now, if you did those options, it's the same problem, people don't like the middle seat and don't like being squashed, but if you swapped those in the companies it would hurt the brand in both ways.

[00:31:31] So you need to make sure people are doing the right things. You need shared values and principles. You need to understand what is it about this company and what do we believe in, are we low cost, are we value. You need the strategic context, so what's our product's vision, where are we going, what's our next three-year strategy. You need the incentives aligned, so this is our KPIs. You need to make sure that your KPIs are team-based KPIs instead of individual ones when you're working in a cross-functional team. And you do need experience, because you are going to have a very different outcome if you have a team of juniors versus a team of senior people, because they just have more world experience and they know a bit better. That's how you can get alignment with high quality decisions.

Funding, governance, scaling, and the summary

[00:32:15] With funding, after we do our slicing into value streams, not every value stream is equal, so we're not going to fund a team, we're going to fund those value streams. We're going to decide, we'll fund this value stream a little bit less because our strategy doesn't care about that right now, our strategy cares over here, we're in growth mode. Or actually, you know what, we're moving now into cost reduction, so we're going to shift our funding into different areas. You fund the value streams and then you decide, okay, how many value streams can a maximum team size... Again, I actually think the team size of two is the perfect size. Anything over that, you start giving more challenges, but a lot of people go up to eight. If you want to look into the two, there's Basecamp and Linear have really good case studies on how they do teams of two.

[00:33:07] Then governance. There's four ways you can track people's performance: the hours they put in, the stuff they produce, the users, how the users use the things they produce, and then the business impact, did we make money, did we save cost. The business cares about the money and cost, but it's too slow to be reactive, so we need to govern on the usage of our products. Not did we produce a feature, but how much are customers using those features, and is it achieving what we had hoped to achieve?

[00:33:40] And then finally, we have scaling. I introduced already the stream teams and the product teams, but we also need internal products, because you can't put everybody on a team. You need your legal and finance, but you also need things like a design system, you need a technical platform, because you don't want every stream team to have to repeat all of these same things over and over. You want to pull out that repetitious stuff and put it into an internal product. And then we have enabling teams. These are your most senior functional experts, and they basically float around the organization looking for stream teams that have problems. They're saying, okay, well, this team needs some coaching in this area, this team needs some experience here, so they come up with training courses. They don't do the work, so it's not a center of excellence, but they go and they train people on how they can do the work.

[00:34:32] So our goal is, I'm not going to try to improve motivation, because I think that's the wrong approach, but the idea behind putting a framework like Zero Blockers together that tackles every single one of those problems I talked about is to try and make it easier to do. I'm not saying it's super easy to do, but it's hopefully easy enough to get across the line of actually making change happen.

[00:34:54] To summarize: KPIs win every time, and when time and cost are your KPIs you're never going to be successful. We need to make it easy. We're asking people to do a lot of changes, so we need to make it easy. And then process is not the problem, bad process is. If we can figure out what good process looks like and institute that, or implement that, then that will make things better. Thank you very much.