I think you're not following what I tried to convey. It shouldn't have ever come to the point where incidents, outages, and bugs have become prominent enough t

I think you're not following what I tried to convey. It shouldn't have ever come to the point where incidents, outages, and bugs have become prominent enough to warrant a team. Either have kickass dev(s), although improbable, thus the second level: Implement mitigations, focus on testing, and have staff engineers with KPIs to lower incidents. Give them them the space but be prepared to let them go if incidents don't go down. There is no stopping of development. Refactoring by itself doesn't guarantee better code or fewer incidents. But don't allow bugs, or known issues, as they can be death by thousand cuts. The viewpoint is from not an engineer. Having constant incidents doesn't show confidence or competence to investors and customers. As it diverts attention from creating business value into firefighting, which has zero business value and is bad for morale. Thus, tech investment rather than debt always pays off if implemented right.