Managing Change: Implementing The UXDX Model

Rory Madden at UXDX Community: Dublin. Video: https://youtu.be/LqptqzWTubs

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.

Implementing change

[00:00:09] What I'm going to talk about today is implementing change. It's going to touch on a lot of what Aiden talked about earlier, because a lot of companies have that aspiration to have that culture. As intangible as it is, there are very obvious ways, when you look at a company's culture, to tell if it's the type of culture that you want, a generative type of culture, or if it's not. In those more difficult ones it's harder to make change happen. So I'm going to talk through a case study of trying to implement change and some of the challenges that were faced.

[00:00:48] I'm going to start with my ivory tower [?], because that's probably the best place to start. As I talked about at the start, working in UXDX we've done a lot of research into what we feel are the best practices for breaking down that barrier between the business and IT, and getting the customer involved in the product delivery cycle. When I started with Aer Lingus, I joined as a mobile program lead, and I thought, okay, my biggest challenge is going to be breaking down this business-IT divide. What I wanted to do was get the product people and UX designers all working together with our BAs, our developers, our QA, etc. That's where I thought the main challenge was going to be.

The delivery challenges

[00:01:30] But what we found was there were actually a lot of delivery challenges. I've drawn a very simple technology stack. I'm not sure how many people are technical in the audience; quick show of hands. Probably a third. For those who aren't very technical, this is a very simplified version, but you basically break down an IT stack into multiple layers. There's the UI layer, where the customers are interacting. You've got the services that give you a separation from your UI, so you can reuse the same logic on your mobile app and your website, etc. Then you've got a messaging bus that connects to all your back-end systems, like an e-commerce system or your data warehouse or other third-party systems.

[00:02:13] The challenge that we were facing was that when we were doing a project, you'd do the full stack, so everything would be touched. That's fine, because you have one team focusing on that. But the problem was we were never doing one project at a time. There were about 50-something projects going on at the same time. So what was happening was that everybody was trying to touch the same bit of code at the same time, and this meant we weren't able to go as quickly as we wanted to. Particularly from a UX perspective, when we're trying to enable the team to be doing experiments, testing things really quickly and getting things out: if I turn around to you and say that's a great idea, it's a great experiment, I think I can get it out in about four months' time, it's not really enabling the quick learning and turnaround time that's needed.

[00:03:03] The way I looked at it, there were six main constraints that were stopping us from releasing quickly. There are the obvious ones: the scope of what you're trying to do; the cost of it, since you can't go crazy on how much you're going to spend; and the resources, which is a crude way of saying the people to do the work. But there were two that I wanted to focus on, which were the time constraint and the environment constraint.

[00:03:23] With time, because we were touching the whole stack, there's only one version of your application in production in this architecture. That meant that whenever a project was going through that path to production, you had to try and figure out where your window was. Your window was when one project finished testing and the next project started testing. You were looking at these huge spreadsheets trying to figure out where the window was that you could squeeze in a bit of work that you wanted to deliver. And as you can see in this example, which is fairly accurate, the windows weren't very common.

[00:04:03] The next one was around the environment. The environment was built as a full stack again, based around the primary e-commerce platform of the company. That meant that whenever you wanted to work on something, you'd say, I think I'm going to get this live based on my window at this point, and they'd go, okay, then you need to be on stack B, because it's going to go live just before you. So you have to go onto that stack. But the problem then is that you're tied. If they get delayed, if anything happens, you're moving along with them, because you can no longer go ahead of them. You've just introduced another constraint.

[00:04:43] After trying to come around these things, I reset and took a step back, going, okay, my biggest challenge isn't going to be breaking down the business and IT divide. What I did was put on pause the change around that and said, okay, if I want to encourage that closer collaboration, I need to be able to say I can release quicker than four months. It just wasn't useful to keep working on that until we had fixed the delivery challenges.

Treating it as a technical problem

[00:05:14] The next section was looking at it as a technical problem, because these issues I've been describing have been solved. A lot of companies have figured out how to break down systems and how to create isolation, so that you don't have this spaghetti code, or everybody trying to touch the same thing. What we did was ask, okay, how can we make the release windows work better? If we make projects smaller, they won't have as long durations, so you'll have more windows between them, because if you shrink the duration, more gaps show up.

