You're making this sound simpler than it is, I think. For the following discussion assume we're talking about management that is smart and wants the dev team(s) to succeed but is racing hard to hit various external deadlines and does
not have a technical background.
Inform them that after investing Y hours on
refactoring X, future development is expected
to happen M% faster with N% less bugs.
I've tried variations of this to sporadic effect. My elevator pitch is/was essentially, "let's devote 10% of our developer resources to making the other 90% more productive, rather than having 100% of our developers suffer these slowdowns and problems."
(I chose 10% because we had 30 developers at the time and generally had teams of 3 developers. So, one dedicated DX team...)
Do you have any articles, case studies, etc of how to express this to management that is generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?
What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?
The best thing I could think to do is have the team minutely log all lost minutes productivity caused by delays and inefficiencies that the proposed fixes could address.
But even that's tricky. For example, at one of my previous positions, the build pipeline could take hours and could randomly fail.
The only way to maintain any semblance of productivity would be to juggle 3-4 tickets at once. This was incredibly challenging, and productivity took a massive hit due to the frustration and context switching.
However, even if I had logged those experiences down to the minute, there weren't any literal downtime minutes. It was more a matter of juggling five tickets at once that should have taken one hour each, but instead they took five hours each because I was context switching faster than the Linux kernel itself.
New features can be expected to be developed,
tested, and shipped to production in S% less time.
This sounds good to
me, a developer but again, I'm not sure how to express this to management. It's not like "one feature" is some standard unit of measurement - the time to shipping "one feature" varies by orders of magnitude.
Scrum and its much-maligned "story points" are a possible solution here, as far as management is concerned, assuming both developers and management have bought into that concept and are using it correctly.