When it comes to tech debts, you must know that all of these are not created equal as the rates of interest vary and therefore when you have to pay back you must be very selective about it. You may prefer to incur tech debt in a specific end user visible feature rather than incurring the same level of tech debt in a core system. The reason behind such preference is simple. There may be a chance in the former that you might not have to pay off the tech debt ever as the feature might not be of any value to the user. It might be possible that the feature which is with debt might be good enough and would not need any refactoring for a long time.
Manifests As Inflexibility And Rigidity
Tech debt in a code manifests as inflexibility and rigidity as you would find while modifying a part of code which is inflicted by tech debt. You will have to work extra on refactoring it but when a code is rarely modified the debt becomes less expensive. While debt is in the core system, it is more likely that it would slow down the ability to make any modifications to it. When there is an existence of unreliable library deep in the core, it will manifest intermittent defects throughout the product making it difficult for you to locate the problem and debug the code effectively.
Lean Versus Debt
When you consider any physical good, you will see that you require less debt to operating it if the supply chain is lean. This attribute makes the lean supply chain to be more robust if sales dry up suddenly and in other faces of unexpected. You will be stuck with less unsold stock and have less debt to your business. This just in time nature reduces the risk of uncertainty and is more capital efficient as well. It is same in the case of tech debt as the team which practices lean supply accumulate less tech debt and can manage whatever they have in hand on time. They do not have to sacrifice on their work speed as they work on smaller batches.
Invest In Speed
You have to invest in speed instead of features with new approaches. If you take on tech debt, you can invest the energy elsewhere, but you have to be sure that the tech debt you let go is manageable and would not severely affect the functionality of the whole code. You can trade it for process development, and it becomes easier to address all tech debts in the future. It may also be so that a particular debt may never come due and in such a case such trading is beneficial.
Tech Debt In Real World
Tech debt is inevitable in the real world and has to be addressed some time or the other. You have to take it seriously and consider paying it back just like you pay back all your multiple credit card loans by taking a single but bigger amount of credit card consolidation loan or go for bill consolidation loan for your bills.. This reverses the standard intuition and adds value to the code which can be done with proper test coverage and refactor with value added work.