Iyfjky

Question

I have been joined to new team and new project as a Team lead. This position is first time for me. I am leading 3 modules. I am above the 3 module leaders. I have identified few areas where improvement in the team are required including coding practices also. I would like to bring few changes into the team which are for team benefit and which will improve team's productivity. I am facing difficulty to convince these module leads about my new practices and change. Some times it leads to opinion conflicts and hence heated arguments. I don't want to impose those forcefully by using my authority and power. My specific question is,

How can I convince module leads without leading conflicts and bring the changes what I want into the team with out resistance?

Research that I have done:

I have searched in the workspace.SE. However I have found the post How to deal with an older team member resisting a team leader appears relevant to me. However it mainly talks about specific person who has different mind set. Here I have multiple team members who are resistant to invite change the way they are doing. Hence I believe my post is different than the one specified

Why are they resisting? Do they not recognize the problem you are trying to solve or do they not think your solution will resolve the problem? — Feb 13 '13 at 18:05
It seems to me that this answer applies to your situation: workplace.stackexchange.com/questions/9603/â€¦ — Feb 13 '13 at 18:06
@Sign: I am trying to bring new coding practices, organizing practices which are new to what they are doing. Every time I hear from them it is difficult to bring those to the team, and feels that it increase extra burden to them. — Feb 13 '13 at 18:19
Increase the number of beatings until the morale begins to improve! — Feb 13 '13 at 20:35
Resistance to Change will happen 100% of the time. Be aware that you never get rid of it, you overcome it. — Feb 13 '13 at 22:22

bethlakshmi 70.4k4136277 · Accepted Answer · 2013-02-13 22:13:35Z

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 & It's 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 ultimatim - Is this a case that fits into the "if we don't... then we can't..." model - then there's an ultimatim. Linking this to things your leads want to do is incredibly powerful. For example, most software developers want to release a successful peice 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 into 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 excuting 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 confict. Ask questions and get alernate 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 one's 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 blesssed relief" while they collect their thoughts and come up with something truly insighful. It's hard to pull this off in a team setting, since all team members add to the mix.

atconway 2,03621630 · Answer 2 · 2013-02-13 18:32:07Z

Making changes right off the bat in a newly implemented role does not always go over well. Change by itself it hard for people to digest, but even harder from those that are not trusted.

I have over the years always respected new management (leads, whatever) that survey the landscape 1st in their new role (so regardless if they are new to the company or a veteran) to assess the current situation before recommending changes.

I have also worked for the inverse where newly appointed individuals in power come right out making changes to try and prove something and it comes off as crass, tacky, and arrogant. Half the time I wouldn't see how they could know what changes to suggest without 1st understanding the specific environment for which they work in now. Are they just blindly applying policies and practices from the industry without knowing how the current team operates? (i.e. "We are all going to use an agile methodology with daily scrum meetings, these code standards, and these 2 architectures from here on out!")

A good leader will take a back seat and learn the new environment, team, and role (you said you are new to the role) prior to making changes. The single exception to this might be in the case where upper management brought you into this role with the introduction of, "Bob was brought in to this new position to change it up and clean up person x's deficiencies" However I think this is the exception as opposed to the rule.

Get to know your new role, team, and environment before rocking the boat. You will gain more respect and success with your team in the long run.

Making changes right off the bat in a newly implemented role does not always go over well - agreed 100%. It makes it very easy for anyone who is unimpressed by the changes to just say "this guy doesn't understand our work/situation/team/etc." You need them to believe that you do understand the current situation. — Feb 13 '13 at 19:56
+1 And also, ask your team what they think needs improvement. They might see things you don't. — Feb 14 '13 at 1:38
+1, good answer. First you gain your teams trust, then you can start making changes. — Feb 14 '13 at 9:04

JB King 15.1k22957 · Answer 3 · 2013-02-13 18:37:29Z

How to Win Friends and Influence People would have these suggestions that may be worth considering:

Twelve Ways to Win People to Your Way of Thinking

The only way to get the best of an argument is to avoid it.

Show respect for the other person's opinions. Never say "You're Wrong."

If you're wrong, admit it quickly and emphatically.

Begin in a friendly way.

Start with questions to which the other person will answer yes.

Let the other person do a great deal of the talking.

Let the other person feel the idea is his or hers.

Try honestly to see things from the other person's point of view.

Be sympathetic with the other person's ideas and desires.

Appeal to the nobler motives.

Dramatize your ideas.

Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing
Resentment

Begin with praise and honest appreciation.

Call attention to people's mistakes indirectly.

Talk about your own mistakes before criticizing the other person.

Ask questions instead of giving direct orders.

Let the other person save face.

Praise every improvement.

Give the other person a fine reputation to live up to.

Use encouragement. Make the fault seem easy to correct.

Make the other person happy about doing what you suggest.

The other point to ponder here is how well are you listening to the issues that the module leaders have about what you want to do? If they have concerns that are things you didn't know about the company that could well indicate why things aren't being done how you thought they should be done. If you are relatively new, then I'd consider the idea of trying to make suggestions rather than forceful commands that will just add more tension.

user8365 · Answer 4 · 2013-02-13 19:07:34Z

Start by asking what you can do to make their job easier. Anyone can jump into an existing team/project and find faults. You never know; they may want the simplest things: new computers, a better bug tracking system, flex-time, access to training materials, better coffee, etc. You'll have more credibility when you make your suggestions and they'll be more receptive if you've removed some of their obstacles and providing an abstraction layer.

Confidence isn't gained by asking people for their trust but by giving them yours.

