Just factor it into your estimates and make it a requirement to the work. Don’t talk to managers as though it is some optional bit of work that can be done in isolation. If you do frequent refactoring before you start a feature then it does not add a load of time as it saves a bunch of time when adding the feature. And helps keep your code base cleaner over the longer term leading to fewer times you need to do larger refactors.
In my experience when showcasing at the end of a sprint it pays to leave the visuals very unpolished and focus on functionality. Even if it’s trivial to use a UI library or other standard components. I deliberately make it look basic to help management / uses accept “it’s working but needs polishing”. That polish might then be me spending 10% of time on neatening UI, and 90% of time refactoring / fixing tech debt.
I often find myself writing scratch work within tests because it’s just the easiest way to get stuff up and running. Sometimes I’ll leave these as a way to show that my assumptions about a less used feature (by my team) of a framework works the way I believe it does. But it’s rare.
tldr
This is a tough one the bigger the project gets. Might be the toughest one.
It’s an ideal that’s only achievable when you’re able to set your own priorities.
Managers and executives generally don’t give two shits about yak shaving.
Just factor it into your estimates and make it a requirement to the work. Don’t talk to managers as though it is some optional bit of work that can be done in isolation. If you do frequent refactoring before you start a feature then it does not add a load of time as it saves a bunch of time when adding the feature. And helps keep your code base cleaner over the longer term leading to fewer times you need to do larger refactors.
In my experience when showcasing at the end of a sprint it pays to leave the visuals very unpolished and focus on functionality. Even if it’s trivial to use a UI library or other standard components. I deliberately make it look basic to help management / uses accept “it’s working but needs polishing”. That polish might then be me spending 10% of time on neatening UI, and 90% of time refactoring / fixing tech debt.
Re: trust frameworks
I often find myself writing scratch work within tests because it’s just the easiest way to get stuff up and running. Sometimes I’ll leave these as a way to show that my assumptions about a less used feature (by my team) of a framework works the way I believe it does. But it’s rare.
Sounds like bad management to me.
And sure, start your project flexible and adabtable from the ground up, but that needs planning and time!