HS057: Technical Debt

In this podcast episode, Johna and I discuss the concept of technical debt. We provide different definitions of technical debt, with me focusing on the inability to switch solutions easily and Johna emphasizing the trade-off between immediate speed and long-term efficiency. We give examples of technical debt, such as outdated systems and insecure infrastructure, and discuss strategies to avoid or manage it. Johna highlights the importance of having a plan for sunsetting technology and managing technical debt in the context of digital transformation. We also draw parallels between managing financial debt and technical debt, emphasizing the role of architecture in making informed technology decisions. The episode concludes with a discussion on good and bad technical debt and the need to address it strategically. We invite you, our listeners, to reach out for support and engagement in further discussions.

Transcript

Greg (00:00:00) – Welcome to heavy strategy. The place where unanswered questions is better than unquestioned answers. Basically, the point is that we are keep going on a topic and agree to disagree. And the idea is instead of sort of agreeing how wonderful we are and going with the status quo, let’s try and find if there’s some other insights or some other side of the discussion that we can’t necessarily find. So if you’re here, Jonah and I argue strongly, maybe debate like good old high school debates, then that’s what you’re in for. Today’s topic is technical debt. This might be one of many or it might be one of one. I’m not 100% sure how this is going to go. Jonah, I started off talking about in my notes saying, how do you define technical debt or what is it? And I went through a different sort of tactic to what you what I said. In general, for me, technical debt is the inability to easily interchange one solution with another with minimal cost and impact. That is, I’m visualizing that there’s some sort of a solution inside of infrastructure.

Greg (00:00:56) – Could be a database, it could be a website, it could be, you know, some sort of business solution. And for me, technical debt is the inability to move away from that if you so choose. But you want it to go into a much higher level of detail. So I’ve stated my side. Now let me shoot a shot at yours. Greg.

Johna (00:01:15) – I would say that your your definition of technical debt is actually a corollary. The impact of true technical debt. Technical debt has a technical definition. It was the phrase was created by a guy named Ward Cunningham, who’s a programmer who developed the first wiki and kind of, for better or for worse, jumpstarted the concept of Agile. And he described it as the trade off the programmers make between immediate speed and long term efficiency. In other words, technical debt is when you go do something because it works at the time and never change it, never go back to change it to ensure that it’s aligned with your broader architecture and is, as you pointed out, interoperable and has all these other capabilities.

Johna (00:01:56) – It’s like, let’s make it work for the solution at the time. Yeah. Don’t think about the bigger picture. And then downstream, what happens is the problem that whatever the technical debt was created to solve may have gone away, changed, morphed. But the technology is still here, sitting there like a lump in the middle of your infrastructure.

Greg (00:02:14) – So I think Cunningham was referring to in that sort of circumstance, like in his era, the language that people often just rapidly prototyped in was Perl. But Perl was not a good long term decision and running code.

Johna (00:02:27) – No, it really didn’t have to do with the language at all. And the thing to keep in mind is something that you did to solve an immediate problem that worked to solve the immediate problem. It may not have been a prototype at all. It solved the immediate problem, but you didn’t do it. Referring back to a longer term strategy roadmap architecture, which is what we talk about on the show. And that’s that’s the big definition. Now, we got into a whole set of discussions of, Hey, I remember when and you were telling some story about going into a bank where they had, what was it, a Sperry mainframe running.

Johna (00:02:59) – What was it? Yeah, what was it running?

Greg (00:03:01) – I don’t know. Some proprietary operating system, which is the name of which has been lost in the depths of time. But but it was a particular mini mainframe. Whatever it was, it was a specific box, but it didn’t speak tcpip. It actually ran some proprietary protocol over Ethernet. And so when you wanted to access it, there was this thing called the Magic Vlan for decades. You know, this thing was 40 years old When I got to it. They had always got just a magic Vlan that could never be secured or managed or and that was the mystical, magical place. Because if anybody flipped with that, this core system just was very fragile and it would blow up. So there was technical debt in multiple dimensions. There was a technical debt around security because it was insecure comes from an era where networks didn’t go everywhere. You know, you’re lucky if they span two rooms. It was fragile. That’s technical debt, because if a system’s not stable under varying conditions, it’s just, you know, you’ve got to take account.

