That's because "bringing value to the business" is confused with "increasing quarterly profits."

The problem is poor valuation. All of the above can be process lubrication. The actual value comes from the process that goes on top of them. But if they're not in place, process implementation is going to have a lot of unnecessary friction, which reduces the eventual value of the core business process.

Some businesses get this, others don't.

For those that don't, it helps to explain the effects with real financial metrics. If your product is six months late and customers hate it because it's full of bugs, your process has failed to "bring value."

Exactly right. Building cowboy software with intense schedule pressure and best practices corner cutting it's likely to give you both late releases and bug backlog long enough to circle Earth three times.

There will be more bugs, and bugs will be more time-consuming to fix.

And the people who could rectify the situation get the message that their opinions/judgement aren’t valued and give up or go to work someplace else.

I think perhaps people don’t realize that “you get what you measure” has deeper layers to it. You get actions, you get people who are comfortable with those actions, and then you get friction to change this new status quo.

Yes, that's how that question is normally used. But it's a lie, those often bring value to the business.

If you are trying to answer it honestly, you will certainly get better results. But I am still not sure it won't bias you in a harmful direction.

> "We need to add unit tests" "That brings no value to the business!"

"Yes it does, it allows to make needed changes quickly and confident that they won't break other functionality."

etc.