Tradeoffs are an intrinsic part of engineering. One part of your job is to propose solutions and tradeoffs. For example, "if we want to ship this fast, we can do it in a day, but here's what could go wrong, and how much negative impact this could have on how many users/bottom line, on the other hand, this is the upside". "If we want reliable, we'll have to solve X issue before shipping it but it'll take about Y days because we still haven't resolved incompatibility with third party tool Z"
Do you frame your decision making and the set of options in terms your manager understands and can base their decisions on?
Why this matters? It avoids you spending days or weeks working to solve an issue because you think it'll save $X, when in fact $X may not be what matters most to your manager, but the ability to ship before a competitor, for example, especially given the fact that if the price to pay if that feature falls flat is not that high.
One problem members might have is not knowing what matters and why it matters, and that effort must be done by management to make it clear through what lens team members should look at problems so that they themselves will be able to make decisions.
If this effort is not done systematically by management, members can help management with eliciting questions explaining why they're asking these questions so it doesn't come off as an interrogation. You're asking questions to know what matters most so you could optimize for that and work to solve the right problem.
One other problem is that some team members cannot discern situations where they can make a call, and situations that warrant getting the green light to do something. This leads either to members requiring the attention of the manager for everything, even things that the manager doesn't care about, or members making a decision and going through an action where the cost of a mistake is too high but they didn't know what the cost of that mistake would be.
True positives, false positives, true negatives, false negatives.
This why members who can tell which situation is which are not common and appreciated by management, because they relieve the pressure and reduce the number of interventions management has to make. This builds trust in that member's judgement, and they gain more latitude to do what they want because the manager knows that "Alice only calls me when it really matters and when the situation is tricky and she needs confirmation."
One great habit to have is to enable management and executives to do what they do best: make corrections, green light things, shut down things.
I used to go to my former CTO with prototypes of different approaches in different branches. He'd look at them and pick one or ask if I could do corrections to one of them and ship it. "Do you care about this aspect or is that good enough?" "Nope, we'll merge as is" or "All is okay except this and this must change because X, Y, Z.". Things move really fast that way.
I also showed the CEO different versions, and he'd ask "Nice. I prefer that one because I'll present it to [type of client] and it's more relevant".
In other words, instead of asking what the next step is, proposing alternative approaches: We can do A, B, C, D and here are pros and cons for each and how they relate to the objectives with tradeoffs and optimizations.
The manager then has a "menu" they can pick and choose from, and will either say "We'll go with A" or "Just change this aspect in B and go for it". This saves enormous time and makes their job easier, and makes your job easier too.
There's effort to be made by the two parties. Management must train members to know what matters and expose how they view things. "Our priority is this, if you need to spin up VMs to test something, you can do it as long as you don't blow up the budget. Say you have a budget of $300. What we want is X and we know we got it if W, Y, Z".
The team members ought to do the effort to frame their decision making process, their options/solutions, their problems, in terms stakeholders can understand, reason about, and make a decision about. When you do this, you'll get extremely useful input from other stakeholders and you can enable people who make decisions to make informed decisions because they have clear information they can digest.
The excuse that manager/CEO/advisor/investor is not technical is a bit easy to have. How do you frame problems to get the best out of that manager/CEO/advisor/investor's minds or executive authority? How do you give solid arguments to your manager to advocate on your behalf, say to increase budget or to hire talent by framing things in terms they understand and can work with, but also in terms that their boss can understand and work with.
You: This [engineering/technical problem] is [framed in terms boss can understand]. One way to do that is CEO doing [thing in terms boss understands] with arguments [boss can understand, and then again in terms of CEO can understand].
There are things that matter and you know why they matter, and one part of your job is to make other people understand why they matter. The ability to connect the dots and take someone by the hand from the [business] objective all the way down to how inability to do multiprocessing is hindering that objective, and how what you're doing is solving the problem is valuable.