Greg (00:03:57) – You spend money if it breaks or blows up.

Johna (00:04:00) – But see, I’m going to push back on that definition because technical debt is usually a system that’s outlived its immediate usefulness. It may not have been fragile when you put it in, because when you define it that way, people think, Oh, well, I’m not stupid. I’m not going to put in anything that’s fragile and non interoperable. The key thing is in its day, it was top of the line. The problem is and this gets to one of the big issues with technical debt. Where does it come from? It comes from people putting something in that did fit, that was stable, that was a good solution. And as time marched on, they never had in the in the technology lifecycle, this idea of how do we know when it’s time to sunset this? How do we know when this thing that used to be incredibly robust is now actually fragile?

Greg (00:04:45) – And, well, I think the most common form of technical debt that I would see, which is there’s no way to migrate off this thing.

Greg (00:04:52) – And so you are locked in. And the problem well, no easy way.

Johna (00:04:57) – There’s always a way to migrate. It’s just cost money. Ian takes time. And quite frankly, the reason that happens is because nobody planned for it in the beginning.

Greg (00:05:04) – Well, well, the chance is there. If you’re going to pay down the technical debt, what are you paying in? You’re paying in money to have a service to do the migration to the impact to the business, to pay down the technical debt, to the time taken to do the migration or to rewrite the application, or if you’ve got this app that you wrote or script you wrote in Perl 30 years ago and you’re going to refactor it into Rust or whatever it might be, right? That has no capital cost because you don’t have to go and buy Rust or by Perl anymore. You did have to once you had to go and buy an ID and a license for the language. But today you don’t. But someone still got to sit down and decide what does the app do, what fact, what features you want, and then do the rewrite and then conduct the testing and the validation so or.

Johna (00:05:45) – Decide whether it’s even necessary in the first place, because that’s actually one of the big things that I always push back is people talk about the five R’s and how to modernize your infrastructure. And I always kind of have the sixth R, which is rethink the business process that that app may instantiate may no longer be necessary because times have changed.

Greg (00:06:04) – But if the debt’s too high and this comes down to this concept of debt, if if what you need to pay to rid yourself of that debt is more than the business process that that technology does for you. Right? The classic one is backup tapes. We talked before about there are backups. People have got spindles from the 1970s still locked up in some storage in case they ever need to get them out.

Johna (00:06:27) – That’s actually a story that I have about a client who has disk drives and data from the 1960s and 70s, and because of the business they’re in, they actually have to hang on to this, even though they have no way to access the data that’s on those that the data that’s there, If they ever had to go back and access the data, they would be screwed.

Johna (00:06:48) – But they have to hang on to it and they have to maintain the systems that are there just in case. And that’s classic.

Greg (00:06:54) – I would maintain that that is a technical debt that you probably never have to pay for.

Johna (00:06:58) – I would say maybe, maybe not. But I would agree with your earlier contention, which is the cost of actually fixing it and upgrading all of that to something modern is less than the highly unlikely chance that they actually have to go after that data. I want to come back to.

Greg (00:07:14) – Kind of I can have that debt and just not pay it. Right. And take the chance. Right. A lot of businesses do that. They take on customers as a risk of finance. It’s not I think this is a time to talk about the fact that technical debt is not necessarily bad because one of the things.

Johna (00:07:27) – You’re not all of it is bad. Some of it one of the options is you can just live with it. And when you when you’re assessing technical debt in your organization, you can certainly pick the option of just living with it.

Johna (00:07:38) – Yeah, but what I really wanted to kind of push on a little bit is this whole notion of what practices can you put in place today that ensure that whatever you’re building today doesn’t generate technical debt tomorrow because it is possible to do that? And how do you do that without sacrificing speed and agility and all those other good things? And I think one of the big things here I mentioned the whole concept.

Greg (00:07:59) – Before you go on, I want to just explain something here is technical debt happens all the time. It’s not the fact that you’re incurring technical debt. It’s whether the price of the size of the debt is worth paying. We take on all forms of technical debt like people live in technical debt to Microsoft around Word and Excel.

Johna (00:08:15) – Yes, but no. I would argue that technical debt is when you’ve got you’ve gone past the point where you’re maintaining something that is no longer efficient, You can say, okay, well, we’re using word because we always used to use word, but realistically everybody uses word because everybody else use this word the moment the rest of the world switches, everybody can switch off.

