Roadblocks to Change: Legacy Systems and Technical Debt | Digital CxO Summit

Hello, and thank you for joining me today for, uh, our discussion on roadblocks to change, specifically focused on legacy systems and technical debt. I'm Michelle Donovan, and I am the analytics director at Best Friends Animal Society, and I'm really excited to share some, uh, insights and, and knowledge with you all today. So the first thing that I wanna do is make sure that we're on the same page about what is a legacy system and what is technical debt.

So for today, we're gonna talk about legacy system in terms of an outdated hardware or software that's still in use, but makes it difficult or impossible to interact with newer systems. And then technical debt is going to be the cost incurred when problems aren't fixed that will cause problems in the future. So in other words, legacy systems are one type of technical debt, and it's the type of technical debt that we're gonna be focusing on today.

So what I'd like all of you in the audience to do right now is to think about a project that fits these parameters and what legacy system is causing you technical debt, probably all of them. And if you don't already have a list, then now would be a good time to start writing it, because you'll probably get some ideas along the way of, of different things that you might be able to address in this way. So if you have legacy systems, then you're probably starting with some baggage.

So one of the things that comes across often is imperfect predecessors. So whoever came before you might have been beloved reviled. Either way they weren't perfect and you're gonna come along and try and make some change.

And, uh, this isn't, this process isn't about changing or exerting who you are or comforting people about what you're going to do differently and why you're going to do it. Really, you wanna understand what the predecessors were doing and where people stood so that you know where the teams are. Um, another starting place that you might be struggling with a little bit is turnover, or even your team growing too quickly.

This can lead to unreasonable expectations. So maybe if there's been a lot of turnover, they're thinking, oh, we hired the right person. They're gonna fix all of our problems, they're gonna be our savior.

And maybe eventually you can be, but you might also need a lot more time and effort and investment than that, what they're expecting. So you wanna make sure and, and keep that in mind that, um, regardless of of what direction you're going in, that can be a, a struggle that you're, you're bringing with you into this process. Also, antiquated or absent processes.

So this is, that's how we've always done it kind of work. And that can be problematic in its own right that you're, that you might be working against. Oftentimes we're dealing with not enough documentation, whatever it is, there's probably never enough documentation.

Nobody likes to do it, but it's something that we do have to navigate. And then of course, the legacy system itself. So if these systems are old enough, you might have a very small group of people who have the credentials or the skillset or the interest even in managing or maintaining that system.

These legacy systems sometimes get forgotten. And so they might have lapsed maintenance or security patches. And we also know that legacy systems are expensive to maintain, but they're even more expensive to replace.

And so it feels a little bit like a known in situation because there is an investment needed, but it's not new and exciting. It's really just to maintain the status quo or to create something new that still only provides very similar functionality than what you had before. So you're starting out with all of this and what's the problem?

It's technical debt, technical debt everywhere. Um, the more you get, the harder it seems to dig out and it can be very demoralizing for your team. The other problem that we see is oftentimes there's a disconnect between what the IT teams see behind the scenes and what the rest of the organization sees.

And you don't always want to complain about or educate about all of the nuance. That's why they have an IT team is so that they get to deal with all of that, or that's why they have a data team, or that's why they have whatever team you are, you are in is so that you can handle all of that. But there are some challenges that come along with that.

So this cute little cartoon talks about shows how there's a, a house that's falling apart and somebody that says, I just don't understand why we can't add a new window. So you see this a lot when you hear stakeholders and business units saying, you've always made it work for me before, um, or somebody in your team promised me that we, I was gonna get this window and all I'm asking for is a little window. Uh, one of my favorites is I should just be simple.

It's just a little window, right? It's just something small. And, um, one of my least favorites is, um, but the c e o, the, the c E O definitely wants it or would hypothetically want a window in this exact situation.

So really having to balance understanding everything that's happening in the background, but not necessarily being able to, to share that with everyone. So when you have all of this happening but still need to make a change, we are going to help come up with a buy-in strategy. We're gonna talk about relationship building, and then we're gonna talk about how we execute.

