I like the premise, but what do we call it? Engineering-driven work doesn't take into account the trade-offs between speed and quality.
Often engineering teams are pushed to work faster at the expense of the quality or by cutting reasonable corners on flexibility of the system.
How do you describe this to outside stakeholders?
I feel like the correlation between speed and quality should be taken into account, which is why tech debt makes sense. It's the debt you accumulate as you build software.
With that said, I'm not a big fan of the name either
The flip side of debt is leverage. That is, you get stuff that you "normally" couldn't afford, or can't afford right now. For a smaller investment (maybe all you can afford..) you can achieve bigger outcomes.
Usually in software, this would be shipping "magical" features (that are done in a crappy way behind the scenes) or shipping faster (because you are foregoing some maintenance).
The common business advice is that debt is OK if you're using it for growth (building capital) and I think that analogy loosely holds for software. Obviously it's possible to get dragged down by debt if you overdo it.
Often engineering teams are pushed to work faster at the expense of the quality or by cutting reasonable corners on flexibility of the system.
How do you describe this to outside stakeholders?
I feel like the correlation between speed and quality should be taken into account, which is why tech debt makes sense. It's the debt you accumulate as you build software.
With that said, I'm not a big fan of the name either