Tech debt can occur when too much of the same knowledge is repeated across a system. For example, the rules to deserialize and validate a config file can be implemented independently by two separate developers, perhaps with one implementation requiring a specialization that has convinced one of the developers that they need their own fork. 

If developers had unlimited time, the ideal approach would be to maintain one implementation or one source of truth through continuous refactoring of the existing implementation. However, many developers prefer to trade-off uniqueness for velocity as they would find it easier to start anew than grapple with the constraints of an existing piece of code that may be risky to change.

Teams do not often budget refactoring in their estimates. When faced with the choice of refactoring vs. starting anew, starting anew becomes attractive as it usually contains less unknowns and developers can work fast in a hermetic design environment. 

An organization's tendency to avoid refactoring can also point to problems in the culture of ownership. For example, if developers were told that they were owners of a particular piece of code or system that was a candidate for a refactor, it would seem absurd for that developer to produce a derivative of that work rather than refactoring the system they own. Artificial ownership boundaries that are unintentionally created by team boundaries can cause issues like this and we can end up making decisions that hurt us in the long run.

The natural tendency to avoid refactoring existing code to meet new or changing requirements leads to fragmentation of functionality and knowledge. Growing organizations need to exercise the 'refactoring' muscle fast before the fragmentation slows everyone down.