And you already have the technical expertise, so we're not gonna talk about the technical aspects of these changes. We're gonna focus on strategy and soft skills that are gonna get you to execution. I want you to remember everything is communication.

You cannot not communicate. So when you're listening, that is communicating when what you don't say will communicate a message to some people, whether or not you want it to and what you say is important, but how you say it is really going to be the difference between whether or not you get that buy-in and that relationship building opportunity. So starting from the bottom, we're gonna listen and we're gonna start from the grassroots.

I really like to start with my team. It's who I have the easiest access to. It's who feels like they have the, the most access to me.

I wanna learn about their goals. I wanna learn about how they think I can help them achieve their goals. And are those realistic?

I wanna learn also about the formal and informal networks. Who are your mavens? Who are the people that everybody goes to for advice or if they change their mind about something every, you know, not everybody, but a lot of people are gonna follow suit.

And can you find people who are already on board with your vision and who are willing and able to help? So in the US our culture is very individualistic and we're very privacy oriented, so we don't always ask the questions that we could or should, but if you can be truly interested in and curious about someone else's role or their experience, you can ask all the questions you want. It's flattering.

And incidentally, research shows that the more questions you ask contrary to popular belief, it also builds liking. So you're building a relationship and you're getting knowledge. So you start with the team, you understand what the, what the ground source truth is from your team's perspective.

Then you move out to business users or end users and figure out what their needs are, what their goals are, how they think you can help achieve their goals, what are those formal and informal networks and who's already on board. And then you move on to leadership because you have all of this other information. They don't have to tell you about the whole universe, but they can look more holistically and tell you, here's some broader goals that we're trying to achieve.

This is how you specifically fit into their goals. Here's their formal and informal networks, and then again, who's already on board and willing to help. So once you have all of that figured out, um, you make a plan.

This is not the final plan, this is an initial plan, then there's entirely too many variables. So I'm not gonna tell you specifically about how to build your plan. I'm just gonna talk about a few general, uh, concepts that you wanna make sure are included in your plan.

And the first one is think about all the goals that are out there. Start with all of them. You've collected all of this information, you know what people want and need, and then think about what you can realistically achieve.

Can you actually deliver those things? And then realistically, what you need to achieve that goal. One thing I'd like to remember is that when you're trying to impress some people or you're trying to get people bought in or you're trying to help people, you might want to over promise, but we wanna keep realistic because I can either disappoint you now with how much it's going to cost or what I can actually do, or I can can disappoint you after we've already invested time and money and energy into this project.

So just a little, uh, a little information about what is realistic. The three-legged stool is something that I go back to all the time. What is a realistic scope, time and money.

So when you look at that list of technical debt, hopefully you've been compiling or you already have created, I want you to think about which one of these three is the biggest barrier to buy-in. Is it that the scope is too big, not big enough? Is it that there's, it's gonna take too much time to achieve that level of scope or the the time maybe doesn't feel like it's worth it to the people who are going to be implementing and the money.

Um, money's gonna be an issue for every type of organization all the time, right? We always wanna save as much money as we possibly can. So then after you have that plan, start shopping it to leadership.

Remember, this is an initial plan. You have all of these things taken into consideration. And for me, I like to start with leadership to the extent possible.

That doesn't mean that I don't go to my team about what my plan is or I don't go to select stakeholders about what the plan is going to be. But once I feel really confident in like, this is a really good starting point, I do wanna go to leadership. Because if you don't have leadership buy-in, the rest of it is gonna crumble, especially for a a legacy system tech get type of project because it is not fun, it's not exciting, and you do need wide support in order to get it done.

So, um, buy-in then is where you start getting some resistance and there's a lot of different types of resistance. So this is also the, the phase, this buy-in phase. When you start getting this resistance, the first thing that I start thinking about is what you wanted me to fix all the things, and here's how we do it, this is how we start.

But you have to think about the other side of that coin as well. Change is hard. You might not be thinking about, you know, the the newest shiniest innovation.

This is something that is, that is foundational to your organization or that is in a, in a back corner somewhere that people aren't even aware of or don't even realize needs to be given some love. So it's gonna be hard for them just as if it was a bigger innovation. Um, these system, these these pieces of resistance are going to be combated with relationship building.

