THIS is your answer, leoqa. The business value is the $$ the company can lose if it goes wrong.

If higher-ups have no technical insight, round up and give them two numbers: $$ if a bad thing happens, and $$$$$ if the worst thing happens.

And they’ll ask for the probability of these outcomes to find the expected cost. And you’ll struggle to give one without heavy caveats, and thereby lose perceived credibility.

"It's hard, so do nothing" is your advice.

Yep. I recently had to convince management to let us fix a legacy CloudFormation template that was brushing right up against the AWS resource limit for a single stack (which also means it was WAY over the recommended limit for a production stack). It had been causing CFN to occasionally choke on a deployment for over a year, and it was just a matter of time before we either added the resource that pushed us over the hard limit, or CFN choked on a deployment and failed to roll back to the last good state.

The director of my department kept asking, "But do we HAVE to do this now?", so my final answer was this:

"Do we _have_ to? No, but it's like a bridge. Bridges have an expected lifespan when they're built, and they're supposed to be torn down and rebuilt after that. It's not a HARD limit, though. The bridge doesn't immediately collapse the day after its lifespan, but there are fault accumulating. Metal fatigue, erosion of support material, and other things. Commuters can't tell the bridge is past its lifespan, and they'll continue crossing it every day without issue. And then one day the issues will accumulate to the point that the bridge fails and people DIE. That's the situation we're in with this stack. It will continue to function just fine until the day it doesn't, and on that day I won't be able to tell you how quickly we'll be able to recover the application stack, if at all."

That FINALLY got through to him.

> The director of my department kept asking, "But do we HAVE to do this now?",

If someone says that something is a risk and we should address it, I don't expect a director to ask for a specific date the risk to become a disaster. Instead, he should just add it to some todo list and slot some time to analyze it and and budget resources. AKA, doing some "management" work. You shouldn't have to explain his job. You didn't need to learn semiconductors physical properties to know that storage can fail and you need to do backup.

Honestly, in traditional engineering firms it’s not the job of the mechanical engineer to quantify risks monetarily, and it shouldn’t be in IT either. It’s other people’s job to turn "without urgent repairs, we’ll have to put severe tonnage limits on this bridge or close it altogether or risk collapse" to the cost of inaction in terms of economic loss.

I also think it’s fair to expect that non-technical people learn some technical reasoning. They don’t need to be engineers, but IMO it’s completely ridiculous that we just let anyone who is business-adjacent off the hook for not knowing anything.

Business people should understand, at a high technical level, how their products work and what they’re actually asking to implement.

I’ve worked with many great business analysts and product people and consistently the best ones are the ones with the “engineer brain”. They might not know how to read even a single line of code, but they understand software products from their pieces. Those people consistently propose high-quality and feasible solutions. Other business people do not.

As developers, we are expected to constantly think on our feet and adapt. We learn new products and methods on practically a weekly basis. But for whatever reason, the business folk are not even expected to understand the product they help build. There’s such a large disconnect there between dev and business.

Well, you see the problem is that all of these stakeholders are engineering managers. If the director of infrastructure in the engineering organization can’t understand something like “move off static secrets embedded in hundreds of applications to workload identity” as a value proposition then I’m honestly not interested in massaging it further for them.