Technical debt tends to accumulate precisely because no single Scrum accountability clearly owns it. The Product Owner is focused on delivering customer value; the Developers understand the debt best but don't unilaterally control the backlog's priority; nobody in the framework's default design has "reduce technical debt" as their explicit job. Understanding how the three accountabilities should actually share this responsibility clarifies why it so often falls through the cracks.
Why technical debt is structurally easy to neglect
Technical debt is invisible to the people the Product Owner is accountable to. A customer or business stakeholder can see a missing feature; they can't see a fragile authentication system that's one edge case away from a serious incident. This asymmetry means technical debt loses, by default, in any prioritization conversation that only weighs visible customer value against visible customer value. The debt simply isn't in the same currency.
What each accountability should actually do
The Developers are responsible for making technical debt visible and quantifiable, not just for complaining about it in the abstract. "The codebase is a mess" doesn't compete well against a concrete customer feature request in a prioritization conversation. "This specific piece of debt adds roughly three days to every future feature touching this module, and here's the evidence" does. Developers who invest in making the cost of debt legible are far more likely to see it actually prioritized than developers who rely on the Product Owner simply trusting their judgment.
The Product Owner is responsible for treating technical debt as a genuine backlog item competing on its actual merits, not as an afterthought squeezed in when there's spare capacity. This requires taking the Developers' quantified cost estimates seriously and weighing them against customer-facing work honestly, which is harder than it sounds when the customer-facing work has an enthusiastic stakeholder attached and the debt does not.
The Scrum Master is responsible for making sure this negotiation actually happens, rather than technical debt simply losing by default in every planning conversation because it's structurally disadvantaged. This might mean facilitating a dedicated conversation about technical debt outside of normal sprint planning pressure, or coaching the Product Owner and Developers toward a shared framework for weighing debt against feature work, rather than leaving it as an unstated tension that resolves the same way every time.
A practical mechanism that helps
Teams that manage technical debt well often adopt an explicit policy (a fixed percentage of each sprint's capacity reserved for debt reduction, for instance) rather than relying on debt winning a fair fight against feature work sprint after sprint. This isn't found in the Scrum Guide, and it doesn't need to be; it's a practical adaptation that acknowledges the structural disadvantage debt faces and corrects for it deliberately, rather than hoping good judgment will correct for it informally every single time.
The underlying point is that "who owns technical debt" isn't answered by any single accountability doing more work. It's answered by all three doing their specific part: Developers making it visible, the Product Owner weighing it honestly, and the Scrum Master ensuring the conversation happens at all.