> Likely when that happens the company will just spend more than they needed to fixing the issues and no one will be around to say I told you so.
In my experience, yeah, but how they do it is... not what you'd expect.
Leadership has no clue about the scope of tech debt in their products and if they do decide to fix it, it will be by coming up with a bunch of ridiculously optimistic estimates and then foisting them off onto engineers who are already overworked trying to keep up with tech debt to launch new stuff. This feels awful and generally doesn't lead to anything being properly fixed because it turns fixing tech debt into a "just get it barely good enough and mark it as done."
After the inevitable surge in attrition, more often than not the tech debt is "solved" by throwing out the old codebase and starting from scratch with a new team. This is expensive, but in a lot of cases produces a better product.
In my experience, yeah, but how they do it is... not what you'd expect.
Leadership has no clue about the scope of tech debt in their products and if they do decide to fix it, it will be by coming up with a bunch of ridiculously optimistic estimates and then foisting them off onto engineers who are already overworked trying to keep up with tech debt to launch new stuff. This feels awful and generally doesn't lead to anything being properly fixed because it turns fixing tech debt into a "just get it barely good enough and mark it as done."
After the inevitable surge in attrition, more often than not the tech debt is "solved" by throwing out the old codebase and starting from scratch with a new team. This is expensive, but in a lot of cases produces a better product.