IMO there are two types of tech debt. The first is "techincal" debt - which is stuff that gets ignored for the sake of faster delivery but slows down developme

IMO there are two types of tech debt. The first is "techincal" debt - which is stuff that gets ignored for the sake of faster delivery but slows down development in the long run. Missing tests, spaghetti code, weird hacks, poor documentation. The second type is "product techincal" debt - stuff that purposely half baked / half delivered for the sake of meeting deadlines. Features that are delivered or bugs that are fixed in less-than optimal ways. I'm much more sympathetic to the second kind. At a certain point you always have to negotiate quality with speed. As long as there is a shared understanding that "this isn't perfect, but we're agreeing to move forward", it can generally be corrected eventually. The first kind is usually the kind that gets piled up though. It's the stuff that causes engineers to want to burn down everything and rebuild, and eventually leads people to quit. Nothing is worse than being forced under time constraints and then realizing you can't implement a new feature without being forced into a major refactor, or spending a week on adding tests that should have been there in the first place. It's this stuff that causes the most stress IMO, because management usually sees it as unnecessary.