And that doesn't mean that we're being duplicitous or manipulative, it's that we truly need to build relationships with stakeholders. That's leaders, peers, team members, business units. You don't have to get a hundred percent buy-in to be successful.

So this isn't about saying like, yep, there's lots of barriers. So I guess we should just give up. This is about reframing what you need to do, not technically, but what you need to do relationship wise to move the needle on the projects that really need to be addressed.

So I'm gonna start with an example. Um, maybe you are in a local government agency. There's a homegrown legacy software system with thousands of embedded crystal reports and it's six versions old.

When they embedded it, they didn't think about having to upgrade the crystal reports along the way. In the meantime, because this system is very, very old, we'll say decades old, you now have a new parallel software system that is slowly taking on the responsibilities of that legacy software system. And that new system is using S S R S for reporting.

You have no documentation because it wasn't expected 20 years ago that you would need it 20 years later. So you don't have a good view of the architecture, you don't have a catalog, you don't have business rules for why things weren't selected in these thousands of reports. It's all about reverse engineering to figure out what's happening in each and every one of them.

You also have no dedicated data engineers on staff. You have one person who's really capable of troubleshooting these reports in this legacy system and your business units and business users are finding conflicting data in different reports and that some business critical reports are not rendering appropriately. So I want you to again, look at the projects that you've listed with your tech debt and think about which projects are facing, which type of resistance are it.

Does this give you some ideas of other types of projects that may be considered technical debt, um, that, that you really wanna think about addressing? So you have the problem, what's the plan that you're gonna come up with? So for this example, the plan is we're gonna audit all the reports.

We're gonna set and set the ones that haven't been used in 13 or more months. We're gonna prioritize by the volume of use, who, how many, which reports are used the most over the last 13 months. Identify simple conversions, purchase a conversion tool, hire a data engineer to do all of those things that the conversion tool can't do or whatever cleanup the conversion tool leaves behind.

You are gonna document all the things this time around and you're only gonna convert as is. And if there's an existing backlog item that already was documented that needed to be addressed, uh, you're not gonna do bells and whistles, you're not gonna do all the improvements that come up during testing, but you are gonna rely on stakeholders to test. And then at some point you have decided that you're gonna retire the crystal report server.

So here comes the, uh, the roadblocks. The first one, uncertainty. You're gonna get this from all levels of the organization.

Uh, in fact all of these roadblocks, you're gonna see different types of responses to the different types of roadblocks depending on where they stand in in the organization. So from your own team, you need to recognize that they've been working with this for a long time. So fixing tech debt is uncertain to them.

They don't know what's coming, they don't know what that means for them. So one of those is we don't even know how big the, the problem is yet. Maybe we know how many reports there are, but we don't really know how difficult it's going to be to address these problems.

What if we break something else in the process? Does anyone on our team actually have the time and ability to do this? So these are maybe not questions that don't have answers, but they're questions that people are going to have and they're legitimate concerns because people don't know yet it's new, so they can't know that it's never been done before.

The next layer of, of people that will have uncertainty is like maybe they're uncertain about your skill and ability to execute on this. And so you might get some pushback about that from stakeholders. Um, you might get some pushback about like, I already know how to do what, I'm gonna do this new thing.

I don't know how it's gonna work. And so I'm just gonna go ahead and hold onto what I have right now. And then this idea about like what if you decommission or sunset something that I actually ended up needing in the end, what if I don't get it?

What if I don't get it back? What if I don't realize I needed it and I end up needing it? Again, legitimate questions that need to be answered, but they're going to come up and they're going to be, because you know all of the ins and outs, you are gonna know those answers and they're not.

So patience is, is key in this. And then how long will it take from leadership? Leadership's gonna wanna know like, how long am I making these sacrifices and, and not moving onto shiny, fancy new things in the process?

And then is it really that important because this is a huge project, do we actually have to do this? So when you get this kind of feedback, you can move on to um, how you, how you combat that. The first thing is transparency.