I would vote this +100 if I could. People don't resist change, they resist change they don't believe in. Help the team with the changes they want to make rather than forcing those you want to make, they almost certainly know better what needs to change anyways. — Feb 14 '13 at 5:57

Simon O'Doherty 4,85111435 · Answer 5 · 2013-02-13 18:32:01Z

The keyword here is Team.

If you adopt the posture of "This is how we are going to do it, end of story" you are going to get push back.

On the other hand it is better to have clear objectives of what you want to achieve and allow the team to build the road to that objective.

So if you believe process X is flawed, then point the flaws in the process and issues it causes. It helps to have some metrics to back up your points. After that discuss with the team on how best to solve this.

At this point you can suggest how you want it to be approached, but don't force the issue. If someone shoots it down, then ask them to suggest a better option.

Suggest running this option for a fixed time to determine the metrics on it, then if there is no major improvement over the current system you will change it again.

If they are unable to offer a solution, then tell them what you suggested is the way to go, and you all will follow up in a few weeks to see if the approach can be refined or changed.

The point to get across that the team is looking for solutions to issues you have seen in the current processes.

In the cases where you have opinion based changes (eg. Source code formatting is always fun), get them all to agree on a fixed format and if they can't you set it then you do. If someone refuses, then you tell them they are free to write in the coding style they want, but they will not be allowed to check in until that code meets the standard laid out for the project. Any check ins breaking this convention will not be pushed into the build.

bethlakshmi 70.4k4136277 · Accepted Answer · 2013-02-13 22:13:35Z

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 & It's 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 ultimatim - Is this a case that fits into the "if we don't... then we can't..." model - then there's an ultimatim. Linking this to things your leads want to do is incredibly powerful. For example, most software developers want to release a successful peice 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 into 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 excuting 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 confict. Ask questions and get alernate 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 one's 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 blesssed relief" while they collect their thoughts and come up with something truly insighful. It's hard to pull this off in a team setting, since all team members add to the mix.

atconway 2,03621630 · Answer 7 · 2013-02-13 18:32:07Z

Making changes right off the bat in a newly implemented role does not always go over well. Change by itself it hard for people to digest, but even harder from those that are not trusted.

I have over the years always respected new management (leads, whatever) that survey the landscape 1st in their new role (so regardless if they are new to the company or a veteran) to assess the current situation before recommending changes.

I have also worked for the inverse where newly appointed individuals in power come right out making changes to try and prove something and it comes off as crass, tacky, and arrogant. Half the time I wouldn't see how they could know what changes to suggest without 1st understanding the specific environment for which they work in now. Are they just blindly applying policies and practices from the industry without knowing how the current team operates? (i.e. "We are all going to use an agile methodology with daily scrum meetings, these code standards, and these 2 architectures from here on out!")

A good leader will take a back seat and learn the new environment, team, and role (you said you are new to the role) prior to making changes. The single exception to this might be in the case where upper management brought you into this role with the introduction of, "Bob was brought in to this new position to change it up and clean up person x's deficiencies" However I think this is the exception as opposed to the rule.

Get to know your new role, team, and environment before rocking the boat. You will gain more respect and success with your team in the long run.

Making changes right off the bat in a newly implemented role does not always go over well - agreed 100%. It makes it very easy for anyone who is unimpressed by the changes to just say "this guy doesn't understand our work/situation/team/etc." You need them to believe that you do understand the current situation. — Feb 13 '13 at 19:56
+1 And also, ask your team what they think needs improvement. They might see things you don't. — Feb 14 '13 at 1:38
+1, good answer. First you gain your teams trust, then you can start making changes. — Feb 14 '13 at 9:04

JB King 15.1k22957 · Answer 8 · 2013-02-13 18:37:29Z

How to Win Friends and Influence People would have these suggestions that may be worth considering:

Twelve Ways to Win People to Your Way of Thinking

The only way to get the best of an argument is to avoid it.

Show respect for the other person's opinions. Never say "You're Wrong."

If you're wrong, admit it quickly and emphatically.

Begin in a friendly way.

Start with questions to which the other person will answer yes.

Let the other person do a great deal of the talking.

Let the other person feel the idea is his or hers.

Try honestly to see things from the other person's point of view.

Be sympathetic with the other person's ideas and desires.

Appeal to the nobler motives.

Dramatize your ideas.

Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing
Resentment

Begin with praise and honest appreciation.

Call attention to people's mistakes indirectly.

Talk about your own mistakes before criticizing the other person.

Ask questions instead of giving direct orders.

Let the other person save face.

Praise every improvement.

Give the other person a fine reputation to live up to.

Use encouragement. Make the fault seem easy to correct.

Make the other person happy about doing what you suggest.

The other point to ponder here is how well are you listening to the issues that the module leaders have about what you want to do? If they have concerns that are things you didn't know about the company that could well indicate why things aren't being done how you thought they should be done. If you are relatively new, then I'd consider the idea of trying to make suggestions rather than forceful commands that will just add more tension.

user8365 · Answer 9 · 2013-02-13 19:07:34Z

Start by asking what you can do to make their job easier. Anyone can jump into an existing team/project and find faults. You never know; they may want the simplest things: new computers, a better bug tracking system, flex-time, access to training materials, better coffee, etc. You'll have more credibility when you make your suggestions and they'll be more receptive if you've removed some of their obstacles and providing an abstraction layer.

Confidence isn't gained by asking people for their trust but by giving them yours.

I would vote this +100 if I could. People don't resist change, they resist change they don't believe in. Help the team with the changes they want to make rather than forcing those you want to make, they almost certainly know better what needs to change anyways. — Feb 14 '13 at 5:57

Simon O'Doherty 4,85111435 · Answer 10 · 2013-02-13 18:32:01Z