It’s called debt for a reason - if it’s not paid down steadily it comes due all at once and you lose your house
Disproof
Unified technical and feature planning, always
Consequences
You will have a lot of explaining to do at the best, and existential problems at the worst
Compounding tech debt presents the same dynamics as error propegation in untested product hypotheses. Each successive kludge you leave in multiplies the risk of a showstopper or show-killer. Invariably, something either:
Breaks in production and you lose money and customers
Breaks before production and you lose time, money and potentially customers
Whenever you hit the landmine that you can't just soak up, you then lose the next few months of ‘progress’ fixing it
In reality, you never had this time in the first place
But it reaaally sucks having to explain to your customers and shareholders why your rapid pace of shipping has ground to a halt for some quarters
Especially if commercial deals or investments ride on said shipping
Causes
Move fast break things?
The irony of a ‘damn the torpedoes’ approach will usually work juuuust long enough to give people confidence that it will always work. As you get away with it, you think you’ll keep getting away with it
Generally exacerbated by a structural disconnect between people prioritising work and people who understand the infrastructure
Happens very often with PMs who are not remotely technical and have a bad relationship with the tech leads
Also happens with overly atomised teams where nobody’s keeping track of debt across the technical estate
In cases where tech debt is deliberately downplayed, it's usually because someone over-engineered a refactor, got blamed for wasting time, and the team over-corrected
Approaches
The one case you might be lucky is where your engineering team growth can outstrip the rate at which you create errors in your infrastructure.
But if you're this kind of company, almost invariably those engineers will be diverted to do more feature work instead of creating capacity to fix tech debt
If the communication is not there between engineering and whoever needs to know, that is top priority.
Communication includes it being safe to voice these needs
Communication should also be backed up by facts and quantification, because otherwise ‘the cranky engineer’ who’s always ‘crying wolf’ just gets ignored again
As with agricultural land generation, get ready to see ‘productivity’ fall briefly and then accelerate. Sell people on the latter half
And if this is just a case of forgetting to think about it, stop relying on Hope as a Strategy