The article challenges the common narrative around technical debt, suggesting it’s not just a financial metaphor but a symptom of deeper issues in software development. The author emphasizes that measuring technical debt can be misleading without understanding its root causes. A client sought metrics to evaluate technical debt across their system, but the author found a lack of concrete signs or lists to help quantify it. Research on the topic yielded mostly abstract definitions rather than actionable insights, leading the author to rethink the approach from first principles. Central to the discussion is the idea of cognitive load, which refers to the mental effort required to understand and work with complex code. High technical debt increases this cognitive load, making it harder for developers to implement changes or add features. This, in turn, leads to two main problems: increased implementation effort and decreased runtime stability due to more bugs slipping into production. The author illustrates this with a dependency graph linking technical debt to cognitive load and then to the subsequent challenges in development. The article also explores the opposite direction, examining what drives implementation effort and runtime stability issues. Factors like poorly defined requirements, frequent context switching for developers, and overly complex processes contribute to both increased effort and instability. The author identifies a complex web of factors affecting cognitive load, highlighting that it’s not just technical debt at play but a multitude of drivers. This broader perspective emphasizes that simply addressing technical debt isn't enough; one must also tackle the underlying causes to improve software development outcomes effectively.