Your CEO (or whatever stakeholder you mean) should not care about _how_ you work, they should trust you to do the right thing and enable you to do so. They should also give you feedback and correct your course, but only in terms of what you work on and with what priority. They should not care how you do it.
In the same way your lawyer does not tell you what kind of legal internal documentation they do and if they go to court X or Y to ask for something, you should not tell that to your stakeholders. You tell them only high level things that are relevant. Tech debt is not one of them, progress and estimated dates is one. And just like how the lawyer recommends you a certain path, you should recommend one to your stakeholder. E.g.: "Yes we can build this feature, but we could also build this other feature, which is almost as good and takes half the time. I suggest to do it this way".
> I think by talking explicitly about tech debt you can get the non-technical stakeholders on board. (It helps I think of you were warning them about tech debt when you were taking it on, too, and not just starting to educate when it comes time to pay back.)
Let's say you are in the position to do so and they trust you. Do you think it is productive to "warn" them? Let's be honest: even for developers it is very hard to understand the direct and indirect impacts of tech debt. And that is even though they can directly experience the effects. How difficult do you think is it for people for whom this is just an abstract term?
TLDR: I think it is easier for you to understand the business goals and make a technical decision than it is to make business people understand the technical constraints and educate them well enough to take the right decision.