Episode 68 Transcript

Brent Trimble: Today’s episode is a recording from a recent TSIA webinar that I did with my Kantata colleague, Melissa Korzun, who is our Vice President of Customer Experience Operations, and John Ragsdale, Distinguished Researcher, Vice President of Technology Ecosystems at TSIA. In a rapidly evolving technology landscape, technical debt has emerged as a silent saboteur within professional services organizations undermining productivity, customer experience, and financial processes. Technical debt refers to the cumulative consequences of using outdated or overly-customized technology – decisions that over time lead to higher costs, inefficiency, and reduced agility. In this webinar, we discuss the hidden costs associated with tech debt, break down how disconnected and legacy systems block predictable value delivery across the professional services life cycle. We also look at the common blind spots and bottlenecks that stand in the way of consistent success, as well as identifying costly issues that are impacting effective planning and execution across the professional services value chain. We hope you enjoy!

John Ragsdale: Well, thank you, Vanessa. Hello everyone, and welcome to today's webinar. I'm very excited because we're going to be talking about one of my favorite topics, technical debt. And we're going to particularly focus on the impact it's having on professional services and professional services automation. I first became really aware of technical debt about a year ago because I was having so many conversations with companies about transformation. And they seem to be really stalled in their transformation, often because they were clinging to old technology, outdated technology, homegrown technology, which is really all a part of technical debt. So at the end of last year, I completed a research study with our members on this topic. And I want to share some of the insights with you. The first question is, am I the only one that thinks this is an important issue? And one of the survey questions asked, in your opinion, how big of an impact is tech debt having on your organization? And people really understand this is an issue. A third said it was a moderate impact. About half of companies said a high impact or a very high impact. So this truly is something that business users and IT are understanding that is really impacting their ability to transform. And as we're going to talk about, embrace AI and all the cool new technologies that are coming out. And another survey question asked, what do you believe is the cause of technical debt? And as I mentioned, two of the biggest problems are homegrown or internally developed technology.

This is often a culture problem within technology firms that they think they can build it themselves.But technology is rapidly advancing so quickly that it is just, unless it is your core competency, it is really not possible to build what you can buy off the shelf.An overly customized technology, this is something I also hear all the time, that they have put so many custom fields and custom processes, they basically recreated the data model of all of the software platforms in the company.It makes them really hard to use, but it also makes them nearly impossible to integrate.And third on the list, outdated aging technology.And again, because AI is becoming so infused in all of the technology that's available today, if your technology is a few years old, it's unlikely that you're really getting all of the best of breed capabilities that are available.

So this is where I think the survey started getting really interesting, is when we ask in what ways do you think tech debt is impacting your company? And 88 % said a poor employee experience and it's impacting productivity. And three quarters said it's delivering a poor customer experience.So if you're impacting your employees, you're impacting your customers, ultimately this is going to have longer term impacts on your ability to renew, expand, sell, and it's gonna cause issues with annual recurring revenue. The prolonged quote to cash process, almost half of companies said that they're seeing that as well.And that's because of a lot of manual processes, still working on spreadsheets for a lot of key quoting and proposal generation.

So I think that you can understand now why tech debt is such a big issue, because it's really having big implications to your employees and to your customers and really your ability to generate revenue. So when I ask which systems within your organization have the most technical debt, I gave about a dozen different systems for them to rate on a scale of one being very low and five being very high. And interestingly, at the very top of the list is professional services automation or Psi, Psa. And it's tied with ERP billing systems, which tells you just how much tech debt is going on.And I think particularly with professional services automation, a lot of these legacy systems were implemented solely for these custom pay as you go, humongous three, six, nine month implementation projects.And professional services is really transforming and taking on a lot of new responsibilities, a lot of new revenue options.And I've got some of them highlighted here, moving to subscription services, value added services. These services that are consumed by points or credits or hours, and these are not three month projects. These are a week of business process improvement or a couple of hours to build a custom dashboard. And with a legacy PSA that's totally focused on these custom projects, it makes it really, really difficult to embrace some of these new paradigms.So when we think about tackling technical debt and professional services, 70 % of companies say tech debt is not getting the attention that it deserves within their organization.

