New Team Lead - How to deal with a resentful former peer [closed]

Question

I've been told that I am to be a team lead of an upcoming project. I've not ever been team lead before but the responsibilities are what you would typically expect, with revolving door of 3 to 4 other developers through the 8 or 9 months it takes to complete the project.

My problem is this: one of the developers who will no doubt be working on this project will be a problem. He has more experience than me, has called me an idiot several times in the past, and has told me that he has taken this job because he is a natural leader. He has expected to be promoted to a leadership position with every new project (which has not happened to date), and even once told me that I was to report to him, even though the actual team lead was under no such illusion. Moreover, I've both observed and heard from others that he is extremely unprofessional (watches non-work videos at client sites - with no head phones, dresses unprofessionally, comes to work late, makes inappropriate jokes, etc.) He took or attempted to take credit for my work or insights multiple times while I worked with him as a peer. My current team lead told me that she threw out 1/2 of this guy's code once he left her project because the quality was no good. I could go on.

My fear is that this guy will actively work against me, because he will resent having to report to someone that he considers an inferior, especially since I have been given this opportunity before him. I've successfully dealt with this type of personality as a peer or even reporting to managers like this in the past. I've not dealt with, or ever thought about, having to deal with this type of character who is reporting to me.

My question is: what kind of strategies can I use to effectively and professionally deal with this? Especially now, before it has become a problem, is there any way to cut it off before it gets out of hand etc. If anyone has a similar experience how did they deal with it?

Answer 1

The other answers I'm seeing here ("short leash!", "document everything!", "be professional!") are nice and all, and they're superficially correct, but they fall short in that they fail to consider the human aspect of the situation.

The thing is, everyone is a human, and humans are different, and their motivations and thought-processes and skills are all different. And while the somewhat algorithmic answers I'm seeing here are technically correct, they do not seem to take into account the nature of the way that human beings work and the nature of what true management can be.

You can't begin to solve someone's problem until you understand them. Which means, understanding their motivations. Which is why, in fact, good people management can be a lot more like psychoanalysis than you'd think.

Here's an example of how the thought process might go.

• Joe thinks he should be leader because he has more experience than me, but he's delusional.

OK, what does that tell us? Is Joe unusually concerned about status? Is he bothered by the lack of respect? Does he chafe at being called Joe instead of DOCTOR Joe in recognition by his PhD? Where is this insecurity coming from? How can you address it?

• Joe's code is not very good. Half of his code had to be thrown out.

Why? How? Is he sloppy? Rushed? Just not very smart? Is he cocky, thinking his code is awesome? Why? Is this that insecurity again?

• Joe is unprofessional and watches videos at the client site.

Again... why? Is it because he thinks he's a rock star, and should be indulged for wearing hoodies and watching collegehumor videos because his work is sooooo amazing? Or is it because he is not very self-aware, and does not realize the image he is portraying? Does he genuinely not GET what it means to be professional, or is he actively rebelling against the idea of professionalism? I'm not sure. The answer is there to be found.

How do you manage this?

Again, you start looking at the human/emotional problems, and address them as such. One thing I'm sensing strongly from the description you've provided is insecurity. It seems like Joe may be genuinely insecure, and he's hiding behind a veneer of arrogance. Where does that come from? Maybe he didn't go to a highly selective university? Maybe he's a VB developer in a world of C++ developers?

I don't know, you didn't tell me. I'm not even sure if insecurity is the issue here, because I don't know this guy. But bear with me for a bit--I just want you to see what it means to look at the human issues of management, not the superficial, "how do I enforce my will on this guy" issues of management.

So where would this lead us? Suppose you think about it, you have a few long conversations with Joe, and you decide that he is feeling insecure about something. How can you make him feel more comfortable? Will that make him happier and better adjusted? Maybe he needs some specific training to be great at something. Maybe he needs to pair program with someone who can encourage him. Maybe he needs to feel more loved. Actually, that last one is almost always true.

I've dealt with a lot of difficult management solutions, and the answer has always differed dramatically depending on the individual. A lot of times, they can't be fixed. But as a manager, you have to understand the individual as a human before you can start thinking about fixing them and fixing the situation and acting correctly in the situation in order to get the best outcomes.

So, here's what I recommend you actually do as a course of action.

1. Meet with his peers and former managers. Have a conversation that tries to get to the heart of what his human/emotional problems are. Is he immature? Just generally unintelligent? Unhappy? Depressed? Insecure? Arrogant? Emotionally unintelligent? All of those are different diagnoses for the real cause of the problem and all of them have different prescriptions.

