Oh agreed, it's a lesson to learn, just like the rest of their engineering practices were learned. You don't usually absorb stuff like that fully by having som

Oh agreed, it's a lesson to learn, just like the rest of their engineering practices were learned. You don't usually absorb stuff like that fully by having someone tell you once. > Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along. I don't think it works any other way. A lot of times the only difference between "intentionally accrued tech debt" and "shoddy work"/"bugs"/"brittleness"/etc is communication. > A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along. If you're constrained by time and money, this is usually the case. You accrue tech debt to meet constraints, and you pay it off over time, not necessarily immediately. It's just normal roadmap prioritization. All you can do as an engineering leader is correctly advocate for the urgency of tech debt, communicate interdependency issues ("we must pay down this tech debt before we can tackle feature X"), and pay off some debt when it makes the most sense.