Again, this can be some cultural issues, that it's always been that way that we run into so often. But particularly for PSA, I would say if your PSA implementation is three years old or more, you're probably not taking advantage of some of the new capabilities that are being introduced, especially around AI and Gen AI.So it's really time to take a look at what is available out there. If your PSA was primarily implemented for these big custom implementation projects, customization, integration projects, it's probably not flexible enough if you are considering moving to subscription value added fixed price services, which the majority of companies are today.So it may be a re - implementation, it may be a whole new purchase and implementation, but you've got to have the infrastructure to support all of these moves that professional services is making. So I keep talking about this, but AI and Gen AI is the hottest topic today. We've got our conference coming up very soon on this topic.And it's important that we find embedded capabilities in our applications. You simply can't build all of this yourself.You don't have the expertise, you don't have the resources.And finally, if you do bring in new technology, please don't make the mistake of re-implementing all of those major customizations you've made on your old system.You're just going to end up with a brand new system that's saddled with all of the problems that you had before.So you've got to think fresh, you've got to really try to stick to out of box as much as possible and rely on the implementation team from your technology provider to really steer you toward only making customizations that make sense.

So enough for me, I would like to bring our expert panelists into the conversation.And Melissa, I'd like to ask you a question first. Melissa Korzun is the VP of CX Operations at Kantata. You've been on our webinars before.So welcome back.And I want to ask, why does technical debt so often go unrecognized ? And if people aren't really thinking of the problem in those exact terms, what do you hear them talking about? And does this create enough urgency around the level of impact that it's really having on organizations ?

Melissa Korzun: Yeah, it's a great question. And it's one that we think about a lot at Kantata. And it's something that we really work with our customers a lot when we start to do implementations with them. And we've done a good bit of research in this area because it's near and dear to our heart. As you've shown, this has a huge impact on PSA organizations. And while we might not necessarily recognize technical debt in those terms, what we find is a lot of organizations feel the symptoms quite acutely, right? We see in our research, when we have Ps leaders, 81 % saying that customized solutions are costly and difficult to maintain. That is a core symptom of technical debt. And if you think about kind of the history of Psa platforms and when implementations would have happened five, 10, maybe more years ago, those solutions maybe weren't purpose-built for the type of professional services organization that we see today. A lot of those systems were really built around scope, schedule, budget, financial management of projects. And we're really starting to see Ps leaders wanting to look at different aspects of delivery. How are we performing in terms of resourcing at a really in-depth level? What does our forecast look like in the future? How is the health of our client? How is the adoption going during our implementations? And when the tools don't fit the bill, maybe rather than looking for a new solution that's purpose-built, companies might have decided to do some customizations and do some add-ons.

And they find that over time, that gets really hard to maintain.We're also seeing leaders saying that they just can't predict resource needs in advance, right, over 60 %.And when you think about a Ps organization where your resources are the biggest cost of your organization and the most valuable asset you have, not being able to predict the needs of that vital resource in your organization is huge.And often times is a symptom of some sort of technical debt.We forced a system to fit, or we just didn't have the capability, or maybe our data isn't structured in the right way that's giving us the visibility that we really need. And so we don't trust the data that's coming out of the system. Lack of visibility and to plan versus actual performance of our projects, right? So, that comes out in, instead of relying on the systems that you have in place to give you the analytics and insight into performance, you're exporting spreadsheets, you're cobbling things together outside of your systems. Again, a symptom of where technical debt is very costly to your organization.

And then, the last one that we have here is 56 % saying that they lack the data that they need to have that robust forecasting.These are all areas that when you're feeling those symptoms, you probably need to go back to your solutions that you have in place and say, are these really purpose-built and meeting our needs for today? Do we need to take a pause and fix the structures that we have in place to make sure that these tools are really helping us get the best out of our organization?

And there really is a sense of urgency around this because I think the market today, we really have to have an understanding of our business and we have to be able to make decisions that are going to protect the health of our business and also the health of our customers.And we don't wanna be inhibited by a solution that's not gonna help us get there.And to go back to what you said before, John, Ai is huge right now.And quite honestly, if our systems aren't optimized with the right data architectures in place and the right processes built into them, then it's really gonna inhibit the ability to move forward into AI solutions and get the value out of them.And instead, a lot of people are gonna find that they're gonna have to pause and address a whole lot of technical debt issues before they're gonna be able to make use of innovative technologies.

