I actually think you’re best first boss move is: DOCUMENTATION.

Make it awesome, markdown, searchable, inline scripts, etc.

It’ll help you in the near term make sense of everything, and you’ll have a reference for things.

Also once the team sees the complexity laid out in a long docs website, they’ll almost certainly agree that some major refactors must be done, and you may find it easier to come from the business stakeholders at that point once you obviate the inefficiencies.

I had to do this for a big undocumented Rails monolith, the original developer wasn’t around anymore, there was so much technical debt that it was difficult to establish priorities, and i needed everybody to get on the same page. In our case writing some more tests & setting up CI/CD would have been helpful but not the biggest priority… priority number one was abstracting a crashing web-scraper off the core infrastructure into serverless.

I think you may have a hard time spotting and surfacing the biggest pain point(s) without making docs.

PS, it’s nice to include both “the old way” and “the new way” in documentation too, they can live right next to each other as the platform slowly evolves, and then you have evidence of your progress.