You're gonna need to promise change. You have to sell it carefully that there will be benefits, but that there's also realistically gonna be some challenges along the way. You wanna keep expectations reasonable and that's transparency is one of the best way to to do it.

If you don't know something, you can say that you don't know something, it's okay. Um, it also helps you to maintain your personal credibility. You're not over promising when you say something's gonna happen.

They can be certain that it's gonna happen. Communication constantly, clearly frequently, you wanna fill the void so that the rumor mill isn't your competitor. If you don't answer a question, if you leave something up in the air, others will fill that space.

They will let their imaginations go wild. And you don't wanna have to fight against rumors that that started because you just didn't communicate enough. And then you wanna clearly explain the processes.

So that's how we're going through this conversion, but also providing some resources for in the end, if you're not familiar with the new reporting system or new style or how we're going to do that, provide all of that knowledge and information so that it reduces the uncertainty and so it reduces the anxiety with the change. The next one is to break habits. Um, some feedback you might be getting from your team is, uh, that's not how we do it.

We have a habit of doing it a different way from stakeholders. I'm just gonna keep doing it the way that I've always done it. This workaround is just fine for me.

Um, why do I have to learn something new? I'm good with what I have right now. And leadership might be thinking, we've never had to do this before.

This isn't a thing, this isn't a process. This is brand new to us. Why can't we just keep doing it the way that we've always done it?

The longer that a group has been doing something a certain way, the longer it's gonna take to undo that habit of, you know, just going directly to this place or directly to that place or knowing that they need to assign this task because the pro the system isn't doing it the way that ideally it would be doing it. So when you come across this kind of resistance, you're gonna look at, uh, understanding that people will revert back to autopilot. It's natural, it's expected, and it doesn't mean that we go back to the status quo.

It just means that you recognize that it is not the end of the world and it's not personal. Don't take it personally when people forget or they're in a crunch and so they have to go back and do it the way that they did it before start. Small, small changes can have a big impact.

If you think about turning the, the a boat one degree difference and letting it go on a one degree difference course, it ends up in a very different place than where it started. And that's especially the technical debt. That tends to be a really strong way to move the needle.

And then at some point, to maintain the boat metaphor, you do have to burn the boats. You have to make sure that there is no escape route. That you are making sure that we are all certain that this is the direction we're going in.

And so we are going to decommission, we are going to make them unavailable sooner rather than later. You have to commit so strongly that there is not a way to turn back, but their roadblock is the investment, right? And this isn't always just money, it's also tying in people's bandwidth that are being invested.

So your team might be saying, I can't believe they're gonna hire someone to do this instead of the millions of other things that need to be done. Can't we just start from scratch? I don't know how many times in projects we've said, I just wanna blow up the system and start over.

Your stakeholders might be saying things like, I don't have time to help you test. I'm not gonna invest that time. That's your job.

You figure out how to do it, or you're not converting all of them. We're investing all of this and we're not getting everything that we started with to, to end up with. Leadership's gonna be saying, I'm investing an entire tool and an f t e into this dying system, or we can't develop any new reports during this conversion.

And then another one is an investment of social capital from leadership. You are going to need them to back this and to help burn those both and to help persuade at higher levels of the organization. And so you're asking them to invest their social capital in what's typically a pretty boring project when you get that kind of the, uh, pushback.

Again, you wanna rely on transparency. What is the cost of a change? There is going to be a cost and then only proceed it when it can actually be afforded.

Tech debt needs to be dealt with eventually. Oftentimes, sometimes it doesn't need to be dealt with. Sometimes there is some other way.

And if you're showing the true costs and the organization is just not willing to absorb those costs, knowing that upfront can stop and ill faded change from going into effect. Similarly, if you are 20, 30, 70% of the way into this project and you see it's just not working, it's just there's a different better way. You have to be willing to kill an underperforming initiative.

You can't keep throwing good money after bad people's time after something that's not gonna come out in the end. You can also look at the flip side and communicate the cost of the status quo. You're gonna continue to be getting poor quality reporting.