John Ragsdale: Yeah, great, great answer. I can understand how this tech debt is really impacting project margins, resource management, all of these key issues that PS executives care about. I wanna bring Brent into the conversation. Brent Trimble is the Vice President of Value Engineering at Kantata. Brent, that's a great title. I love that. But as I talked about earlier, it's also impacting the customers and they're feeling this as well. So I'd like to get from your perspective how you're seeing tech debt impact the services delivery lifecycle.

Brent Trimble: Absolutely. So universally in all types of professional services organizations, there's more or less a linear journey of revenue. And it starts, of course, with sales and new business, whether that's net new organic growth, that goes to sizing and pricing and resourcing. Can we put the right people at the right time on the right client to exceed their expectations? Then can we deliver on what we promised and exceed those expectations? And ultimately, can we accrue, build, capture, and recognize revenue? And then underpinning all this, do we have the data and the foresight to really drive the business? And this is universal, whether you're marketing services, management consulting, an embedded services organization in a technology firm. So we start typically with this notion of, can we trust data coming from our sales apparatus, our sales motion, our engine, whether that's managing directors, mining work from existing clients or net new pitches, the deal flow. And where we see the debt really start to manifest is this lack of synchronicity of data. Sometimes that's just a hindrance of the technology in place. Sometimes it's a way it was potentially implemented. Many times it's also hygienic, overlaid. And these folks, whether it's resource management or leaders saying, we just don't trust the pipeline.

We don't trust the dates, the flow, this pairing of demand on our services to supply. And blind spots ultimately can lead to really profound business challenges like overhiring, underhiring, having a gap in utilization, having a really extensive time to staff for clients. And technology really enables those insights or can hinder that. We then move to things like in the delivery, the all important, the work that is the reason professional services firms exist, delivering innovation, delivering work, deliverables, assets, technology to their clients, having that visibility into managing projects successfully, having a finger on the pulse of how the project is going as well as things like client and customer sentiment. And we see a lot of breakages here, latent sort of aging systems because professional services folks are so earnest, hardworking, very resourceful. They'll often patch together a pastiche of data sources from aging systems and just get on with it.But this is where you can see some real profound impacts to the business around client satisfaction, certainly erosion.And then ultimately getting to things like that all important AR, a revenue recognition function where the twain of don't meet, the notion of a statement of work, billing milestones, client expectations, ultimately the effort it took to run a successful project or client engagement.

And then ultimately what you're able to accrue. And sometimes this is maybe a non-compliant billing system that's just too painful to uproot.Many times it's the notion of the project governance, PS system, not being really aligned with that. And then things you get into endless cycles of spreadsheets and reconciliation. And so debt in this linear sort of journey of revenue ultimately acts as like a real tax on the whole organization and erodes productivity because, with all of our clients in the space we're in, and then I think technical debts, very valid topic for any kind of technology enabler, but in our business, the people really are the product.And when you're taxing that based on incomplete views of data, non-synchronous points of functionality, the whole business can suffer.

John Ragsdale: Well, we talked about a lot of impacts here and Melissa, I'm hoping you can drill just a little bit deeper in what ways this old outdated homegrown technology is really the culprit with these problems.

Melissa Korzun: Yeah, I think, in my experience, I think likely everybody has had a situation to where they've walked into a company or a new role. And as they've started to learn how things get done around here, they've encountered some sort of homegrown system that's been built, probably with a lot of really good intention and that was right for their business at the time. But ultimately what you end up finding is those homegrown systems require a lot of care and feeding to keep them alive. They're often kind of cobbled together solutions that rely on other technologies. And in my own experience, we've been in situations where we've had homegrown systems. They don't have nearly the capabilities of newer technologies that are coming out and they really handicap our ability as an organization to be successful in certain areas. And it's also very costly to continue to maintain those, just the skill expertise. There's often not someone whose role is it's kind of the responsibility to maintain those. And we end up pulling resources away from other critical work that they should be doing in order to kind of keep these things alive. And so as newer technologies become available as other systems that these homegrown tools rely upon because they're often kind of pulling in pieces from other parts of the organization start to evolve, you end up with these tools that really just no longer meet the need, right?