2. Talk to him personally and privately, at length. Let him do most of the talking. Ask open questions. A good one is "How did that make you feel?" It uncovers a surprising amount of stuff. You would be shocked to learn how much better I got at managing human beings when I learned to ask people "How did that make you feel?"

3. Form a hypothesis of the root causes of his issues. Pick a course of action based on what you think the core problem is.

4. It may work. It may not. If it doesn't, that's too bad, but life is too short, and you're not paid to solve his problems, only the company's problems, so follow whatever advice you see elsewhere in this thread to get rid of him.

Once again, and I apologize for going on soooo long here: the other answers I'm seeing here are mostly summarized as "You need to be very strict." Well, being strict works well in one situation and one situation only: an emotionally immature person. If, indeed, his problem is emotional immaturity, that's the way to go. If his problem is depression caused by a cycle of learned helplessness, strictness will have the exact OPPOSITE effect than the one you want. Life, and management, and people, is just not that simple. There are many "diseases" that make a person be a bad employee and each one has it's own medicines. Some of them have cures. Some don't.

Answer 2

Your behavior will need to be, in this case, entirely professional. While team lead, you should refrain from any non-professional conduct involving this person so that they will only see you in an authoritative light. This means no discussions about sports, video games, etc. that are considered casual and will put you on a peer level with the others. This can be tough, especially if you've been peers with your new underlings up to this point, but it is essential for new leaders that have been thrust into such a position. You will be able to return to these intimate behaviors later, but early on it is important that you differentiate yourself.

Early in the project, you will need to establish your authority. Give very clear and direct orders for this person to fulfill, and in such a way that there is no ambiguity about your direction or intent - this person will either submit and all will be fine, or they will balk and you will have an open-and-shut case of insubordination to bring to your superiors as to why this worker is unfit for the position.

There can be no backing down. The moment you give in, you will have lost all credibility and authority with not only the problem employee, but the rest of the team as well.

