You do that by understanding some of the tradeoffs involved and showing that you understand that maintenance for the sake of maintenance is usually a waste of time.
* If it was causing some immediate issue or had a bug that needed to be fixed you could justify it that way, but all too often someone wants to refactor something to make it "nicer"
* Code that's rewritten is going to have all new bugs of its own, those are going to end up wasting more time than the time spent on the initial rewrite.
* A lot of programmers will get the urge to rewrite something before they fully understand the system they're rewriting (and thus aren't qualified to do so). You might be 90% through rewriting it to be nicer only to discover that the remaining 10% doesn't fit with your design. There was some design requirement that you missed which caused the initial code to be so convoluted and "nasty" in the first place, because it was solving a tricky problem in some non-obvious way.
* In a growing business requirements change all the time, maybe you'll spend 6 months now rewriting some system to be nicer, but 2 years down the line it turns out that that system was inherently broken and has to be thrown away and replaced. So it would have been better to commit 1 month of time over those 2 years to keep it on life-support.
* Speaking of resource allocation: Is now the right time to do this, you probably have a 100 tasks with manpower to accomplish 10 of them. Maybe this is better done in half a year when you have more hires, or not at all if some of those other 90 things are more important.
But finally, if it's really the right thing to do just do it incrementally as part of other tasks. If it's really code you're working on all the time, and fixing certain issues saves you time down the line just make those fixes along with other tasks.
* If it was causing some immediate issue or had a bug that needed to be fixed you could justify it that way, but all too often someone wants to refactor something to make it "nicer"
* Code that's rewritten is going to have all new bugs of its own, those are going to end up wasting more time than the time spent on the initial rewrite.
* A lot of programmers will get the urge to rewrite something before they fully understand the system they're rewriting (and thus aren't qualified to do so). You might be 90% through rewriting it to be nicer only to discover that the remaining 10% doesn't fit with your design. There was some design requirement that you missed which caused the initial code to be so convoluted and "nasty" in the first place, because it was solving a tricky problem in some non-obvious way.
* In a growing business requirements change all the time, maybe you'll spend 6 months now rewriting some system to be nicer, but 2 years down the line it turns out that that system was inherently broken and has to be thrown away and replaced. So it would have been better to commit 1 month of time over those 2 years to keep it on life-support.
* Speaking of resource allocation: Is now the right time to do this, you probably have a 100 tasks with manpower to accomplish 10 of them. Maybe this is better done in half a year when you have more hires, or not at all if some of those other 90 things are more important.
But finally, if it's really the right thing to do just do it incrementally as part of other tasks. If it's really code you're working on all the time, and fixing certain issues saves you time down the line just make those fixes along with other tasks.