Where can I find a list of structural quality principles that would resonate with a manager?

This question could be regarded as opinion-based. I'll take my chances. So here goes:

I'm trying to explain to a non-technical manager why structural software quality matters. Like nearly everyone, he understands the importance of functional software quality, because that's primarily user-facing. But structural quality is mostly lost on him. It's not that he regards it as unimportant, just not very important. "Who cares? As long as the end product is the same."

I think it's well established that software projects with high structural quality cost less in the long run, though they can have higher up-front costs because they require a bit more thought.

So, what I'm looking for is a list of principles a non-technical manager might understand. One that resonated with him was "Don't Repeat Yourself". However, things like SOLID are a bit too technical and would go right over his head.

I also want to stress that it's possible to have a project with good functional quality and few bugs, but which still has poorer structural quality than it needs because the developer chose the wrong kinds of abstractions, making it harder to maintain and enhance. (This can also occur in spite of one's best efforts, because the functional requirements changed in a way the developer did not anticipate. Not much can be done about that other than to refactor.)

I searched the web for such a list, but perhaps my Google-fu is not so good on this topic.