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?

  • 119
    It's easy to see why you were chosen to be the team lead instead of him.
    – jimreed
    Jul 6, 2011 at 14:28
  • 61
    So the person in question grieves others, doesn't get things done and isn't really pleasant.. how the heck wasn't he fired? Jul 6, 2011 at 14:38
  • 16
    @Michael, I always like to think that there are two sides to any conflict, and to be fair, I have only presented my side; but sometimes I have run into certain personality types (esp. at work) who are just parasitic individuals and should probably be let go. Unfortunately (or fortunately) the job demand for skilled programmers is pretty high, especially for the space we operate in. Jul 6, 2011 at 14:45
  • 9
    Not a solution but I couldn't help be lol at him asking you to report to him. Sounds like Dwight Schrute :)
    – Tundey
    Jul 6, 2011 at 16:10
  • 22
    Sounds like you should ask your boss to have him removed from your team.
    – user1249
    Jul 6, 2011 at 17:36

25 Answers 25


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.

  • 19
    +1 - thanks, this is probably the best answer here. The issue is fundamentally one of trying to figure out if the problem can be salvaged before getting rid of the guy. The other big benefit of this approach is that when the time comes to get rid of the guy, its much easier to make your case because of the amount of background work, time, effort, attempts, etc that you put in. And one final word: If the guy is REALLY depressed (clinically) then he, and only he, can do something about that. And if you try and interfere, watch out. This is especially difficult territory. Jul 7, 2011 at 5:43
  • 47
    Not just a good answer, a remarkable one. I think there is definitely a psychology behind programmers. Many programmers are both introverts and control freaks. We'll start holy wars over tabs and spaces, all from basements we're scared to leave. I'm generalizing, but I know too many arrogant programmers for this to be a coincidence, and many of us have probably been that problem guy at some point in our careers. For a lead to understand this could mean the difference between humility or a headache.
    – Soviut
    Jul 7, 2011 at 6:27
  • 3
    I disagree with your simplified "superficially correct" response in your first paragraph. The OP's direct question was "how to cut it off before it gets out of hand". IMHO in this situation, you must establish the senior/subordinate relationship first and then pursue other avenues like you mentioned. Jul 7, 2011 at 11:04
  • 1
    @joel-spolsky Joel, I wholeheartedly agree with your answer for the human element of the situation. I feel compelled to point out, though, for others benefit, that is it not a mutually exclusive response to the situation (which I'm sure you already know - why rehash everything that's already been said?). +1 on adding such an astute response. Jul 7, 2011 at 13:29
  • 5
    @Joel Spolsky: I see at the end you've apologized for the length, but I think it could have been a little longer to include the increased emotional load that will now be injected by a peer rising to a position of authority before him. If the problem truly becomes insecurity, recommendation #2 may not be very useful since OP will be a symbol/reminder of those same insecurities. How would you recommend OP handle a situation where dealing with it directly (personally) merely amplifies the problem? Jul 7, 2011 at 17:26

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.

  • 43
    Be sure to give this person direction in writing, so you have a paper trail. Jul 6, 2011 at 14:22
  • 10
    I would add to keep a log/journal of any issues that might crop up just in case with this individual, too.
    – Marlon
    Jul 6, 2011 at 14:42
  • 18
    @Marlon: I'd add that the journal should cover everyone on the team. Covering just one person looks like targeting. (+1, because I suspect that's what you meant anyway.) Jul 6, 2011 at 14:56
  • 6
    "but the rest of the team as well". You're going to alienate everybody. That is bad. If I can't mention what I did on the weekend to my team lead, basically I'll lose all respect for that person. Jul 6, 2011 at 15:57
  • 5
    WTH? Don't talk to your coworkers about sports? Just because you're professionally above them does not mean you can't be friends. I play poker with my company's directors twice a month and yet I'm pretty sure when it comes to work I report to them and not vice versa. Jul 6, 2011 at 19:10

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.
  • 10
    +1 for 'Removing him from the team'; -1 for 'Ask for your team's opinion frequently'. // In software especially, never rule by consensus. It is the worst thing you can do. If you're going to take on this malcontent, then take him on. Don't solicit opinions from other team members in an effort to strengthen your case. In the best-case scenario, team members are left believing that they must validate your instinct that this team member must be removed. In the worst-case scenario, the malcontent finds allies and weakens your case.
    – Jim G.
    Jul 6, 2011 at 17:02
  • 3
    @Jim G.: I don't suggest to use the team to strengthen a case but use the team's opinion as the opinion to follow. In my book the team leader is not a boss, but a helper.
    – user2567
    Jul 6, 2011 at 17:06
  • 1
    Yes, but there are times when a leader must lead; and when it comes to "Preventing the bad apple from spoiling the bunch", the leader must move swiftly and decisively. Anything less may weaken the team and the leader's authority. It may also lead other productive team members to seek greener pastures, which is among the worst of all possible outcomes.
    – Jim G.
    Jul 6, 2011 at 17:10
  • 4
    @Jim G.: that's not leading then, it's management.
    – user2567
    Jul 6, 2011 at 17:11
  • 4
    "Removing him from the team" essentially translates to your own management as "you're not good enough of a leader to make a team work." Teams always have problem people, people have conflicts. That's human nature. Great leaders make such teams work, poor leaders blame their own failings on their team. If you can make a difficult situation work, this will be a much bigger boost to your reputation with YOUR managers, the people who really matter to you personally (and who determine if you lead again).
    – anon
    Jul 7, 2011 at 1:03

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. :)

  • 2
    After bullets "Be professional" and "Be direct" I was waiting for "...and have a plan to kill everyone you meet." Jul 7, 2011 at 1:01
  • No... no! The next bullet is "create villainous lair", followed by "capture hero", and "explain devious plan to hero". Jul 7, 2011 at 13:09
  • When do we get to make the call for .... ONE MILLION DOLLARS... +1 great advice Jul 8, 2011 at 16:08

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.

  • I disagree with accepting that this developer is best just thrown away (my words). But your advice in how to handle it applies very well either way. Jul 8, 2011 at 16:04

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.


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.

  • 3
    +1 for this comment, "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."
    – maple_shaft
    Jul 6, 2011 at 16:35

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.

  • I was at first glad that you tried to address making it with the problem... until I saw that it was a backhanded slap at the idea of trying to work with him. Jul 8, 2011 at 13:48

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.

  • +1 for pointing out an important point that others overlooked, especially considering the problem description given by the questioner. Jul 7, 2011 at 0:45

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.

  • 2
    Imo, most of this advice is "ill advised" - the best way to entrench "that guy" as your sworn enemy is to come down hard and tough from the get-go. He doesn't think you're worthy of him -- show him that you are by following the advice of those like Pierre. You're not in the military, you're in a workplace. -1
    – Vector
    Jul 7, 2011 at 3:05
  • 1
    There's a difference between management and leadership. Most people think these two are the same. I disagree with your "ill advised" comment. Until you have been in a situation like this where the potential for someone to undermine your authority you really don't know how to react. Talk is cheap. Jul 7, 2011 at 10:57
  • 1
    -1 This is good advice for dealing with the relationship if it fails but a poor way to start it out. Jul 8, 2011 at 16:00
  • If you tried these techniques in the military, I think the Lt would get fragged on his first day in the field.
    – gbjbaanb
    Jan 31, 2014 at 8:40

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.


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.


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.


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.

  • You make the same failure as the poster in assuming that the developer is going to fail. This will prevent his ability to destroy the project, but it also prevents him from providing any contribution. A greater crime in american history than slavery was our racial and gender discrimination that undoubtably preempted great discoveries, inventions, and advancements. Jul 8, 2011 at 15:55

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.


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.


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.


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.

  • That may have been the right thing to do when they were peers. As a lead that dynamic changes. The lead should appear in control of his/her emotions about the team. Expressing feelings that are not positive, will lend to an appearance that he just does not like the guy. And any constructive criticism is more likely to be disreguarded as the lead just has a personal grudge against him. This is not a friendship that needs mending it is a professional relationship that needs to transcend any personal feelings. Jul 8, 2011 at 15:48
  • Leadership and honesty don't have to be mutually exclusive
    – jayrdub
    Jul 9, 2011 at 5:44

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.


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.


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 :)

  • 2
    In theory peer performance reviews seem like a good idea. In practice they tend to seem like the team is picking on the weakest member(even if they are not). This serves no positive purpose. A leads job is to lead the team forward. Jul 8, 2011 at 15:42
  • performance reviews and Stalinist monitoring are a very poor part of the answer, but the first part is great: fix the problem. If devs are told to "go write awesome code", some will watch videos all day. Some people thrive in that kind of environment, others thrive with firm direction. Fix the situation so it gets the best out the staff.
    – gbjbaanb
    Jan 31, 2014 at 8:33

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


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.

  • if you think documenting stuff is a "dirty job" then you are the bad developer, not him.
    – gbjbaanb
    Jan 31, 2014 at 8:35

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.

  • 1
    If you run away from every challenge you will find yourself having to run further at each successive challenge. Jul 8, 2011 at 15:36

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.