Johna (00:08:35) – Now, if you’re continuing to maintain Microsoft because you know, because that’s what you’ve always done, then at that point you’re in technical debt.

Greg (00:08:42) – But but but just to make the point there, that is a form of technical debt that we all run. Microsoft is nobly and provably unsafe and insecure and produces Word and Excel are by any definition, cost way more than the than the cost price in terms of securing them. Look at how much money we spend on desktops.

Johna (00:09:02) – Yes. But I think you’re I think you’re going expanding beyond the narrow concept of technical debt. You’re not wrong because, you know, we’ve we’ve spent time bashing Microsoft and its security implications. And I’m happy to go do it again. But my my main point here is technical debt is stuff you deployed in the past that is now dragging you down. And the point is, you you’re always going to be in a position of having to roll something out. That’s that has to be out quickly. That has to be agile, that’s solving the immediate problem.

Johna (00:09:32) – You don’t have the luxury of of having a 15 year plan and carefully executing on it because technology will change. But if you follow a handful of practices, you’re going to minimize the the amount of time that you find stuff from the past is is kind of lurking over you or, you know, thinking a bad a bad Mexican meal, you know, haunting you long after the experience. And I want to really hammer on this because I think it’s important for people. We’ll understand this, this notion of any product that you roll out, anything you you design, develop and deploy. Everybody loves to pay lots of attention to proof of concept, to building it out, the test cases, to rolling it out into production. A little less attention to operations, but that’s starting to become more popular since DevOps. But almost nobody that I’ve seen has a product life cycle that then ends with, okay, these are the signs that will tell us we no longer need this technology and this is our plan for sunsetting it.

Johna (00:10:30) – And I’m telling you, if you if you make those plans early, you may have to change them later on, but at least you’ll be able to say, aha, I have warning signs that are telling me that this once robust and critical technology is now becoming fading into technical debt. And I need to start thinking about shutting it down. And I’m telling you, the other thing is, yeah, that’s a that’s a a longer, slower process. And one of the big things is making sure that the users and the stakeholders understand that their beloved application or whatever the hell it is, is going to go away at some point in the future. And they just need to know.

Greg (00:11:05) – That, Yeah, I guess there’s always an expectation that something will last forever. Microsoft Word success, of course, is that everybody’s used to it. Now nobody’s going to. For better or for worse. We’re kind of stuck with it no matter how much we spend making it secure or making it usable or keeping it controllable, it’s not integrated with the version control system.

Greg (00:11:24) – It’s not at the end of the day. I think one of the topics that you wrote down here is that a lot of people see technical debt as prioritization of deployment speed over long term value. And so we tend to say this will solve it right now. I guess one of the things that we want to I want to highlight here is that technical debt happens differently. It’s not one thing. It’s actually one of those topics. You know, we’ve had plenty of these on the show where we sort of say, Yeah, but you can’t define it in one thing. It’s often sophisticated multivariate, multi disciplinary, you know, stuff like that. Would you agree with that?

Johna (00:11:59) – Oh, yes, yes. But no, I mean, I think you’re you’re, you know, technical debt is interesting enough in and of itself that you don’t have to expand it to cover the known universe of problems that we have architecturally. You know, So, for example, I don’t think Microsoft Word is the most egregious form of technical debt, and most organizations are.

Johna (00:12:18) – I don’t think it even you know, I say.

Greg (00:12:20) – That out loud.

Speaker 3 (00:12:21) – Yes.

Johna (00:12:22) – Possibly. Oracle, you know, the the example that you gave of the old Sperry mainframe, you know, things like that are much more egregious. And the reason that they’re really bad gets to digital transformation. We talked about that in a previous show. If it had not been stuck cutting costs and dealing with the consequences of technical debt, it would have been where it should be, which is leading digital transformation. And it’s directly because it got stuck maintaining 20 to 25 year old systems and didn’t have the budget to migrate off them and do new things. Business leaders started saying, Oh wait, now there are these new technologies. It’s all digital transformation. So we’ll bring in people from the outside who will transform us. Yes, You know, you were giving this great example, Greg, where you were the hated contractor because you came into the bank and you were getting paid twice what everybody else was, although you were a contractor and didn’t get the days off.