And so the ultimate cost and just lost productivity, caring and feeding of these systems, and quite honestly, not having the reliability or the quality control that a true best -in -class solution is gonna provide for you can just be significant.You know, I recall a situation at one point where we had a homegrown system that we were using at a company I was at for some financial management, and it didn't have some of the right quality control in place, it passed around in ownership, changes were sort of made on the fly, right? Because there's no well - developed life cycle for those types of things.And we ended up finding for over a year, there was a financial calculation that was wrong in the system, right ? And it was costly to our organization.And really, we should have been going with a much better purpose - built solution to achieve that.So I think there's just all kinds of examples across the board for where these homegrown systems can really lead us in the wrong ways and cost us a lot in terms of our organizations versus making the effort to really invest in the right tool that is gonna continue to innovate for you and bring new capabilities along with you as the technical landscape changes.

John Ragsdale: So Brent, do you have anything you wanna add on this topic of what are the costs to the business when technology makes it hard to really maintain that consistent performance across the customer life cycle?

Brent Trimble: Yeah, absolutely. I think for organizations who feel the pain and probably getting input from their talent as well as their clients, and just inherently know that the systems are ancient and creaky, or there needs to be a change made, there's usually, I think, you can break down costs into four or five different areas. One, of course, is that administrative load. And Melissa, I think, articulated this really well, just this note of pulling folks away from critical work to maintain systems or transact work in the space that the system doesn't provide. So the cost can be less tangible, but certainly quantifiable. In some cases, external third parties are required to maintain systems, and that's a very hard cost. That's a direct bottom-line hit to EBITDA. The next area of cost is really risk. And I think this is an area that a lot of firms need to probably at least take a glance at, aside from things like data compliance, and that's an important part of risk, but is there too much tied up in the operations of our business in a platform that may deprecate, that may not have a vibrant product roadmap? Maybe the vendor is turning their eye to another product in their platform, and this isn't going to get the attention.

And could this data go away ? Could you be forced to make a migration before a time and place of your choosing ? So that all represents risk, and that can be a real drain on a business.Think of having to maybe go through a replatforming that was not planned because a system was maybe being sunset.So those are the types of risk factors you could consider.Users, the cost on users can be everything from just that daily pain of transacting work that bubbles up to management, potentially even churn.We've had instances certainly in our firm where we talked to end users of different types of platforms who just raised their hand and said, I do not have the tools to do my job to exceed the KPIs set in front of me. Therefore, I choose to work elsewhere.

Does the platform hinder or enable the team ? Customers, certainly that's another cost area of technical debt. Does a platform enable you to interact with the client and give them a high degree of satisfaction in the experience of transacting work with you? And then ultimately the cost that's usually hardest to predict, but the most devastating to live through is this notion of insights and data that are incongruous and missing a blind spot, maybe a big hiring miss, a big swing in the type of talent required maybe six, nine, 12, 18 months down the road because you were forced to live in this sort of tyranny of spreadsheets and data that gave you that incomplete picture.

So I think you think about cost and we've all felt, this is costing more than it's worth or there's administrative load. You can break those down into those four or five areas. And typically without extensive analysis, come up with some real tangible, what if state scenarios around that and it illuminates that the true tax that debt has on the organization.

John Ragsdale: Brent, you had an amazing line earlier about people who have been in a company for a while. They've seen these systems get customized and added new components too. And you had a great line about this pastiche of systems and data that they've managed to pull together to get what they need. And I think it's sometimes in that situation, they're really in denial about the role that technology is at the root of problems it's easy to blame it on people and process. So what do you see as some of the keys to really adequately diagnosing the impact that tech debt is having on your organization?

Brent Trimble: That's a great question. And really starting with the orientation of the business, what are you in the business to solve on behalf of your clients? And we're talking in the context of professional services and then within that, what are those best in class outcomes you wanna drive? Velocity, satisfaction, are you in a high growth, low margin type of position or are you really focused on EBITDA and setting appropriate benchmarks for each of those five to 10 to 15 levers that are at our disposal in a professional services business pricing, rates, hiring cycles, whatever those are and then working back from there to establishing use cases for your talent from the individual contributor up to leadership and saying, do you have the tools at your disposal? What would a high velocity data in your hands able to transact work look like? And then do kind of a gap analysis against those use cases. You alluded to the fact that a lot of folks in professional services, they'll use these tools that they've picked up to do gap fill over the years and to fill kind of a gap and many times maybe their point solutions and suddenly you've got this constellation of systems that don't talk to each other. It's important I think for professional services businesses to take a hard look in inward as well because at our heart, we're very resourceful and we get monumental Herculean things done for clients.

