This 100%. This line is an immediate nail in the coffin:
> This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers. And post COVID, budget is really tight.
I've been at a company not unlike this... several MLOC of VB WinForms that was total spaghetti, but a highly successful app that brought in a lot of revenue. In our case the majority of the dev team was in agreement that the situation wasn't sustainable, and at first (meaning when I joined the company) we had engineering leadership who mostly agreed. They brought in several rounds of consultants to evaluate the code base and announced plans for a major modernization effort. But the consultants largely agreed with the dev team that the code was in such bad shape that it effectively needed a rewrite. At one point we did a prioritization and t-shirt sizing exercise and came up with _30 man years_ worth of items in the "critical tech debt" bucket. Apparently engineering leadership was not aligned with the C level suite about how much money they were willing to spend on this thing, because within the next year there was 100% turnover of management in the engineering org. A couple of (talented!) people who had been hired for the modernization effort left first, then the other engineers who knew the code base well followed. Last I heard the company was limping along relying on Eastern European and Indian contractors to keep the lights on.
In short OP, you can probably get some wins; maybe some major process improvements like using source control, maybe more minor things like introducing patterns or frameworks so that net new code isn't a total mess. But there is zero chance that you're to do anything like a rewrite or major refactoring without leadership understanding that they're in an unsustainable situation and a willingness from them to invest time and money to fix it.
Seems so many of us have been hired at one of these companies. Same here. No source control. No bug tracker. No tests. There was no formal system for producing builds--releases to customers were simply copied from the workstation of whichever engineer could build it successfully today. There were so many bugs and crashes, it was hard to even get through basic customer use cases. There was no spec. There was no product roadmap or plan. Sales would sell something, then run downstairs and say "We just sold XYZ, you need to implement XYZ in the software blob somewhere!"
The CEO/Founder wouldn't even consider a refactoring or cleanup session, let alone a full or partial rewrite. Only features drive sales, and we've sold so many things we don't have, so all he wanted was feature cram. Every so often, a VIP customer complained about some major use case that simply didn't work, so only in those cases was bug fixing permitted. And in those cases, the VIP customer would get a custom bespoke build made with the bug fixed. I was hired because the last person of my seniority could not cram features in fast enough and gave up in disgust.
They only got source control because I came in on a weekend, unpaid, to do it. I lasted a little over a year. Bootstrapped founder (and sole shareholder) eventually sold the company for ~$150M. Sometimes it seems there is no justice in the world :)
> This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers. And post COVID, budget is really tight.
I've been at a company not unlike this... several MLOC of VB WinForms that was total spaghetti, but a highly successful app that brought in a lot of revenue. In our case the majority of the dev team was in agreement that the situation wasn't sustainable, and at first (meaning when I joined the company) we had engineering leadership who mostly agreed. They brought in several rounds of consultants to evaluate the code base and announced plans for a major modernization effort. But the consultants largely agreed with the dev team that the code was in such bad shape that it effectively needed a rewrite. At one point we did a prioritization and t-shirt sizing exercise and came up with _30 man years_ worth of items in the "critical tech debt" bucket. Apparently engineering leadership was not aligned with the C level suite about how much money they were willing to spend on this thing, because within the next year there was 100% turnover of management in the engineering org. A couple of (talented!) people who had been hired for the modernization effort left first, then the other engineers who knew the code base well followed. Last I heard the company was limping along relying on Eastern European and Indian contractors to keep the lights on.
In short OP, you can probably get some wins; maybe some major process improvements like using source control, maybe more minor things like introducing patterns or frameworks so that net new code isn't a total mess. But there is zero chance that you're to do anything like a rewrite or major refactoring without leadership understanding that they're in an unsustainable situation and a willingness from them to invest time and money to fix it.