Greg (00:13:15) – And why not get holiday? And that’s, you know, a retirement plan or anything. All they heard.

Johna (00:13:19) – Yeah, but that’s kind of what’s going on with digital transformation. It’s like the you know, whizzy big companies from the people from the big six consulting companies come in and kind of hand wave about all the cool things you could do with technology and the IT guys are sitting in the corner going we knew that if we just didn’t have to maintain the damn Sperry mainframe, we could have done that for you. Yeah.

Greg (00:13:38) – Sometimes the definition of a consultant is a person who asks you for your watch and then tells you the time and then exact the watch.

Johna (00:13:45) – Yeah, exactly. And we say this as consultants. The things to focus on really are, number one, why did you get it and what can you do about it and how can you avoid getting it in the future? You know, and when I say avoid getting it, everything will become technical debt. But how can you manage it tidily? And I think debt is the great part of this because there are lots of scenarios where people manage debt very neatly.

Johna (00:14:10) – For example, if you go out and you get a mortgage, you know exactly what it’s going to cost you. You plan your lifestyle around it. You budget for paying off that mortgage. And, you know, sometimes you decide that you’re going to pay it down early and have that, you know, have that money available and organized, managed part of your life as opposed to someone who goes out and get some kind of balloon mortgage with no idea of how they’re going to make the payments. You can do it the sane, ordinary way where you manage it, control it and pay it down at the rate at a rate that works for you. Or you can do it the stupid way, which is, oh, look, if I, you know, for $50,000 down payment, I can buy the $600,000 house without realizing that downstream you’re going to, you’re going to have to be making payments that are bigger than your entire annual salary.

Greg (00:14:54) – Although there’s a lot to be said for a fixed 30 year mortgage these days.

Greg (00:14:57) – It’s like 30 years of rent at a fixed price.

Johna (00:14:59) – Well, yeah, but you can always pay off those early. You should at least you should at least negotiate those terms. I am now mortgage free. Woohoo. I always a good thing.

Greg (00:15:07) – Yes, always a good mortgage free. That is freedom. There is no technical debt around my house. Ownership.

Johna (00:15:14) – Exactly. And I think that’s the that’s that’s the other thing to think about because it is cheesy, but it’s but it’s important because when you realize it’s possible, like everybody grows up thinking, oh, I have to have a mortgage. When you think about, wait, what if I didn’t? That’s when that’s when real freedom happens. I think one of the other than having an end of life built into your product deployment, I think the other the other really critical thing that helps you mitigate technical debt as having an architecture and 99 times out of 100, what happens when you’re trying to solve the problem right now is you deviate either deviate from your architecture knowing that you’re deviating from the architecture or you didn’t have one in the first place.

Johna (00:15:54) – Deviating from the architecture, knowing that you’re deviating is actually okay. Like I’m not saying don’t solve the immediate problem right away. You should. But knowing that you have an architecture and building and plans to bring in whatever it was back into the architecture is key in that situation. So you can say, look, we know the right thing to do is X, Y, z. The expedient thing to do is ABC. We’re going to go do the expedient thing. But here’s our plan to bring it back into into the architecture. And if you do that and follow through on it, that’s good. Well, if you don’t have an architect.

Greg (00:16:25) – Let me let me throw this at you then. Yeah. I think what you’re alluding to there is that the architecture function says we are willing to incur this technical debt. We just said that all in any decision you make incurs technical debt or incurs some sort of penalty. For once you have a solution in place, you can’t just throw it out and move to something else.

Greg (00:16:43) – But what you’re actually saying is this is the sort of debt we want. It’s a bit like buying a house. If you buy a house and then you take out a mortgage on it, you’re saying this is the house that I want and I’m willing to accept this debt against it. Technical debt is the same and your architecture function then allows you to manage the debt. It around the technology decisions that you make and the business processes associated with them.

Johna (00:17:03) – Brilliantly put, Greg. Brilliantly put. That’s exactly it. Just the way that an intelligent mortgage, you know, a fixed rate mortgage, as you said, a fixed rate, 30 year mortgage that to manage the debt, the architecture helps you the technical debt and keep it to a to a tolerable level because, yes, you’re never going to be able to avoid it unless you’re constantly burning down your environment and jumping from from company to company. And you really don’t want to be in the position of having to do startup technology every single time you you know, you do.

