[MalcolmDiggs]

I'd engage if you're up for a long-term commitment. The good news is: the problems you're experiencing are pretty standard; the bad news is: it's going to be a slightly painful road ahead to crawl out of that hole.

You're not going to be able to fix everything at once, there's going to be some amount of triage necessary, so you've got to prioritize your concerns. Figure out which changes give you the most bang for your buck. If you can prove your value by making a few small strategic changes, leadership might trust you to do bigger overhauls later on.

If it was me, my main concern would be that the engineers don't want to get their hands dirty. That's a really bad sign. Perhaps the biggest change you could implement short-term would be to flip that culture on it's head. Set some team goals around testing-coverage %, and documentation-coverage %. Encourage small teams to pick a small part of the codebase, refactor it, write tests for it, and write documentation for it. Reward them heavily for every little increase in coverage. Make sure they feel pride of ownership. Make sure they know they're not responsible for 13 years of code...just their tiny corner of it. The main goal is to stop the developers from tying their perceived self-worth/value to NEW features; that can lead to a "slap more lipstick on this pig" mentality. You want them to feel like investing time/energy in the current codebase is worth it.

Little by little your metrics will improve. Eventually the codebase will be stable enough (and the team will be productive enough) that you'll be able to say "okay, I want 3-5 developers to split off from the herd and start a ground-up rewrite". And that's where the real fun starts.