Edit (incorporating Kevin's comment)

Be sure to keep impeccable documentation. Its tempting to give orders orally in meetings, but even if you do, you should follow those up with an email (which should be CC'd to relevant parties) or a task in your project management system that enumerates your expectations for that particular task. This is best practice anyway, but it has the side benefit of providing a complete and undeniable paper trail that you have been properly communicating with your underlings.

Edit (due to mass confusion)

My point about casual discussions (ie: sports, video games, etc.) needs to be taken with a grain of salt. I'm not suggesting that you shut down all non-work interaction with your office mates entirely, nor that you shun them when they try to discuss such things with you. Rather, such interactions need to shift into an appropriate supervisor-employee role, at the very least until your underlings have adjusted to you in that particular role.

Answer 3

I've been in the same situation many times, and the most effective method I know is removing him from the team. No serious company can afford conflicts in teams. According your description, he is not a team player.

If you really need to keep him, here is what I suggest (this apply to any team member):

• Don't consider him differently than the other team members. One of the biggest mistake is to consider him differently. This works particularly well with arrogant developers.
• When he makes you feel uncomfortable, angry, anxious, excited, [put any emotion here], remember that every thought you will have at that time will be biased by the emotion. It's better to wait for the emotion to disappear before analyzing and making decisions.
• When a conflict arises, try to take him in a face 2 face meeting. Don't do anything in front of the team.
• Listen to him actively, by asking many questions. Seek to understand him before trying to be understood.
• Ensure that decisions are made by the team with him included. His opinion should be as important as other team members opinion.
• When you are wrong, accept it. Sometimes, he will be right, like anybody.
• Be genuinely interested by him. This usually unlock difficult people. He must understand you are not a threat, but an ally.

Answer 4

Let's see... some good answers have already covered a few on my list:

• Be professional - a no brainer anyway, but avoid, at all costs, judgement calls about your potential problem employee. If you really need to vent, ask your boss for the opportunity to talk through the issue, don't ever let his problem or your problem impact how you interact with your team.

• Be direct - give work, expectations and deadlines. Involve him as much as you would any other employee and stay willing to listen to ideas - but make sure you are impeccably direct. I think one the tricks with problem people is that it's easy to say "do X task by Y date" but there's another set of elements of how you want the work to be done - how much bragging? how much testing? how much is due diligence vs. over engineering?

  • Sadly, this will also have to include being direct about his behavior (dress code, watching non-work videos, off color humor) - as his day to day manager it is not just your right, it is your duty to help the rest of the team survive this guy, and that means setting the expectations point blank.
  • Being direct also means calling him on bad behavior when it's happening. You are actually in a good position as you already know some of his problems, so you can be on alert when he repeats previous problems. The best time to halt a behavior is when it's happening.
  • And - being direct also means giving feedback on work - when you review his code (which you should do with some regularity) and find that you'll need to throw out 50% of it, then his job needs to change from writing new code to fixing code to meet your expectations. Not your minimum expectations, either, the expectations you have for everyone. And that doesn't mean a delay in deadlines - if this is something that should have been done right the first time, then he needs to do the work and keep on schedule.

• Keep records - Personally, I like the giving tasking via in person conversation, since it (usually) reduces tension and improves shared understanding. But there's no harm in leaving the meeting and following up with a friendly email reminder to everyone. The best part is that once it goes through email, it goes through whatever corporate email scrutiny and backup processes you have, which means it's part of a more legal record.

• Remember - you own team health as well as the technical solution - A lot of the behaviors you've pointed out are problems that can be counter to a healthy happy team. One of the things to think about as you work on this problem is that you are not just the owner of the technical solution, but also the productivity of the team while they build the solution. It can often be hard when you think about going head to head with someone - as if the situation is innately adversarial. I've often made much better headway when I think of the problem behaviors as something that is hurting the whole team - then I can look for ways to change the context and isolate the problems so that I don't have to go head to head with someone - instead I can develop a team that is so healthy that it fights the "virus" in its midst. Probably my biggest guidance here is work on overall team trust - if the rest of the team trusts you (and vice versa) it will be very hard for the bad behaviors to get much play or to do your group much harm.

• do have 1 on 1s - not just with your problem guy, but also with other people on the team. IMO, team meetings are for status that everyone needs to hear, and problem solving. 1 on 1s are for the things no one wants to get into in public - what's going well, what's going bad? What does a given employee want most of the job? What's missing? What's great? This is a good way to build a healthy team, and also a good way to address problems 1 on 1.

That's all the really good for all purposes advice. Here's the way more political and harsher underside of management:

Know the blame lines

What exactly is the direct chain of command that says whether this guy stays or goes in the company. In other words - who gets the blame for a problem person remaining a problem that the company is paying for? With the first line of technical leadership, you cannot automatically assume that the blame line involves you - for several of my first leadership situations, I was not the person who approved vacation time, raises, bonuses, employee evaluations or disciplinary action. Often on short technical projects that responsibility can fall on a bigger section manager and not on the day to day technical lead. Know this guy's blame line. Get to know at least 2 tiers of those individuals - develop a collaborative relationship where you are checking in about the more trivial day to day stuff, so you already have a point of trust if you need to bring in problems.

Learn the company's employee evaluation process

Most importantly - is it you that will be the frontline reviewer of this process? If not, who do you give feedback to, and why isn't it you? But also - what ratings and guidance has this guy received in the past? I'll bet ya that he's already gotten some pointed feedback about his behavior in the past, and most companies keep records on this. Get the records, know what he's been told.

One of the roughest parts of engineering management is that due to the speed of projects, there is sometimes no longevity of management, so a problem person can get bumped around between managers and each switch is a chance to revert to old behaviors. You don't have to keep this a secret - if you end up leading him, you can sit him down and say point blank - "I checked up on previous evaluations, and I know you're working on improving X, Y, and Z - I expect you'll keep working on those skills and behaviors on this project and I'm ready and willing to help you improve here." Obviously use your own words. What I just wrote makes you sound like you're impersonating a human being. :)

Talk to HR and learn about the process of how someone gets fired

Yes, this is truly a horrible process. There is no good way to fire someone for being incompetent. No matter what the process is, it will trump any other process in terms of horribleness.

The only thing worse than knowing about the company's termination process is NOT knowing. Not knowing will get you in plenty of trouble, knowing will let you prepare yourself in case you have to go there.

A legally minded company will have a very formal process and your HR should be prepared to coach you. This does NOT mean that you should step up ready to fire the guy - this means that you should know what it takes. There are often some truly bizarre (to a sane person) nuances to how this works, and forewarned is forearmed.

Keep your own records

You do NOT owe your employee every thought that crosses your mind.

Keeping records in general is a good idea, because it lets you remember the good (and bad) stuff that EVERYONE on the team does - so when it's time for the fun part of management - setting bonuses and other cool rewards - you can do more than give a generic gift. One of the best things ever is having your management give you a bonus and a note that specifically calls out some of the awesome contributions you made to the team... I guarantee that employees remember the cool note much longer than they remember how much money the company forked over.

And, sadly, having records of issues for a problem employee is often part of the firing process. It's also part of the sanity-keeping process. The human mind likes to forget pain and suffering. It's very easy at review time to conveniently forget just how many issues have come up, and when you do have to have a painful conversation, it's worse if you are not grounded in some details of specific issues and patterns.

Use your management chain

When I was an individual contributor, I was happy to stay as far away from management as possible. Once I became a manager, I realized how invaluable a good working relationship with management can be. Of course it totally depends upon the competence of your management - but often higher levels of management are composed of people with plenty of tricks in their tool kits. They know the culture and they know the biggest red buttons in the company - so they are in a good position to give you help. Also - if you are sharing your grief on a regular basis, they know where you stand in case of any political hijinks.

Do not assume that no sign of trouble means no trouble

I could be completely washed up, because this is just one snap shot in time.

But what you describe is a series of very defensive behaviors that seem to be coming from someone who has some serious problems with work behavior. The fact that you have been promoted and he hasn't tells me that your management is smart enough to realize the issues on some level.

Most disciplinary action is taken in private one on one sessions. Calling someone out in public rarely does any good - and when it comes to the very serious "shape up or ship out" discussions, they are ALWAYS in private. Which means that no one who is NOT in the direct management chain should be privy to these.

This is my biggest rational for most of the other advice -- it sounds to me like not only do you have a guy with some problems, but that you have decent enough management that problem-fixing may already be underway, and mostly what you need to do is establish how you fit in to the problem-fixing cycle and then continue the activities as needed.

The final hopeful finish

It's not unusual for people to change radically when dealing with a manager from dealing with a peer. All my cautionary advice may be pointless as it very well could be that this guy will be sweet as pie when you take the lead role as you have now suddenly become "The Boss". Different people deal very differently with authority - for signs of how this guy is programmed, check out how his current boss deals with him.

In fact - one of the best tricks is to watch other managers. I'd bet money that his current management does some stuff great and some stuff absolutely badly. Look for the good tricks, and keep and eye open to blind spots in your current management hierarchy - be ready to try new things but also be aware of what works and therefore doesn't need to be fixed. :)

Answer 5

You are in a tough spot, because if this guy wasn't fired yet then he either has political importance or you work for an organization that will never fire people for performance.

Pray it is the latter, that is much easier to deal with. Politically important troublemakers like that can ruin you despite ALL of your best efforts to be professional, cover your *, and document EVERYTHING. I have seen it happen. The paper trail means nothing when politics are involved.

Be Professional - Don't try to be friends with anybody on the team. Act as if you are on a mission the entire time and do not show favoritism.

Protect yourself/Document EVERYTHING - Don't make silly mistakes, you are being watched. The sharks are attracted to blood in the water. Also make sure that you fully document all decisions, email trails, discussions and team consensus. When you get dinged on something you will want to pull up that email from 6 months ago.

Answer 6

Just keep your humor. If you can't get rid of him, the worst thing you can do is let him bother you. He's not a big deal. He wants you to be nervous. He wants to be "that guy". Let him be "that guy". Just keep your good humor and always look on the bright side.

Handle him. Don't let him handle you.

Answer 7

You have had good advice, my answer aims to complement what others have said.

Remember that you are in charge, so you set the parameters at all times. This may sound very strong, but with someone who is going to push on your boundaries you are going to need to make those boundaries clear and unambiguous, leaving no space for someone to undermine you. If everyone understands clearly what is expected of them, it is very easy for you and them to know if they are doing it right or not. This will apply to your whole team, obviously, but as a leadership approach it works.

This also means that ultimately as you will be considered responsible for the project as far as your managers are concerned, you have the final say in how things are done. That doesn't mean you don't consult the whole team or whichever members are your experts in a particular part of the project before making a call on something, but as it will appear to everyone you are reporting to that the decisions made are yours you had better make sure that they are.

There is a term we have which is "firm but fair" - that is a good way to treat everyone in your team - with clarity, consistency and transparency, but acting in a way that does not open the door to people questioning your leadership or their standards dropping without very good reason.

Professionalism is typically unemotional, so stay calm as far as possible. Don't buy into other people's emotions either. Understand them, but don't allow yourself to get caught up in them.

Think about likely situations that might turn into a confrontation and see if you can find a way to head them off. If someone has a lot of experience in a field, they may well feel that their experience gives them the right to take some control over what you are doing, for example, but you can narrow it down - in what way does their experience fit them for control? Would it not work better if they shared the relevant parts of their experience with the rest of the team? Normally this will ultimately come down to a specific complaint and by narrowing things down to the exact issue they have, you can probably address it in a way that avoids bad feeling.

Where possible avoid one on one meetings.

When everything is going smoothly, make sure life is as good as you can for everyone on the team.

Answer 8

I agree with Joel, all the answers are on the same frequency, everyone is giving suggestions as peers, not as managers.

Before dwelling in the human side of the problem, I think there's a meta-question you have to answer yourself.

As the leader of the team, your responsibility is for the team to deliver, on time, on budget.

The meta-question to be answered is, you wanna do it with this guy, let's name him Dick, or without him?

You wanna make it with Dick

This will make you sweat...

• You need to understand what motivates him
• Need to give him tasks suited to his skills
• You will understand what skills are missing, and coach him on those
• You will spend a lot of time arguing and positioning, which may damage your position as leader in the eyes of others.
• If it doesn't work at the end, the team will lose.
• If it does work at the end, your energy will be drained, but there's joy in helping someone be a little bit better.

If you have the time and the energy, take the path of the enlightenment, you are made from the battles you fight, not from the battles you win. Risk losing.

You wanna make it without Dick

This I call, damage control mode...

• You won't put Dick on the critical path
• Dick won't have sole ownership of any piece of the project
• The priority is to keep the guy busy and the project moving, not to keep him happy, not to keep you safe.
• You will need to prevent Dick from undermining the morale of the team:
  • Recognize loud and clear the good performers.
  • Make everyone to understand the deliverable of everybody.

Because life's too short to work with Dicks.

Only you know if it's worth it.

There is an alternative path if you have someone in your team who does get along with Dick, you may proxy through her.

My two cents.

Answer 9

While I very much like both Pierre 303 and Jarrod's answers, I would also suggest keeping track of his code submissions.

If you are a strong lead, you may be able to mentor him into being a successful teammate. Sometimes being straightforward with him and actually tell him what others have said behind his back (finding the most politically correct way of course, without mentioning anything along the lines of "well so and so said this about you") may open his eyes and make him either 1) look for help in correcting his ways, or 2) look for work elsewhere.

