How can I manage stubborn team mates?

Question

I am part of a group of developers where I am the one person with the most "modern" web development experience. My team members are not totally clueless, the all come from a WPF/SilverLight background.

Quite often I have to mentor my team mates "unofficially", but occassionaly the odd argument does break out.

Yesterday I landed myself in an argument with one of my team mates where I found a piece of code that was essentially unnecessary. Long story short, a piece of JavaScript was intercepting a click event of a link and was ultimately redirecting to the same link without actually doing anything worthwhile. It thus made sense to remove this.

My team mate however, insisted that this was a necessary piece of code and that him and another team member "already agreed" that it should stay. I then went ahead and showed him a practical example of where this code won't even be hit (by opening it in a new tab). Even after seeing this he still insisted that it should stay. It was here where I grew impatient and upset and walked away in frustration.

So my question is, did I handle this situation incorrectly or could I have handled it better? How can I ensure that what I tell my team members convinces them well enough that what I am saying is in fact best practice?

Answer 1

If you want to be the mentor that directs how stuff are done and checks everyone's work, then be that person - tell them how it should be done and that's that. Rely on argumentative and assertive communication styles. (Like: "Because of Y and Z, we need to do X" or "I need you to implement X")

If you expect people to learn and adopt better practices then you have to behave differently - you have to adopt a more coaching style. You can't point out their errors or waste directly to them, you have to let them see it for themselves. You should absolutely not give them solutions, at most you should provide clues on how to get to a solution. This is time consuming, frustrating and very demanding on you. Ask open questions. Why did you include this code, what does it do? When is it activated? (But be clear when something is not meeting expectations) Rely on visionary and listening communication styles. (Like: "Our business results relies on a product that can do X, and there has to be a solution that can allow this, lets find it" or "In your opinion, what is the major roadblock in order to get a product that can do X?")

You can't do both, or at least, I have never met anyone that can both be directing and coaching at once. So if that person exists, accept his answer.

Answer 2

People are resistant to change. You have to get them on board with the change by listening to their concerns and answering their questions. You get them on board by having them involved in the change process and by giving them some of what they want to get some of what you want. You also need to think carefully before making a big issue of anything.

You want to make sure that the things you strongly push are critical to the success of the project and not get bogged down in less important items. All software has rough edges and places where it could be better. We can't polish all of them, there is not time.

So make sure you build a reputation for identifying the critical fixes and helping coach people as to why they are critical and how to avoid them in the future.

Coach people by showing them the issue, describing why it is a problem and what the impact is and getting them to suggest the fix and actually create the fix. It is critical, if you want these people to get better that you do not do the fixes.

If you simply rewrite everything you disagree with, all of the rest of the team will dislike working with you and you will get less and less cooperation and they will make less and less effort because they feel you will make arbitrary changes no matter what they do. They feel the changes are arbitrary because you haven't convinced them that they are not..

As to your specific problem, they probably resisted deleting the code because they were not sure what it might impact. If your team doesn't have good regression testing, then they may be right to be concerned when someone wants to delete anything. I know you tried to show them there was no impact, but did you just hit one screen or do a complete regression test? It may seem irrational, but people are especially reluctant to change code when they don't understand why it was there in the first place. This is in part because most of us have had unhappy experiences with people making changes and breaking stuff that used to work (or appear to work).

Another thing to remember is that you are never going to get all the things you suggest approved. Everybody wins some and loses some. You need to learn to lose graciously. This is especially true when the issue is something that is currently causing little or no harm. If you give in graciously to what they want at times, then they are more likely to give you what you are suggesting when it is really important that they do so. You have to build up a backlog of these sorts of things, so that people will think, "Hey ChrisC is usually fair and accomodating, if he is really concerned about this issue then it must be important." That is part of how you win the big ones - by being gracious about the smaller ones.

One thing you need to watch is your attitude towards others. You describe your co-workers as not totally clueless and your write up appears to insist that you are somehow better than they are. People will push back on arrogant people who think they are better than everyone else. This is an attitude you need to lose and lose quickly. Everyone in a workplace has something to contribute and everyone is better at some things and worse at others.

Never think or act as if you are the fount of all knowledge and so much better than anyone else. One thing I do is try to build up the confidence of those who need coaching. I also laugh at myself and tell stories about mistakes I made in the past, so that they know I got here by making mistakes and that you can recover from mistakes. It also makes them realize I don't think they are stupid because they didn't know something. There was a time when I didn't know it either. Another good technique is to catch people doing things right and praise that. If they know that you praise as well as criticize, they will take the criticism better.