In my experience, it pays to be open with product managers and QA about what you are working on, how you are implementing it, what the risks and benefits are, etc. For example, it helps QA to focus their testing efforts on the areas that are most likely to be broken by a refactor. And having some understanding of how an app is built and where the problem points in the code lie helps product managers to develop a sense of how much effort a certain change might take, and reduces the chance that they will be surprised by some behavior in the app as the result of a change.
And if someone on the team wants to question me about the cost/benefits of a certain refactor and discuss alternatives, I think that is totally fair game. Same way that if I want to ask a question about the cost/benefits of a new feature and discuss alternatives, I feel empowered to do so. It's not about asking permission so much as it is about developing a shared understanding of the costs and benefits of the decisions that we make, and working together to optimize them.
On the other hand I remember on some projects there being real (HUGE) pushback from the client about doing anything that wasn't implementing features exactly as they define and "are paying for".
As soon as you declare that you are doing something "optional", it gets political, people start talking about it, it escalates to project manager, their bosses boss etc and the shitfight starts. Ugh.
The reason they're paying so much for it is that you didn't do the refactoring last time. Every time they refuse a refactor, all their future costs genuinely go up.
If they ask why the refactor is needed, why you didn't do it properly first time round: “You're constantly refining your business processes to satisfy ever-changing business needs; that's what I need to do to the code.”
The more experience you have with the reverse of that situation ("Dammit past koolba, what the hell were you thinking?!"), the more you value dedicating time to both doing things right and going back to progressively clean them up.
The real skill to learn is to properly isolate quick and dirty solutions so that they can be easily replaced down the road. The sausage factory does not need to be spotless on day one, just the entrance and exit doors.
This hits the mark.
I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.
I'm constantly thanking "myself from the past" when I go to implement some new feature and find that the surrounding code is clean and well organised and ready for that new feature to be easily implemented.