> You're implying that buggy software has no impact on the bottom line.
I'm not implying that, and I don't think my manager was implying that either. I think rather there were 2 things going on:
1. It's often hard to connect bug-fixing to metrics.
A specific feature change can easily be linked with an increase in sales, or an increase in usage. It's much harder to measure the impact of a bugfix. How can you measure how many people are _not_ churning thanks to a change you pushed? How can you claim an increase in sales is due to a bugfix?
In your case, I'm sure some team at Microsoft has a dashboard that was updated the minute you used one of these features you bought Microsoft 365 for. How could you build something similar for a bugfix?
Bugfixes don't tend make the line go up quickly. If they make the line go up it often is a slow increase of regained users that's hard to attribute to the bugfixes alone. Usually you're trying to measure not an increase, but a "not decrease", which if possible is tricky at best. The impact is intuitively clear to anyone who uses the software, but hard to measure in a graph.
2. A ruthless prioritization of the most clearly impactful work.
I wouldn't have minded working on something less-clearly measurable which I nonetheless thought was important. But my manager does care though because their performance is an aggregate of all those measurable things the team has worked on. And their manager cares, and so on and so forth.
So at the end of the day, in broad strokes, unless the very top (which tends to be much more disconnected from triage and edge-cases) "doesn't mind" spending time on less measurable things like bugfixing, said bugfixing will be incentivized against.
I think we all know this impacts the bottom-line. Everyone knows people prefer to use software that is not buggy. But a combination of "knowing is not enough, you have to show it" and "don't work on what you know, you have to prioritize work on what is shown", makes for active disincentivizing of bug-fixing work.