Patrick McKenzie's advice[1][2] is good, but what if the costs, risks, or revenues aren't large enough? What if my real reason is to compensate for my personal weaknesses?
----
Example 1: Automated Tests -- I can say they can prevent bugs that harm the business.
But the real reasons I want a project to set up automated test tooling?
1) I find it harder to read a codebase without tests.
2) If I've written a test I can run, I find it easier to focus.
----
Example 2: Clear subteam ownership of product areas + a usually-empty UI to list production errors -- When I'm the dev on error-watch duty for a service, I want tools and team agreements which let me:
1) Glance at a UI listing un-triaged errors and see one.
2) Quickly see severity and which team owns that part of the product.
3) Pass to them.
4) Glance at a UI listing un-triaged errors and see zero.
I can say that a team habit to keep 30-40 production errors un-triaged makes it easy to miss a serious problem. But who would miss that error?
Me.
So, the real reason why I want prod errors in a Zeroable Inbox[3]: I find it hard to multitask. I am accountable to deliver code changes for my team, but I fail when I'm responsible for a list of 30-40 errors I shouldn't put elsewhere. I keep anxiously re-scanning for a new actually-harmful one.
----
I could inflate the business value or shame people about "best practices". What are better ways to persuade a team to adopt what are secretly just accommodations of my mental disabilities?
[1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/
[2] https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/
[3] Zeroable Inbox: A todo list with social rules to quickly move any item to some proper other place.