I would try to explain it as levels of abstraction and how they extend beyond the computers that execute the code. You can go down through the levels of abstraction, 1 by 1, until the point is made rather than attempting to start from the bottom and work up.
So, for example, when talking to the non-technical executive, the first level of abstraction is the technical expert that tries to explain complex technical issues. Below that, there might be a technical management layer that deals with technical issues on a more granular level, but still isn't looking at the code. Below that there's the actual developers who are writing code and are concerned with the actual logic the computer is executing. Below that are the framework authors that abstract away the common parts of writing an application of a certain type. Below that are the language platform authors who write compilers or interpreters that translate the code typed by the programmers into a format that either the computer or a lower-level abstraction (LLMV, etc) deals with. At this point, it's probably not necessary to go any lower, but you can go all the way down to CPU/machine architecture level, if necessary.
The key point is that even highly-technical people have to trust the layers of abstraction below the point where they have full understanding. I've been coding for over 20 years and I still only have a cursory understanding of how my compiler is translating the code I write into machine code, let alone how the actual hardware that runs the code. I took EE courses in college and understand the theory, but the implementation by the folks at Intel and other hardware vendors is opaque to me and I'm forced to trust that it works.
The coders employed by your company may be able to dig into framework code, but the chances are that they're fully trusting the runtimes that they work with. That trust may be the result of a well-earned reputation or through testing that the claims made by the language runtime are empirically true, but it's still trusting something that they're unequipped to verify themselves. This need to trust bubbles all the way up to senior management. The systems are just too complex for anyone concerned with the finished product to understand the whole picture.
That means that, as an executive, you're likely trusting your senior technical leadership. The only way you avoid doing that is to dig in and better understand the abstraction layer they're providing. You can also make that trust easier by doing the same sorts of things that a coder does with their language runtime...give tasks to your abstraction layer and test whether they're completed successfully. And, when those tasks are not completed successfully, don't accept techno-babble responses, dig in to understand the wheres and whys of where things broke down. Likely, the chain of trust of those abstraction layers was broken at some point...figure out where that point was so you can prevent it from happening again.
Every abstract layer adds uncertainty to the system. A CPU engineer can tell you how long a small task will take within a ns or so. A compiler engineer can tell you how many CPU cycles an expression will result in and compute an approximate time for a given processor within microseconds. And it continues as you go up the chain until you're talking to senior management and he's giving you swags with a margin of error of months. Understanding this goes a long way towards explaining the behaviors that are so confusing to the non-technical executive. It's intimidating, but the good news is that many of the skills of a good manager are what's necessary to achieve the necessary level of demystifying. The way that you begin to understand these layers of abstraction is through inquiry. Ask the right questions and, over time, you'll understand more and more of how software development happens.