Greg (00:17:34) – Two things. You’ve got to choose the asset you get for the debt that you incur in as much as you do in personal life as you do in business. You know, businesses incur debts. You buy this product, you pre order something to put into a warehouse. You’ve incurred the debt. Is that a suitable business debt? Is that something that you can eventually turn a profit on? And so technical debt is not inherently bad until you get into things like if you want to get into some specifics, I think if you’re stuck in a closed data format, we can’t migrate the data off to another solution. If you buy something that is a proprietary and that comes with restricted interoperability. So if you buy from a vendor and they have their own command line interface or they have their own user interface or non-standard user interface where where some things are standardized and they come up with their own hack on that. Or if you end up buying having obsolete technology that costs more to maintain than to replace it, then effectively that’s bad technical debt, some things, a good technical debt and some things are bad.

Johna (00:18:31) – And you led with the whole lack of interoperability. And I want to circle back to that because I think that’s incredibly important. Now, once you’ve once we’ve sort of articulated what what technical debt is, one of the things you can do to avoid getting into it is, is avoid getting buying solutions that are proprietary or if you do buy them because they’re the only thing that scratches the itch right at the moment, have an understanding that that piece is going to be a problem. And think about what the strategy is for migrating your data off it before you get before it gets too late.

Greg (00:18:59) – Yeah, I bought this house because it’s in my budget and it solves my problem right now, but I also may need to move house later, so I need to plan for that. Maybe you don’t buy that extra expensive sofa because if you’re planning on moving, you know that impacts your decisions. You don’t want to buy, you don’t want to over.

Johna (00:19:15) – Exactly. You start you start a fund that says, okay, this is my moving fund or whatever.

Johna (00:19:19) – And that’s that’s actually sort of the key thought. But Greg, I want to turn this back to you and toss over a question to you, since we love our unanswered questions. We’ve talked about how to avoid technical debt. But if you’re in an environment where you have a lot of technical debt, what would you as a consultant recommend that people do?

Greg (00:19:39) – So the first thing is to recognize where the debt is incurred. It doesn’t matter whether whatever you’ve got, you’ve got debt. So the question now is good and bad debt. If my business transformation is being restricted because my operational tools are no good, if I can’t administer that, that database that I’m using, it’s a proprietary database and it uses custom tools, then I’m stuck. Operationally, I’ve got a limited resource pool. I might have certain headcount which become very valuable or over valuable to me because I can’t replace them. If you are working in specific industries, your accesses to service and support might be restricted. So, for example, if you buy a technology, if you’re running a resort on, you know, out on an island somewhere and you buy some technology, then that’s a fairly niche market.

Greg (00:20:21) – And the pricing of service may only come from the vendor that you buy from, and that will often end up in the vendor’s favor. So the classic story there is of course, is that the average price for a general IT person is $200 an hour, but your vendor consciously $500 an hour because you can’t go anywhere else. That’s debt right there. So that access to skills and resources can be limited. We talked a bit about Word and Excel. If the vendor is dominant in its space, then technical debt around skills and resources can be solved. At this stage, everybody knows how to use the Microsoft Office suite, so even though you’re locked in and it’s entirely proprietary data format, using it meaningfully is very difficult. So you’ve got operational challenges, you’ve got security challenges, you’ve got migration challenges, but everybody’s using it. The vendor is dominant. Maybe that’s just an acceptable trade off and I think that’s where we are.

Johna (00:21:08) – With Well, I would wish that you’ve stopped using Microsoft Office as an example of technical debt because it’s really not the most egregious problem.

Johna (00:21:15) – And it’s the problem with it is more monopoly than debt. But coming coming around to what you were saying, I think step one is recognizing the the technical debt. And step two is having a plan, a cost effective plan for migrating away from it. I would argue, though, you mentioned something very briefly, and I think it’s incredibly important. People generally and business stakeholders in particular don’t want to fund housekeeping. What they want to fund is new capabilities for the business. So you mentioned that tying the removal of technical debt into your business transformation is key, and I would second that very strongly. A better way to make all this palatable is to go instead of saying I am going to go eliminate. Technical debt. The real problem is the business stakeholder says, What am I going to get for that? And the only answer you’re going to be able to give is, well, I’m able to operate my IT environment faster, better, cheaper. I care about new functions that I’m going to be able to get.

