There is no difference how maintainable the code base is?
I've seen a very well-known business, which is regularly discussed on HN to grind to a halt and fall behind all of it's competitors in a very fast-growing and fast-moving space because it was built on a ugly spaghetti monolith developed by someone with PhD in history and almost no experience in engineering. And that's only the first of many examples I can think of.
You might also want to read Refactoring to Patterns, but the legacy book is more important to start with.
Oh, and you should get good at incremental refactorings, and at downscoping your improvements so that they become feasible and easy to sell. Or even not require any selling as they can be done as part of normal work. It is not the big rewrites that get done, it is the small improvements that take only a little time, so learn how to compound them.
By the way, getting good at the above points will over time also change your own priorities.
Also I would not frame it as playing them. That is the wrong mindset. You should be among for a high level of trust from their side and then playing them can backfire.