However, if all good intentions fail, then keeping track of his submissions (you are using version control I hope?) will give you clear indications of his intentions. If he's obviously trying to sabotage your project, approach him about it. If he continues or denies it, bring your proof to upper management. Sometimes bad apples just have to be thrown out to allow a project to thrive.

Answer 10

Establish boundaries and expectations

First off before the project even starts you need to put this person in his place right from the start. You must clearly state in a private one-on-one setting your expectations. Start of by stating what he can expect from you. Then state what you expect from him. Do not let interruptions take place while you are speaking. If interruptions start to take place be firm in your tone and express that you will not tolerate that type of behavior. Follow this up with "Is that understood?"

Start With A Short Leash

You must keep this person on a short leash. You and only you decide when and if you extend the leash. By keeping him on a short leash from day-1 he will get used to it (eventually). He may not like it but he knows the boundary. If you give him a little more leash as his attitude improves he will adjust to that new boundary. If he gets out of line you just retract the leash back to the original short length. He may not like it but it is something he is already familiar with.

If you start on a long leash and then try an real the leash in, the resistance will be much worse.

Under No Circumstance Tollerate Insubordination

Make sure you make it known you have been put in charge and will not tolerate any insubordination. Make it clear that he can approach your supervisor to discuss what ever is bothering him but he must inform you and you will set up the meeting.