[00:05:48] We were talking about implementing a tax on long-running projects. The problem was, whenever we'd say we'll do all these releases, it became much more expensive. If I chop the project in two, I had to pay twice to release it to production, and that was seen as, okay, now you're just increasing the costs. So we said, let's put in a tax to cover the hidden costs. There are costs associated with big projects, like change requests, the carrying cost of software that you've built but haven't released that could be generating money for the company, and other costs of blocking, like merging, etc. But that was rejected, because it was seen as going to make us look more expensive, so we don't do that.

[00:06:29] Then we said, okay, let's look at the architecture. If we could start taking a domain-driven architecture approach, what we can do is isolate bits of code. Instead of having every project touching everything, if we start implementing different domains, you could have one project touching domain A, another project touching domain C, and they're completely independent. They don't need to interact with each other. A lot of work has been done on that and designs have come up, but that's going to take years to do, so we're not able to solve that straight away.

[00:07:01] Then we said, okay, that environment problem that I talked about, where if I lock into an environment and it gets delayed, I'm caught by that as well. How about we swap our way of looking at things? All of our UI-facing stuff sits on our production application, and anything where we're changing our e-commerce platform is a separate environment. That will become the production application at some point, but at the moment all I'm concerned about is making sure that when it changes, my services don't need to change, and the interaction with the website doesn't need to change. But again, that was rejected, because it's a lot of hard work.

[00:07:40] And for the release windows, finally, we said, okay, let's shrink the path to production. If we can't change the project size, let's shrink how long it takes to get it out. So we went to the teams and said, here's a challenge for you: it's taking a long time; come back with the solutions that you have. Because the people closest to the problem are often the people who know the best ways of fixing it. They came up with lots of ideas and started working on it, but then it was overruled, because the structure internally was saying we can't have different ways of working in one team versus another team. Either the whole company agrees to shift to a new way of working, or everybody stays with the same way of working.

Taking logic to an emotional argument

[00:08:19] The way I picture this is I was taking logic to an emotional argument. I was trying to explain with logic: here are the problems, here are the solutions, let's do it. I thought logic was going to be enough to convince people, but emotion is what actually triggers people to change behavior. It's not logic. There are two main aims: you have to motivate people to do it, but then you have to make it easy for them to do it.

[00:08:46] So moving on from "it's a technical problem" to "it's a people problem." There's a guy in Stanford who has a behavioral model that says, basically, if you want to change behavior you need motivation. That's your logic, your data that shows this is a better way of working. But that alone isn't enough. You also need the ability. You need to make it easy for people to change if you want them to actually take on board something new.

[00:09:15] The way I looked at it was, okay, the triple constraint was the core thing here. This is probably more of a waterfall-type organization, where the triple constraint is budget, cost and scope, and you have to keep your quality constraint. The question I just kept asking was: what if an on-time, on-budget project does not deliver the expected benefits? Is that still a success? People were gradually coming over to, okay, it's not. But again, that's still the logic, the motivational side. It's not doing anything on ability.

[00:09:52] The question that kept coming back to me was, okay, teach us this agile process, and then we'll go and adopt this agile process across the whole company. Again, everybody has to do it or nobody does it. So I kept having the conversation: well, there is no one agile process. Agile is an evolution from waterfall, where as teams get more mature they can break down silos between teams and take on more responsibilities. It's showing that there are a lot of different variations of agile as you go along, and this would be my preference, where you have the business, IT, everybody working in cross-functional teams with a mission to solve. So this started some conversations: okay, maybe we can't go to this all or nothing. Maybe there is a need to have different processes in different teams, depending on the maturity of those teams.

Core beliefs and Conway's law

[00:10:45] But what really happened was it impacted people's core beliefs. What I have on the left is the traditional, Taylor's approach to management. He was the father of management science, and he came up with the concept that breaking companies into functions is the most efficient way of working. That's where you have your sales function, your marketing function, your IT function, your customer services, because in a low-change environment that is the most efficient way to structure a company. In the early 20th century it was a low-change environment; things weren't changing rapidly.

[00:11:29] The challenge is that when software development came along, we introduced a new paradigm that hadn't been seen before. We're never in a low-change environment; we're constantly changing. So if you want to optimize for responsiveness over cost efficiency, you actually have to do things almost the polar opposite of the way you've done them before. And if you've worked for 20 years in a particular way, it's quite jarring to hear or learn that this might not be the most optimal way of working.