You're gonna continue to be struggling and having workarounds if we keep it the way that it is. And then an investment of power and responsibility to others on the team can sometimes turn this around as well. When you recognize that individuals can feel invested in the outcome of this project, that can also help you to overcome this concern about what the investment is.

Okay, the next roadblock risk. Your team will be saying things like, what if we break something else in the process? What if we can't figure out the mess of a system that was left behind?

Stakeholders will be saying things like, well, mission critical work be impacted negatively. And leadership will be asking, could an error in this project land us in the news for all the wrong reasons? And you start hearing that kind of pushback.

You wanna lean in the risk taking, actually this is important, this is how we innovate, and this can be a really good, uh, example of what we're gonna do on more fun projects is you lean into that. You can actually make this an opportunity as a catalyst for more change while you're going through the change. Your goal is not to stabilize during the change, it's to create stability afterwards.

So while you're in this shakeup opportunity, is there something else that you could kind of sneak in or that could be part of this, this bigger change. You wanna address people's fears. They have legitimate fears and they are concerned that it will affect them negatively.

And it might, but you can talk about how we alleviate risk and how we mitigate risk. Um, and, and again, it comes down to communicating and, and being open and understanding that it's a natural part of the process. And again, when you start small, you can keep the risks small as well.

The next roadblock that we come across is culture. Um, you'll hear things from your team like, I'm gonna be blamed if something goes wrong because that's the culture that maybe existed already. I'm gonna be out of a job after this project.

How can I work in this environment when I'm really finishing something so that I no longer have a place here? Um, you know, you can also just stay out of it, right? Like I, I don't, I don't feel like being part of this.

I'm gonna let them go ahead and, and deal with that monstrosity over there from stakeholders you hear, why should I support your efforts with what's in it for me? Um, or even territoriality. They're not gonna touch my reports.

I'm good with mine. I don't need you to do anything else. And then leadership, my especially on something like this where it's is more technical heavy, the those technical debt items, they don't need me to get involved in this.

I'm good. They can just, they can deal with that over there. It also keeps me from having to give up any of my social capital.

When you hear these, what you're gonna see is that the, the best path forward is a supportive work environment Change may make employees feel threatened, insecure or vulnerable and, uh, and become inhibited. So you wanna create that supportive work environment. As soon as people start shutting down, it's the exact opposite of what you want and need for a successful organization change.

You're gonna need to put your people skills to work, make people understand that they are needed, they belong, and that you are gonna support them moving forward. And you're gonna have to lead by example. Really put your money where your mouth is, you know, not just the talk, but also walking the walk and provide a sense of purpose.

Uh, remember why we're doing this in the first place. We're doing it not just for this one system, we're doing it so the organization works better so that maybe our working environment in having to deal with these legacy, legacy systems is improved. And then finally, bring in executive support where you can let them know that you absolutely need them.

Anytime one of these changes, even if it's something that feels like it's background, it can become a showstopper if you don't have explicit support from executives. Okay, our next roadblock to change is the capacity for change. This is really about resilience.

So if your team is already at capacity, they've already absorbed as many changes as they can. There's been turnover, there's new leadership, there's all these other new projects, you might be hearing things from them, like, we're already working on a million other things. Stakeholders might be saying things like, don't they realize I've got my own things that I wanna work on?

And from leadership you might hear, this just had been a good time. And this one always irks me because it's never a good time. There's never a time when you're just like, okay, we're just gonna coast now.

No, every organization I've ever seen or worked in is say it. There is a knowledge and ex expectation that we're always gonna be doing new innovative things. Sometimes that new innovation is as small as tech debt, but there's always improvements that are needing to be, to be made to remain relevant.

So again, start with small goals. Small goals are gonna be easier to absorb. If you think about a saturated sponge, just a little bit more is gonna be much better than a huge, a huge change.

Short range objectives, you're not thinking about transitioning thousands of reports you can think about. We're just gonna start with these from this one department. These, you know, these four reports that have the biggest impact.

The next one is you still wanna keep it organization-wide to the extent possible. They deliver solutions that are common across everybody and are sustainable long-term department specific customizations and, and projects. They add business value.