You need to discuss this with your supervisor ahead of time and the two of you need to be in synch on this. If he approaches your supervisor without you setting up the meeting, the first question the supervisor should ask is... "What did aceinthehole say about this?" This is very important.

If he challenges you in a group setting pinch it off immediately. Say something like, "This is not the time to discuss that, we will talk about it after this meeting." If he continues to push the issue then you must...

1. Ask he stop talking... "That is enough, I told you this is not the time."
2. Bring the meeting to a brief hault and excuse yourself.
3. Escort this person to a private setting and deal with the attitude. (keep this short)
4. If he cannot return to the meeting without being cooperative and cordial then send him away. Tell him you will discuss this after the meeting. Retun to the meeting by yourself.

Do not let him bully you in front of the other team members.

Ask Your Supervisor For Guidance

Don't be afraid to ask your supervisor for guidance on how to handle situations you are not comfortable with. Do this in a private one-on-one setting. Don't worry that you will appear weak in front of your supervisor, you will not. Your supervisor will more than likely appreciate that you asked for their assistance.

The same holds true for you. let your team members know that you are willing and open to discuss issues with them and that those issues will remain confidential.

Answer 11

Some good answers here but for me there's a fundamental issue that nobody has addressed: you've decided what this guy is going to be like on your project before it's even started; you're judging him on something he hasn't done yet. While it's very much worth having a strategy for dealing with problems you might encounter with him in your back pocket, it's ESSENTIAL that you give him a fair chance and treat him the same way you do the rest of the team. Don't single him out, don't assume it's going to be a disaster, do think positive.

