Technical debt does not manifest itself only as “bad code”. When working against a tight deadline, we take strategic decisions without being able to explore the problem space as much as we’d like. So the resulting code itself may be clean, but eventually architecture changes are unavoidable. And those are more costly to execute.

Under a high pressure scenario with poor business knowledge, it’s easy to incur debt that’s in the reckless and deliberate quadrant of technical debt by skipping design.
When you don’t have the luxury of time, I find indexing on Amazon’s “Are Right, A Lot” and “Have Backbone; Disagree and Commit” leadership principles the most likely way to shift right to the prudent and deliberate quadrant.

techDebtQuadrant

As a teammate, voice your concerns for a proposal, this way the team is aware of all datapoints, however if the person on the team with the best track record and experience wants to go another route just commit to it. That should get us the closest to the real customer requirements and hence to the smallest debt.