If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it tech

If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem. But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case). If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.