If you convince yourself that your project is doomed to failure, whether it's because this guy is on the team or for any other reason, then you can pretty much guarantee that it will indeed fail. For a project to succeed you have to believe it is going to, you have to believe in yourself and you have to believe, and trust, in your team. Above all you have to be fair.

Answer 12

Could you ask your manager or the project manager to assist you in dealing with this problem individual? That would be my suggestion as you may need backup for when he does jeopardize the project which could well happen. If you don't make sure that these other managers know what is happening you may get blindsided as I'd imagine the problem individual may talk a good game to management which is how he has stayed where he is.

Answer 13

Most answers here are focused on accountability, which in my mind is setting the person up for failure, or at least there is an assumption that the person will fail. All may very well be the case in the end, but I do not think that entering into a situation presuming failure will create an atmosphere in which success is likely.

To Joel's point - remember first and foremost that the person is human. Do as he suggests: consider the person, their state of mind, and their needs before taking action one way or another. What Joel underscores is that management is never prescriptive - there is no single way to manage people, or even a person. So yes, consider the person you are managing, before you manage them.

But also consider the situation they are in. You may find for example that a person who performs exceedingly well in one context, might perform poorly in another, and in this case vice versa. The fact that this person does not perform well (in a professional or social context) does not mean they can't perform well, just not well under the circumstances.

So, consider their state of mind, and consider the circumstances they are in -- circumstances mind you that might have been around for a very long time. The key in my mind is how can you help this person be and feel successful? Success, no matter how small, will boost confidence and probably have other positive effects as well.

To make them successful, perhaps what you can do is ask more directly what you can do to help. Perhaps it is running interference with other managers, perhaps it is getting the person out of meetings, perhaps they just need help finding and staying in their zone. Or perhaps they don't know what they need. In that case, it is your job to guide them. They might be resistant. Focus first on giving them small tasks that they can accomplish and for which you can give very specific direction. This might feel like micromanaging, but believe it or not, there is a time and a place. This might be it. When they succeed, praise them. Recognize them in front of their peers. Send an email to your manager and cc them. Make them feel valued. As their confidence picks up, slowly back off on the praise and direction you give them.

Perhaps an analogy could be drawn to learning how to ride a bike, or how to snowboard for the first time. If you are left to teach yourself, it is quite likely that one bad fall, or a series of them will produce a feeling that you can't do it. That you are incapable. You might never say that out loud, but what you will do is direct a lot of anger at the equipment and the people around you. In order to learn how to obtain those skills however, you eventually need to receive instruction in the form of very specific, very rudimentary advice. A good teacher will take you back to square one, help you center yourself, help you reset what you have learned thus far, and then take you through the process of learning again, but more slowly. They will praise you a lot. Eventually you will be able to do by yourself, and when that happens, they will instruct you less and praise you less, because your success in learning will be motivation enough. As you succeed you will be less angry, and so on and so on. You can see how this works right?

Interestingly, and not to abuse the metaphor, you can see how if after you have achieved mastery at snow boarding, someone comes to you and asks you to ski, the process of frustration and anger can start all over again. Why? Because you find yourself in a new situation that requires skills you don't have yet. In comes the instructor to help put you on the right path again.

So my advice? Be patient, consider the person and their needs, and manage to the situation as much as you do to the person.

Answer 14

The best approach is isolation. Assign most mission critical parts of the project to core team, leaving the rest for him. You can even come up with some useless feature idea, just to keep him ocupied. If he produces bad code, you will produce bug reports/cleanup requests. Just make sure that whatever he does has very little affect on the rest of the system. Yet somehow, you must convince him, that what he does is extremally important and you will fail if he won't deliver quality code.

This may seem like a total manpower waste, but surprisingly is quite contrary. The problem is that such person not only isn't helping. He is also producing turmoil/problems or killing productivity in other ways. If you won't isolate him, your team and your project will suffer.

Answer 15

My suggestion is to be very transparent with him. Be professional. As a team i understand that others will back you up if this guy tries to harm your project.

Answer 16

Remember that human relationships trump just about everything when it comes to human interactions. People behave irrationally, but they respond to their own emotions. You can use that to your own advantage -- not by being manipulative, but by being responsive (almost the same thing, i know, but the difference is in how it makes people feel).

