That's a thoughtful approach, but if I were a (technical) business owner I'd still be skeptical about those large refactors. As a fellow engineer I'd appreciat

That's a thoughtful approach, but if I were a (technical) business owner I'd still be skeptical about those large refactors. As a fellow engineer I'd appreciate them, but for our overall organizational success I might still wonder if they were the best use of time -- especially because large refactors/rewrites can be risky. If you started by developing test coverage (that would remain constant throughout the refactor) I think I'd find that an easier sell as both a tech business owner and a fellow engineer. Another angle to consider could be handling 'known' technical debt as feature teams emit it. For example, a feature team might be aware that there are some negative aspects to their implementation, but they may have other high-priority tasks to handle. Catching those "debt outputs" (perhaps detected during code review) could be a continuous task for a role like this. The problem in that case would be alignment of incentives: how do you ensure that the feature team doesn't just take the easiest possible implementation and claim that all the downsides are just technical debt to be cleaned up by another team.