Johna (00:22:13) – So let me hire this digital transformation person over here. And I might or might not fund you to get rid of technical debt because, you know, you’re you’re managing it. Fine. I’ll just go pay for someone over here to do my digital transformation. If you, you you upend it and say what is the business function that the business needs to accomplish now new and future business function build out a project to enable that function, fund that project and include as part of that drawing down the technical debt of the system that ultimately will get replaced by the new function. That’s usually a better way to get funding than to try it on the on housekeeping best practices, because unfortunately, business stakeholders are like five year old kids in a candy shop. They want the shiny, tasty thing and they don’t want the broccoli. And so you sort of have to say, Well, here’s your lollipop. You have to eat the broccoli to get the lollipop.

Greg (00:23:06) – Yeah, I think the challenge here is a lot of people see technical debt fairly narrowly.

Greg (00:23:10) – And one of the things that I’ve learned over the years is to start looking at it way more broadly, if that makes sense, where it’s, you know, a business process can be working and it’s doing what you want. The challenge here is to recognize that it’s fine, right? You know, just because you’re using this lousy business process thing. But what I also want to highlight is that we’ve significantly addressed a lot of technical debt around openness and open standards. The challenge here is we’ve seen tools like Linux come around, which just gives us a basic standard for operating systems. There are things that it makes sense to standardize, to have as a commodity to be and using as open source. But there are times when you don’t. So there’s times you literally want to incur technical debt because that gives you a richer, better, more profitable and more less operations, more whatever it is. Technical debt is a real thing and you actually want it. It’s not just a know.

Johna (00:24:06) – Exactly. And I think there’s nothing else that you come away from this show with.

Johna (00:24:11) – The idea that technical debt isn’t an unmitigated bad thing is probably the top one. The second one might be that there are ways to mitigate the amount of debt you accrue in the future so that you’re only getting the debt that you want. And I think the last one is there are processes for eliminating technical debt from an existing environment. But the trick is generally you’re going to not get funded for it. So you have to tie it into some new capability and focus on building that new capability out and then kind of roll in the Okay. And as part of this, we have to actually get rid of this old system legacy system behind it. There’s there’s a phrase for that in the Agile programming model. I know one of my clients actually took their absolute core application and when they were rolling in Agile, they, they basically said, We’re going to rebuild this application with all the new functionality you can get with today’s technology and then turn off the old one went once, migrate everyone to it and then turn off the old one.

Johna (00:25:10) – Once everybody’s gotten comfortable that the new technology can enable what the old monolithic solution did and it worked. And that approach does work. And they ended up with a brand new modular, interoperable, all those good things, agile system. And they were able to turn off a 25 year old system that was incredibly expensive to maintain.

Greg (00:25:32) – And the thing I would say to people and I’ve been quite successful as this is when you’re talking to business people talk about technical debt in in business terms that I’ve used here today, where I’ve got stock sitting in the warehouse that I can’t sell that’s sitting on the books as debt, right? Because you’ve paid for it and you can’t sell it. Nobody wants to buy it. That’s what you’re sitting on here. You need to talk about operational debt. That is this, this is this solution or this business process we have is costing us this much to maintain. It would be cheaper to consider paying down that debt by buying a new solution to replace it and having something that we can operate more efficiently.

Greg (00:26:07) – Talk about it in terms of speed to market. If we would place this solution, you could be able to bring new products to market. So the big one we’ve seen recently is a lot of companies suddenly say, let’s get technology to deliver SAS. So let’s build a cloud operated service. We can create a new product just out of technology, create subscription revenue from it, and our customers get more from our existing products and we grow the overall revenue. However, in the process of that, we incur technical debt. There is a debt in technology, not not just a simple debt, that is. And it’s like holding stock in a warehouse. As long as that stock sitting in the warehouse, it’s costing you money, it’s either depreciating or going obsolete or whatever. And you’ve got to look at your technology in the same way. And if you can phrase it or I’ve had great success in terms of phrasing it to executives in that way.

Johna (00:26:53) – I want to detangle two concepts that you raised here, because I think they’re both important, but they aren’t.