First of all, document everything -- all instructions, all responses, all interactions. Don't make a big deal about it, and don't include make the record look subjective. You want to be able to show it to anyone without making them feel defensive.

Find out what people want, and use that help them take appropriate action. Find out what your uncooperative co-worker would like out out of the project; what the picture of an ideal environment is in his head. Once you know what he wants, you may be able to tailor the working environment to accommodate it without disturbing everyone else. Often just asking someone what they want is enough to change their attitude.

Don't invoke your authority if you don't want a fight. Don't give an ultimatum unless you want them to be resentful. Don't back someone into a corner unless you want them to snap at you. Sometimes you want someone to get angry and leave, but that's not usually the optimal outcome. You're "in charge", which means you're responsible for setting the team's direction. But don't use that as a club to beat others down and then expect them to help you. In the end, you have to make the decisions, but you're better off making them feel like it was their idea.

For most people, being in charge is a means to an end, and not the goal. They want to be in charge so that they can have what they want. But if they can get what they want without the responsiblity of being in charge, then they'll gladly work for someone else. Helping someone want what they have is just as good has helping them have what they want.

And finally, if someone is a poor fit for your team, then they shouldn't be on the team. If they don't have the skills for the task at hand, then get them off your team.

Answer 17

There are some key points that I would address.

I consider it a failure on my part when a member of my team fails. There will almost always be someone on your team that poses a challenge. It is your job to make sure that your project succeeds and your team succeeds. You appear to have an attitude of "This jerk is going to ruin my project". This can be a self fulfilling prophecy. Change your attitude towards him. Find his strengths and leverage them.

Treat him with the respect he desires. Your attitude towards him will affect how your team views him. You can poison your team against him or you can give them hope. If you poison them you will get what you expect. If you provide hope then there is hope. Even if his work forces you to marginalise his efforts you can keep your team spirits high which will improve the entire experience. And this does not mean you should treat him like he is above anyone else on the team. Just treat him as an equally valuable member of the team (Even if he is not).

Use Build, Break, Build method of coaching Start by complementing on of his accomlishments(preferably something signifigant and recent), Then point out the problem, explain your expectation going forward, and get him to commit to making the change. Then build him back up with your belief in his ability to make the correction and continue to function as a valuable member of the team.

