Here's my best process for getting people in charge of subcomponents to agree with me. I had to do the same sort of thing in my first management job:
Know the Problem & Its Priority
As the leader, this is really your home turf. As the top of this particular section of the org chart, it falls to you to decide how overall resources should be spent and what needs improvement most urgently. Do take the position that the team leads have to convince you that a different issue is more urgent, but be open to being convinced, as this is a two way conversation. They see things you don't... you see things they don't... so you need to collaborate to figure out the real highest priorities.
But in the end, the call on what you do and how it impacts your team's obligations is your call. So you need to know:
the problem - what's really wrong with the code as it is?
the impact - why and how is it slowing down productivity? What brings you to this level of certainty?
the relative priority - how urgent is this? Is it important enough to cause a delay? Is it important that the change be consistent - in which case, when does the rehab of existing work happen and what gets shuffled to allow for that? Subordinates may not move forward if you can't give clear direction on this.
the ultimatum - Is this a case that fits into the "if we don't... then we can't..." model - then there's an ultimatum. Linking this to things your leads want to do is incredibly powerful. For example, most software developers want to release a successful piece of software, if you can't release or sell it without decent coding standards - that's a powerful motivation.
Have a Sketchy Plan
The sketchiness is as important as the plan... here's why:
A requirement from management with no thought put into it seems impossible. It's frustrating to think your management just makes random demands and hasn't put in any thought as to whether it's really feasible or how it could be accomplished. Having a plan shows that you tried to see a path to success.
It must be sketchy - not only will you be wrong in the details - because you don't know what your team knows - but being told in excruciating detail how to do something is demoralizing. These folks are in lead positions because they are capable of breaking down and executing on big chunks of work - let them leverage their capabilities. If they can't you have a team skills problem and not a "following orders" problem.
Chances are good that you will get the plan wrong. You'll be overly specific in places where you thought you had a clue and not specific enough in an area that someone on the team will call "absolutely vital". OK - well then the job of your leads is to help you refine the plan.
Refine the plan together
If they won't even try - ask why? Why is this so crazy? Why is it impossible? Why is there no value here? Keep going back to the problem you see and ask for better ideas. Maybe coding standards AREN'T the way to solve this problem or they are too expensive to be feasible. So challenge them to help you fix the problem. I have had very few cases of people refusing to admit that there WAS a problem. However, I've been corrected (many many times) on the fact that the problem didn't have the root cause that I believed. Another reason for that plan to be sketchy --- it gives you the opportunity to throw it out the window without much time investment.
The challenge is, they have to convince you. Don't accept a proposition just to avoid conflict. Ask questions and get alternate solutions vetted. Be convinced that your team is right before you agree.
Once you've got a solution, you can hammer out the actual plan - maybe it's fixing the plan you walked into the meeting with. Maybe it's creating a whole new plan together...
The goal here is to be just flexible enough to get the job done. Know what you care about and what you don't care about. Know what you're willing to spend money and time on and what is unreasonable.
Use one on ones as your backup
There are times when people will argue for no obvious reason. They may be overly emotional, illogical or simply non-sensical. This is when one on one meetings are a good backup. People will voice fears and concerns differently when talking to you privately. And sometimes smart people with good ideas won't voice them in meetings.
When you're getting truly inexplicable resistance, eliminate the chaos of group communications and take it to a one on one. It also lets you force feedback. There is nothing like asking a provocative question and then waiting in awkward silence until your person steps up and says something - particularly since your "awkward silence" may be your persons "moment of blessed relief" while they collect their thoughts and come up with something truly insightful. It's hard to pull this off in a team setting, since all team members add to the mix.