Do we have to do that to close a week, a month, a quarter? Is there a better way? And then sometimes that involves taking away a little bit of control because there's comfort in being a solution provider of a cobbled together system and saying what kind of productivity could we give back to the enterprise if we're able to fulfill these use cases in a more streamlined? And then understanding, I think that answers a little bit to your question, John, but the role of technology versus the organization saying we want to achieve these 10 to 15 outcomes.Technology is going to help us enable that But we do have to change our practices to align to that.

John Ragsdale: Yeah. So Melissa, recognizing tech debt is one thing And I think people are getting there but getting organizational alignment required to actually attack the problem is another issue. So what do you see standing in the way of pushing past the status quo and this attitude of we've always done it that way?

Melissa Korzun: Yeah, I think there are a few things And I would reference back to some of what Brent just said, right? You can address technical debt for debt's sake, right? But that's going to be really hard to get anyone moving in the right direction. And I do think it comes back to what are the outcomes that you're trying to achieve as a company? And then being able to break that down and saying, okay, where are the barriers that we have in order to achieve that? And that's where you're going to start surfacing some of the challenges that are related that are coming from technical debt, right? So as you're looking at these outcomes and you're starting to say, oh, we can't achieve this outcome because we can achieve it, let's say, but it's very difficult or we're always late or running behind on it because we're relying on a lot of manual processes to keep these very hard to manage systems moving forward. Or we actually can't do a great job of measuring our performance around the outcomes that we're trying to achieve because we don't know or have our data structured in the right way or optimized in our systems to where we have the trust that that information is coming out in a way that's going to be relevant for us. Or even in some cases, we're asking questions and we have no clue how to get the answers out of the tools that we have in place. It's those sorts of things that I think are really important to get the organizational alignment and get people to have that aha moment to say, okay, we get now that the issue that we're having is related to the solutions that we have in place and aligning the resolution of that with the outcomes you're trying to achieve is going to get you much further along.

I think it's also really important to understand that just like financial debt, technical debt should be intentional, right? We make intentional decisions about debt on a day-to-day basis. I'm going to go and finance a car.That's an intentional decision that I'm making based on my situation, right? And so even when we're looking at technical debt, being really intentional about, this is the technical debt that we're willing to manage.This is the technical debt that needs to be prioritized and addressed, I think can also help with organizational alignment because if not, you run the risk of it being so big and so huge to try to manage it because you're trying to address everything that getting anything done can be very challenging because some of these things are very complex. They have a lot of tendrils that are reaching out and connecting into other systems, other processes, cross-functional departments, there's dependencies upstream and downstream.And so it can be very overwhelming if you go into an organization and say, we're going to rip out this entire critical thing and do just this massive changeover. Whereas if you say, this is an outcome we're organizationally aligned on, here are the areas that we're hindered on and this is the symptoms that we're seeing because of this technical debt, I think you're going to get a lot further with your organization that way than technical debt because we have a technical debt initiative to go out and find it all and fix it.

John Ragsdale: Yeah, this is something I've done a lot of projects on. I think getting an outside expert in is really helpful to avoid this boiling the ocean and coming up with the roadmap of what can we do today to make a difference and kind of do a crawl, walk, run approach. I know we've got a lot of questions from the audience, but I want to ask one final question to Brent. What are the keys to making an effective business case for change? Because we've got to have a budget, we've got to have resources to do this. I have to think that articulating the cost associated with technical debt is a key one, but that's not always easy to create. So could you talk about making that business case?

Brent Trimble: Yeah, absolutely. No, happy to. And this is obviously sort of near and dear to my heart because it's a practice I help run here at Kantata. But essentially when an organization, a services organization, usually reaches some form of tipping point and it could be size, its scope of work that they're engaged in. It could be geography, it could be a new transaction resulting in an acquisition, whatever the case might be. And everything's reached a point where they come to an agreement and say, there's some, we want to do business differently. And we think technology is part of that story. Definitely defining and articulating a problem statement first. Then looking at those outcomes, what do you want to drive? What would best look like? Really absent of the technology initially, just do we want to forecast more accurately, make the close process less painful, gain more margin on our project, price more effectively, staff with higher velocity, whatever those are, list those and index, why is a change in technology relevant to those outcomes? Then a cost benefit analysis is really looking at those use cases, looking in the gaps in the current technology, certainly looking at the technology that you're evaluating. And then against each of those use cases, quantifying outcomes. And there's, we do pro formas with clients who are looking at everything from shrinking time to staff, to improving EBITDA, certainly utilization is always kind of an overlay there, improving revenue per consultant, whatever those metrics are, and then be very modest and realistic about the timeline of achieving those goals.