Set High Standards for the whole team Do not accept marginal from any of the members of your team. Make sure your expecations are clear and unwavering. Do not cut slack for anyone or set a higher bar for anyone. This can be percieved as favoritism. Better to the jerk with unrealistically high expectations of the team, than the guy that lets his favorites get away with murder (Even if you don't). The former can help your team bond together to get the project to work. The other will create dissent and demotivate.

Encourage Peer Mentoring Everyone on your team has a strength. Leverage those strengths to help your team grow. Have your team seek out the assistance of other members of the team to refine or improve their code. But do not assign someone to look over someone elses work. It will be more productive to have your team working together and asking each other for assistance in improving than critisizing each others work.

Talk to the teammember's manager He is still employed there so someone sees something in him. Otherwise he would be in the datacenter writing migration scripts. Find out what the manager has found to be effective for motivating, what (s)he feels his strengths are, and how they would like for you to help him as his lead.

Throw out your old judgements and bias They serve no one least of all you. You are in a different dynamic than you were previously. Give him a chance to show you his value.

Answer 18

I personally think the right course is probably the hardest one to take. Be honest with him and let him know what you're feeling. Most people who are jerks aren't trying to be jerks, they just don't know they are, and feel horrible when they discover that they are. If you approach him in all humility and respect and let him know that you think there might be feelings of unfairness on his side due to your new role, I'd bet his response will be of equal respect. Like Joel said, he's just a person. Think about how you'd want to be treated if you were in his shoes.

Answer 19

You need a Mediator / Judge

(from a Soft. Dev. plus H.R. / psychology guy)

You cannot solve this problem by yourself. Whatever you do, "its already out of your hands", you require a person higher on your company with more authority.

I have seen several cases like that. That employee won't follow your guidelines, it doesn't consider you as "the boss".

Besides, even if he is right, and he should be given that job position, he must understand it wasn't your decision who is going to be the project manager.

In theory, it should be someone from Human Resources, but, in practice H.R. people try to be too much nice, so better find an admin. with negotiations skills, otherwise that guy will break your project.

Answer 20

It seems that no one recommended the author to think about what it cost to be a team leader. Obviously being a team leader limits your ability to program, learn new programming stuff, hack a lot and become more and more professional developer. That is because a team leader receives a new responsibility - to help other developers, fix their bugs or just point them what to do / what to fix. Then all these endless meetings. I can not tell for an author, but for me this would be a perfect step(may be even with 15-20% bonus in salary) but in a wrong direction. Like getting extra 20% for converting my job from passion to something where I never wanted to be.

-Dont take this responsibility. Someone should be a leader, someone should be a cleaner in toilets,others destiny are even worse, but you can be a programmer and just increase your hourly rate / skills day by day. Working with computer and working with people are skills which are rarely both on a high level for one person.

-Other programmers should not affect you. They can go to job nude, watch their porn videos,do other crazy stuff - but that is their lives and your boss pain. Just demand such work conditions, like working from home or in an izolated room, where you feel yourself perfect and ready to code

-In case your work on a project and you are blocked by someone from your team - write them politely email with your boss in CC. This is bad - "Hey, I am waiting for your functions str2int for 2 weeks, so I just don't do anything at all!". This is what I do - " Hi, xxx. It seems that you can not deliver the function str2int to me, so I just replacing it with my own implementation, which is slow but mostly works. If you are going to add it - just confirm to this interface ".

I hope that non standard answer may help an author, or someone else to do his job well and remain happy.

Answer 21

A good solution requires an in depth understanding of the working environment. The fact that this guy has gotten away so far without being checked reflects badly on the situation. It is very easy to deal with such people provided you are supported by the management. Lousy management would be an even bigger concern than that guy.

One strategy I've used successfully in the past

• Make him responsible for something, and hold him (and everyone) to his responsibilities. A weekly/daily status check meeting, with proper visibility to upper layer would make sure he does not fallback and enjoy trouble-making while leaving you to "handle" as a team-lead. I used to make co-leads and made sure they are the ones to send me a daily status check of all members.

• Do peer performance reviews, like every member of team answering basic question like how satisfied he/she is with peers. This is sort of a political tactic but if he's to feel pressure from everyone and not just you - he may just breakup or behave accordingly. Needless to mention, you can always pass on bad evaluation to upper layer.

I'll suffice with these :)

Answer 22

most answers i see, i think, focus on the wrong problem.

i can't help but think that the OP is disillusioned, this is only half the story

leadership is hard, i can't help but wonder that if i was in the poster's shoes, the situation never would have evolved to the point that a peer disrespects me

developers don't "report" to the tech lead, they report to managers, "tech lead" (in the sense of the guy who knows the most on a team of 6 devs) doesn't get asigned on healthy team, a healthy team organically self-organizes and people naturally grow into ownership of functionality. that teams often don't self-organize is a culture problem at some bigcos for various off-topic reasons, see jurgen apello's writings (noop.nl) for further reading

Answer 23

Give him the dirty job -- writing documentation.

You should soothe his ego at the same time by explaining why HE is the best person to be doing it:

• Documentation needs to communicate the big picture, and naturally none of the other developers are as capable of even seeing the big picture, nevermind explaining it. Only an "architect" like him can tackle it.
• Reading code requires understanding any kind of code the other developers write, in all sorts of styles, and involving all the tricks of the other developers combined. Only an "expert" like him can tackle it.
• Documentation is very important to project success, so naturally you want your strongest team member -- him -- to take it on.

Or stick him with writing test cases; the same arguments can be made.

This has multiple upsides:

1. He won't be checking in any code.
2. He'll have to read and learn from the code of the other developers.
3. If he doesn't understand he's been had, great.
4. If he does understand he's been had, he can't really complain without also admitting he isn't the omniscient superhuman programmer he's been claiming to be.

Most likely, he'll be posting a topic here about how his team lead repeatedly ignores his suggestions about how to improve the code... at which point none of us will believe him (we've had those types before) and will tell him to focus on reading and understanding a wide variety of code because that's a core skill for someone writing documentation.

Answer 24

I find a lot of the answers very cautious.

Remember you are responsible for your career no one else is. This means that by agreeing to work with this person you are saying that you are accepting this assignment and responsibility and that you will be able to manage the project (and this person) to its fruition.

If you don't think you can do it, then don't accept that responsibility: have him assigned to another project, or ask that they give you a leadership position on another project.

I know your question is about "how to deal with this person", but based on what you are writing it sounds to me that he is not worth any effort, you'll be busy enough proving yourself in this new leadership position.

Answer 25

I have also seen this type of job. Some people have extra talent and obviously have risen to a high position, but you have to remember that he is older than you.

So respect him. But never forget you are the team leader and you have to manage your team. You have to maintain a proper understanding between team .//// and go on.