The department level deployments are faster, they face fewer hurdles. So it kind of fits into the small goals, these short range objectives, but it lacks the resources and general appeal that helps to maintain them so that that can become problematic as well. And then of course, be agile.

You might start out thinking that you're gonna do one thing, but you can do it incrementally, right? And you can shift and adjust once you understand, okay, this group is ready for change and this group isn't ready for change, or this is a change that can be absorbed. The last roadblock that we see is about metrics.

And this is really important to capture those metrics even in the throes of everything that comes at you with an organizational change, it feels administrative, it feels like there's not a lot of value add and teams are already complaining about documentation. This isn't gonna make them feel any better. But we have to collect this information at the front in order to understand where we continue to have issues and what other resources we need in the future and how successful we are.

So you're gonna hear things from your team, like, I'm too busy trying to get this effort launched. I can't work on this too. Can't somebody else do this?

Other organ or other parts of the organization might be saying, I already helped test, I don't wanna help maintain it too. Don't be asking me for, for things along the way. And even leadership might look at this and say, metrics are fine if we have time to do it, but you can do that later.

And the reality is you can't do it later. You don't know what your baseline is if you haven't collected data before you launch. So that's, that's really important how you do that.

You can focus on what you care about most. Um, those are the things that you're, what are the goals that you've tried to achieve with this? What are other people's goals that you've tried to achieve?

And how can you measure those things? And then again, transparency, make it available to everyone. Even if you're not doing well, it can demonstrate to them why you need their support.

You can say, you can show that we're not getting the resources that we need or that this has gotten off to a slow start, but we made the right choice for these different reasons. And remember, the data is useless if it's not driving change. So you really do, again, going back to number one, you wanna focus on what you actually care about.

Don't collect data just to collect data, just to say that you have something. You wanna make sure that when you, when you have it, it's, it's gonna be ready to go. So after all of these roadblocks, you've navigated all of them.

Now it's time to figure out when to execute. And this is when you need to think about your own roadblocks in overcoming challenges to change. This is your time to drink your own champagne.

So if you're facing your own uncertainty about, oh, when is it time to actually pull the trigger? 80% consensus, not 100%, even 80% of the information, if you wait until you get a hundred percent consensus, you've missed the boat and you've invested too much time and effort into that part of the process, breaking your own habits, find out what that crutch is and remove it. Be disciplined enough to know what it is and know how and when to, to remove that crutch.

When you're thinking about the investment that you're gonna have to put into this, you can scale it and make sure that it's a reasonable investment. So scale down, not scaling up and really thinking about what is, what is the right way to take advantage of this opportunity? You're thinking about the risk, that's, that's part of this.

And then you gotta think about what's the risk of not executing? What is the organizational culture? This is the slowest thing to change.

This is something that one person cannot change, but you can come back to your own, your own part of the organization and the culture that you want to be responsible for and how you want to do that. So come back to your why, why are you doing this? So even if there are cultural barriers that are going to stop you, remember, you know, if you have a strong enough purpose for why you're doing this, it's going to help you get through to the next stage.

And then your own change capacity. Like, how can I actually do this? Am I, am I ready?

Am I prepared to take on something larger? So again, remember to, to start small. And then finally metrics.

And you've gotta lead the way if you want other people to use data to come to you and say, okay, this is why we need the next, uh, change to be made. This is the new system that we're going to implement. Uh, you've gotta show them how to do that.

A lot of people in a lot of organizations try to be data savvy and data-driven, and they aren't there yet, but you can help them to show what what's happening. So now I want you to take a look at your tech debt list that you've been compiling and think about where are you being your own barrier to change, which changes already have leadership buy-in, at least conceptually, maybe you're not there on the nitty gritty of it, but where do you think that there's, there's not a, a challenge to get them to buy into this? And are there any roadblocks that will actually kill the project?

And can you overcome them? Can you be prepared for that barrier so that you can still, you can still move it forward? And if you can't be realistic about that and, and why you can or can't.

So in some, we talked about a buy-in strategy, we talked about relationship building and execution. And now I wanna open it up for any questions that you might have.