You're definitely on to something here. The root of the worrying pattern is that you and your team are not aligned on what Technical Debt is. Do you have a des

You're definitely on to something here. The root of the worrying pattern is that you and your team are not aligned on what Technical Debt is. Do you have a design/code review process? Do you have a coding standard? (I think these are prerequisites to alignment) Using the unfamiliar library example, there could be a review process that happens before the rewrite that considers at least the following: - code life: is this throwaway code or will it be used for the foreseeable future, have good enough documentation and tests to survive team turnover? - team knowledge: what technologies are familiar/unfamiliar? What technologies should we all be learning? - alternatives: what existing libraries are available? How well do they meet our needs? Cautionary Anecdote: I once joined a startup. I remember the last bulleted line in the job description was "Preferred: Knowledge of functional programming languages such as Scheme". The interview process was straight C++ and no one mentioned a word about functional programming. After a couple weeks of code sifting and it became clear that a former team lead who'd recently been let go was a hardcore Scheme guy. He built and maintained a chunk of the build infrastructure which by the time I arrived had been obsoleted by a Python tool. No one else at the company understood or wanted to learn Scheme. (Nothing against Scheme BTW). The desposed team lead failed to bring themself and their team into alignment. That they were removed rather than leaving on their own indicates that they either failed to recognize the problem in time or recognized it and chose to ignore it. You must be clear on the existing skills of your team members and realistic about what they are capable of and can be motivated to learn.