[00:12:01] Realizing that there was this jarring nature for people, and people were going to push back against that, it was: how do we align management? Because there's only so much you can do bottom-up, getting the teams involved. You need to make sure there's top-down buy-in as well. So what we did was we got a vision for the organization that everybody could get behind. The vision was... sorry, I'm jumping ahead of myself.

[00:12:26] Conway's law. The challenge is, if you want to change a process, processes get locked in by the way the company is structured. There's a guy called Conway who coined a law that says any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. If you think about how your company works, between silos there often is a documentation handover, because that's the most efficient way for each person in the silo to make sure their area is constrained. They have entry criteria: I'll only take in work if you meet these conditions.

[00:13:02] So what happens is, if you have a functional structure, you end up in a waterfall process, because each of the functions will define strict entry criteria and exit criteria, and you'll have a document handover between each of the functions. If you want to go to a cross-functional team, you have to shift it on its axis, put in place cross-functional products, and have different representatives from across the organization. So we needed to get buy-in at a management level that we needed to make this shift from a traditional functional approach to a more product-structured approach.

Leadership, vision and a trial run

[00:13:41] In reading a lot about change management, there are two ways you can do change. There's the crisis, where people's survival anxiety overrules their learning anxiety. They go, okay, I have to do this even if it's scary, because otherwise I'm out of a job. Or there's leadership, where you try to increase their ability to learn, so that it's easier to learn than the scare of survival. We went down the leadership approach, and that's where this vision comes in.

[00:14:09] The vision from management was that we do want to go towards that responsive way of working. We want to be continuously optimizing towards a rapid and sustainable flow of value. It was really embedding that we want to move towards responsive instead of the cost-efficient approach. Now it's up to the teams to figure out how to do it.

[00:14:30] What we did in one of our teams was a trial run. Come back to that problem we had at the start: teams can't do things differently, because if I'm managing a function, the most efficient way of doing that is if everybody does it the same way, so I can move people in and out of jobs quickly. So we said, if we're shifting to this product structure, then the different teams are going to work in different ways depending on their own circumstances. So we did a trial run, and we said, look, what's the worst that can happen? Let's do three months of working in this new way, let's see what happens, let's measure any improvement that we get, and we'll take it from there. That was how we got management on board.

[00:15:12] To get the team on board, we asked, what's our process? We sat down with the team and said, okay, that's our vision, we want to get to this really responsive way of working. How does that work in practice? We came up with a very long process flow, but what happened was there was no separation between functions in this flow. It was actually one team working together. Communication was happening a lot, and a lot of the documentation disappeared.

[00:15:40] Then we said, okay, that's our ideal, that's our blue sky, but we're down here at the moment, so how do we get there? We started identifying the gaps and doing small experiments to figure out what the biggest problems we were facing were. Let's do something quick and small and figure out whether that works. Doing change management in the same way that you would do product development: small iterations, see what happens, learn from your mistakes, and move on.

Where we are now

[00:16:07] And that's where we are: happily ever after. Everything works, nothing went wrong, and it was a great success. The way I would describe it, and I copied this from a great illustration of different management structures: this one I think is apt, because for those people that we said let's do a trial run to, they're losing authority, they're losing control and power. In a lot of organizations, power is determined by how many people you have under your direct control. So if you say, let's shift from you being at the top here to you being at the side, more of an influencer rather than a direct manager, that's taking power away from people, and they're not going to like that. So there is a bit of tension. It's being worked through, but it does exist.

[00:17:01] Then on the team level, purpose and mastery are definitely coming along. We've identified the purpose and what the teams are trying to achieve. We've worked on both the purpose of how we work and the purpose of why we work, so the business objectives of what we're doing. Mastery is coming along through moving towards that new way of working, because there are a lot of new techniques people need in order to work closer and change how they're working. Relatedness is probably the one that still needs a bit of work. If you ask people what their team is, they will still say their function, but what we want is to get them to see the product as their team, versus the function.

[00:17:43] I'll finish by saying, if you are in this position where you're trying to influence change, it can feel like it's really slow going. It's best to keep track of some of the wins to keep motivation high, because it feels like you are battling against it all, but keep going. You'll get there in the end. Thank you very much.