Typically, then you can come up with a very relevant and realistic ROI analysis spread out over that journey.Select the technology, understand why, hold them accountable, and then present and create an implementation plan that is about the technology, but also about the business changes that you're going to transact while you're in that stage of evolution.

John Ragsdale: Well, Melissa and Brent, I thank you both for this conversation. You've shared a lot of insights with me and with our listeners. And Vanessa, I know we've got a lot of Q&A from the audience. Do you want to fit in a few?

Vanessa Lucero(Moderator): Yes, let's go ahead and do that. But I do just want to remind everybody, even though we only have a few minutes left, please go ahead and submit your question. And even if we aren't able to answer that question here live, we will make sure to follow up with you.So our first question comes from Nate.And they say, there's always going to be a lot of complaining about the technology people need to use. How do you separate grousing over the way a platform behaves from legitimate concerns about a platform that might be feeding technical debt?

Brent Trimble: I could take that one if you'd like. And I think what the question is alluding to is this notion of, typically we see this in services orgs where there's individual contributors, consultants who are using the platform, because it's important to note in the services world, in PSA, 90 to 95 % of all employees would utilize a system. And you contrast that with something like maybe a Gl, ERP, or even a CRM, fewer, a lower percentage of the total employee base would use those systems. So a lot of that comes down to sometimes things like UI, preference with a previous platform, maybe their experience and unfamiliarity with a system in place. But I think it goes back to really enabling, reorienting, engaging, and then driving some understanding to the user and the employee as to what the outcomes the enterprise is trying to drive and where they fit into that. And then peel that back and have some understanding around why the process is in place, their role in enabling that process and completing that and what the technology is there to do. And often when they get a broader picture of those goals and objectives and those outcomes, things like the technology that's been selected, particularly if it's a newer rollout and adoption is still ongoing, can be mitigated.

If it truly is a system that really hinders and not helps, that can be a great opportunity for them to articulate using a simple framework that we've discussed on what is it about this? Where are these gaps? And is it really not giving you the tools to transact your job and your work? And that can be a really good area of elimination. Maybe there's something that was overlooked there.

Vanessa Lucero(Moderator): All right, thank you for that, Brent.And our next question comes from Summer.And they're saying, we have goals this year around integrating AI into our workflows. How does the ability or inability to adapt to emerging needs like that play into the technical debt conversation? And how do we overcome limitations and find the right ways to adapt?

Melissa Korzun: Yeah, I can take that one. I think, first of all, kudos for having goals around and really thinking about what AI looks like in our workflows. And I think it's important to remember what AI is, right? And AI requires a body of knowledge in order to be able to function, right? Whether we're talking about large language models or generative AI, the AI is using your information in order to create efficiency into your workflows. And so if it's not being fed good quality information, then the ability of AI to produce good results for you is going to be very hindered. And so I think that addressing technical debt is one of the most important things that any company can be doing right now in order to prepare themselves to take advantage of the AI capabilities that are out there.

In terms of overcoming limitations, I think I would just go back and reference a lot of the things that we've talked about today, right? I think the first thing is being really honest and figuring out where the technical debt is in your organization. And so starting to think through where do we have homegrown systems? Where do we have complex customizations that we've put in place? Do we have all of our critical data available in systems that is gonna be accessible to these AI capabilities that are out there, right?

Spreadsheets that are hidden away on personal computers and laptops are not gonna be optimized to be used as a part of this model.Thinking through the way that your organization gets work done.Are they getting their work done in the right tools and systems that are gonna allow them to take advantage of these new capabilities that are out there? Thinking through what questions can we not answer throughout our organization because we don't have the structures in place. All of those are gonna be ways to help you kind of unearth where the technical debt is that you have in your organization that ultimately you can start to think about how to address so that you can get the best possible solutions out of these innovative technologies that will be coming out. And again, I'll just say, I think it's really important that when you make the list, you really have to start to prioritize it and figure out what are the things that we're gonna address? How do we crawl, walk, run, as John said, into this? But yeah, I think it starts now so that you're ready for that.