[cadamsdotcom]

The person with an issue should gather data and make a case for the investment. Sounds like they’re at a company where a vibes based case won’t fly, so it needs to be a business level case. These talk of resources saved/gained, ie. $$$ and time.

It’s not too different to a design doc. Design doc proposes a solution and details the investment needed to bring it into existence.

Main difference is the additional need to communicate why there is a problem - but most design docs restate this at the top anyway.

Maybe making a case for a change will show the org some previously untracked info, eg. time wasted. And maybe that was not known previously and surfacing it leads to rapid change. But be wary because maybe making your case will cause you to learn things you didn’t know. You might make your case and learn there are reasons for the frugality that you weren’t privy to and now are. But going through the process will either way better align your priorities to the org’s and vice versa.