Johna (00:26:58) – Necessarily related if you’re working for a CFO or a CFO. Minded person, you can make the argument that good, good housekeeping makes sense by using business terms. You know this your warehouse with the obsolete dating technology. ET cetera. ET cetera. And there’s a decent chance that the CFO will say, You know what? That makes perfect sense. I wouldn’t do that in any other area of the business. Why would I allow it to do that? Yeah, and that’s a compelling argument. However, in a lot of cases, you may not have good fiscal discipline generally or your CFO may not be in a position to make that decision. That’s when you pivot and say new capability, let’s give you the new capability. So we’ll give you the candy first, but you have to eat the broccoli later. Yeah. In that model, you you peg elimination of technical debt to the the new thing the new capability that your business stakeholders want. And I think there are two different things you can you can make the same argument for the same or make two different arguments for the same project to two different people.

Johna (00:27:57) – But you don’t necessarily have to do both at the same time. You can if you’re lucky enough to have a CFO who understands the logic, you’re good, you’re golden. You can go in and say, I’m getting rid of the technical debt because it doesn’t make sense to have it. If you’re more like most organizations, you actually have to to peg the elimination to the to the delivery of the shiny new thing.

Greg (00:28:18) – And that’s and this is where people often get confused about technical debt and using open source or open standards or interoperable standards. That’s only part of the thing that is, the value of openness is the ability to unlock, to lock out. I call it. We talk a lot about vendor lock in, but what you’re really talking about is the inability to lock out or to unlock and get away. And this is where open standards, openness, open source can help you because it makes it more portable. But it’s not the overall problem of technical debt. The overall problem of technical debt is a bit wider than just your technology choices and which ones you want.

Greg (00:28:54) – So I’m not rabid about open source. It’s just a way to incur less debt. But probably in a higher operational cost.

Johna (00:29:00) – And I agree with that. And I think, yeah, I think technical debt, as you just said, is bigger than the question of openness. But openness should be a selection criterion for every product solution service that you bring into the organization. For exactly that reason, it minimizes your chances of being stuck with technical debt downstream. So definitely agree that technical debt as a as a problem is bigger than than interoperability and openness, But an emphasis and a strategic direction towards interoperability and openness can mitigate the problem downstream.

Greg (00:29:31) – And keep it in business terms. Again, you know, when we talk about talking to the business and talking in a language they understand we shouldn’t have to. I’ve said this before, we should we should be able to they should be able to meet us and understand something about us. But they don’t talk in that sort of language. Try and turn it into this.

Greg (00:29:48) – Storytelling is super important around technical debt and getting the right stories in the right story arcs is what will lead you to some sort of success. And or remember, you can always get away from technical debt by quitting. That’s very important.

Johna (00:29:59) – But there’s that. Go to another company. Exactly. Well, I rarely say this to you, but I couldn’t have said it better myself on that. So I think we’ve we’ve wrapped up that topic, but we would love to hear from you. If you’re wrestling with technical debt, please come and talk to us. Greg, How do they how do they send in a follow up kit.

Greg (00:30:16) – Head on over to packet pushes you You can tell us what you really think or you can send us a follow up, whichever one of you you want to do. And don’t hesitate to talk about us on social media. It would be super helpful if you tell your friends about this show. If you found what we’re talking about valuable. And this format is unusual. We’re not getting we’re not sitting in the mainstream of the podcasting industry.

Greg (00:30:37) – It would be very helpful if you’d help us find new audience.

Johna (00:30:40) – Also, if you want to come on the show, as Greg keeps pointing out, we would love to have you on the show. Come tell us your experiences with technical debt. Tell us whatever else you want to talk about that’s technology strategy related and tell us that we’re idiots. Hey, we can take it. We’re big boys and girls.

Greg (00:30:55) – Yeah, it’s not just about our opinions. It’s about yours as well. And we’re trying to take your perspectives in as much as we know how. But it would be really interesting to find if someone’s got an idea or a way to measure this too, would be interesting.

Johna (00:31:04) – Yeah. And if you. That’s a great thought. We have to come back to that. If you if you want to join our community, come on over to the Nerdist community. Hit the nerds website, nerds click on the community tab and just mention heavy strategy. We will usher you right in. Greg and I hang out there and we’ll chat with you.

Greg (00:31:22) – And we’ll look forward to seeing you in a couple of weeks.