Beyond what taway20171214 said, don't discount the value of "language which management can understand". As I've moved up the ladder I've learned how extremely valuable this skill is and how woefully bad I am at it.
1. What's the proposed issue/improvement?
2. What are the recommended options?
3. How much time will it take to get done?
In other words, all you really need to communicate is why we're doing it, and when it will be done.
In my experience, they're not interested in challenges faced in implementation. Keep things simple, and deliver on time, and you'll be speaking the "language which management can understand". That's basically all there is to it.
Your line manager may be interested in a technical issue / improvement and understand its value without further explanation -- for instance, we're using a brute force algorithm that takes exponential time to foo the bar in the Baz module. It's got test coverage and the problem has a known logarithmic solution, so we could rewrite that in a week to be more efficient, and still be confident it's accurate.
Your department head may be willing to consider fixing a problem that affects efficiency or security or expected timelines -- we've identified the likely cause of at least one class of those outage events you've raised concerns about. If you want to fix it immediately, we would have to push back delivery of the Quux feature by a week while we rewrite a portion of the Baz application, but other risks are minimal.
The C-suite is mostly interested in problems/solutions framed as "how does this save us money" or "how does this make us money" -- we intend to invest a week in technical maintenance work that will allow us to save 25% of our monthly hosting costs by scaling back hardware requirements, and reduce the frequency of outage events that we have to pay out for on under our SLAs by 75%. That would cost $10,000 in developer time and delay our product schedule by a small though measurable amount, but I estimate it would save us an average of $48,000/year in costs.
The other piece I've seen is being able to handle "I want Foo by X". It's easy to take on the engineer mindset and say "Sorry, that's not possible. The whizbangs alone would take more than that time!", but what do you do when they simply repeat "I want Foo by X"?. Picture the various Star Trek series where the engineer would say it'd take 5 hours to fix something and the captain retorts "you have 2". It's real.
The skill which really makes me jealous are the folks who are able to read between the lines and get at why they want Foo and why they need it by X. Instead of saying "Sorry, no can do!" they're able to offer Bar instead, and because they understand the deeper motivations of why Foo is being requested they understand why the manager is likely to accept Bar instead of Baz.
This is pretty similar to your C-suite descriptions, now that I reread it. But it's a different spin on it.
One tactic I can suggest (if your manager isn't a totally unreasonable cartoon tyrant) is to simply be explicit about it and ask "can you explain more about why you need Foo?" and then "what's driving the deadline of X?" Understanding the business case is generally necessary - though not always sufficient - for coming up with an alternative solution.
I suspect that part of the gap between people who are and are not good at this is how well apprised they are of the general conditions, initiatives in other departments/teams, and short-term strategic goals of the company.
Some of that is on the person who may or may not put in the effort to remain informed; and some of that is on the company's management that may do a good or a poor job of communicating those things proactively between departments/teams and from senior management down to junior management and line workers.
Depends on the individual, not on the job title. In my experience, managers of any level value information as simply put as possible. If they ask questions, then you answer them, but otherwise just tell them what they need to know.