How to handle demoralization caused by a slacker in the team?

Question

I recently started working a programming contract at a company, and initially everything was going fine. I was very focused, I came in on time every day and got a load of work done, and never let myself get distracted by anything like web browsing, email, etc. I got a huge amount of work done in a short amount of time.

Then they hired another guy, let's call him Bob. Bob comes in between 30 and 45 minutes late every single day and is the team slacker. I honestly don't know how Bob passed the programming interviews, but he seems to have very little programming experience. (On his first day, he asked me for help and when I came over he had copy+pasted some tutorial code from the internet straight into his file, without even putting the code into a function, and asked me why it wasn't working.)

As a first project, he was given the initial task of changing a program I wrote to do something slightly different that they needed for another task. It took him 4 weeks to make these modifications, while it had only taken me 2 weeks to write it from scratch.

For the rest of his assignments, he tries to find something similar that I've written, downloads it from the code repository, and then asks me how he can modify it to do what he needs it to do.

The fact that Bob is being paid the same amount I am, is such a slap in the face of my efforts that I feel demoralized.

How do I handle demoralization caused by a slacker in the team?

Answer 1

If you don't help him and let him fend for himself, he'll miss his milestones, nature will takes its course and that's the last you'll hear from him. From now on, you're always busy trying to meet your own deadlines. You are not so selfish as to not want him to get full credit for his own work, do you?

Let his incompetence lead to his undoing. You don't have to lift a finger.

Our site deals with somewhat thorny issues, but the issue on how to deal with obvious incompetence from a newly hired employee is an easy one

... And you're feeling demoralized because?

Follow-up comment from @JeffO "I agree with your answer, but you have to consider some people are going to naturally be a team player and try to help someone in need. It's not easy for them to cut someone loose"

This team member is so unqualified that he is unsalvageable. Those who rush out and help this individual will quickly find themselves trying to do two jobs - his and theirs - on exactly one paycheck.

Follow-up comment @Stevejessop "You also have to apply a modicum of diplomacy. Someone in your organization has chosen this person, and they will expect you to treat them as a member of the team. So you should help this person as much as would be expected for a functioning team member or else you'll share the blame for their failure, just as you would if they were any good but failed because you refused to be a team player. That amount is not a lot of help to someone on the same grade as you, and depends on the nature of the team, but it's normally more than none and more for a recent hire than an established employee"

The individual's getting paid the same as the OP, so I take it that he is at the same grade as the OP. Surprisingly, the OP is doing their job without the help of this individual and this individual cannot do their job without the help of the OP? The OP assumes that the individual has the same qualifications as the OP and provides any assistance on that basis and only on the basis that time permits. If what the OP says to him sails over his head, tough luck for the individual. I proceed on the basis that every member of the team must carry their own weight and that whoever hired this dud is going to have to take be responsibility for his upkeep and maintenance.

Follow-up comment from user568458 "Doing only this risks you also getting into trouble for not being a team player, or a manager concluding that the problem is the team not him. I'd suggest heading this direction more gradually: track how many hours you spend coaching him, tell your supervisor that it's cutting into your work time, and agree a reasonable cap (like, max 2.5 hours helping him a week) and make a note of what help you give him and when. Then, you'll have firm facts showing you did everything reasonable for the team, and you'll have firm grounds for refusing excessive help."

Every team member must carry their own weight. Period. Being a team player does not mean doing the work of someone who is congenitally unable to do his own work or to teach the basics to someone who was hired on the presumption that this someone knows the basics. This individual gets the same degree of support as every one of the team is getting. No more, no less.

Hiring that individual was a management mistake, and the management cannot correct their mistake unless the mistake is documented as a mistake. The failure of this individual to meet their milestones is one strong piece of evidence. Documenting that the individual did not understand the basics gives the management more ammunition.

Answer 2

I have worked as a consultant / contractor for a long time (since 1998), and I have been on both sides of this fence. So I have some advice that at first might sound contradictory, but here we go.

Do you have a strong enough relationship with either someone from your vendor company or the company itself to have a completely honest no-bull conversation about what is going on? If so, I personally would suggest the direct approach. This gets a little sticky if Bob is an FTE as opposed to a contractor like yourself, so you have decide if you have enough on your side to make this kind of move (what market you are in, how long it took you to find this job, what other jobs are there, etc.).

Now this is the part that is going to sound contradictory - are you sure that Bob knew what the job entailed? It is possible that he is feeling completely lost. For example, I work as a Web Developer, front-end to middle tier with some backend skills. I interviewed for a position 2 year ago where I was told I needed crossbrowser skills; check mark in that box (been doing that since 1995 or so).

However, when I got to the site I found out that I needed to rewrite a custom DynamicsCRM plug-in application that had no documentation, the 2 people in the company that knew how it worked were on vacation for multiple weeks (they were also in another country), they had overpromised the delivery date to the external client (2 months for something that was 6 months of work at least), and they promised the external client that there would be no loss of functionality. I consider myself quite skilled, but I failed miserably on that assignment; the client ended my assignment 2 months in on a 6 month contract. My point is that Bob might be feeling just as lost on this assignment as I was on that one.

So, before you try to approach your vendor or the company itself, you might want to see if Bob can go out to lunch with you and try to figure out how he is feeling about the job. Again, if Bob is an FTE as opposed to a contractor this could get sticky, so you would need to determine if this would work for you.

Answer 3

You say this:

On his first day, he asked me for help and when I came over he had copy+pasted some tutorial code from the internet straight into his file, without even putting the code into a function, and asked me why it wasn't working.

Then you say this:

For the rest of his assignments, he tries to find something similar that I've written, downloads it from the code repository, and then asks me how he can modify it to do what he needs it to do.

Everything else sounds hilariously cringeworthy. I have worked with slackers. That is all I have to say about this.

But this one sentence here points to a larger problem: This co-worker is not a slacker. They are incompetent. The problem is you are on contract & I assume the other person is as well? Well, you need to point out these facts to your supervisor right away.

The reality about coding is it’s invisible work. Nobody sees what you do. And even if they do, they rarely see the full process of coding & problem solving. The quality of your work comes down to end product, trust and—this is key—a history of proving viable end products & fostering trust.

This co-worker of yours clearly pushed the right buttons with whoever hired them to get the gig. And is clearly faking it to make it.

So you need to document all of these “face palm” moments & save them for a discussion with your supervisor. Also, you need to not let this clown derail your efforts. For example you say this:

The fact that this idiot is being paid the same amount I am, is such a slap in the face of my efforts that I don't really feel like working very hard anymore.

I have felt that way in many similar scenarios, but do not ever let this kind of B.S. slow down your work or compromise your quality. If you do that, you basically bring yourself down to their level. And then—for all you know—you could get the boot & the clown stays.

Instead, do the same quality work, but be sure to be good on documentation of what you have created & why. And if this co-worker asks for help, help them! But document it in some way. Meaning, if he casually cut & pastes code from a random website but wants your help, save the urge to scream & instead help them. Explain how what they did is wrong. And then guess what? Follow up with them in an e-mail—if this was a casual office convo—and basically say, “Happy to help you with that problem today! Just a follow up but…” and then document it all in an e-mail.

You need to basically rise above this clown.

Answer 4

The fact that this idiot is being paid the same amount I am, is such a slap in the face of my efforts that I don't really feel like working very hard anymore. (I feel like "why should I?") However, I still have projects to deliver so I still have to get work done, I just feel demoralized so it has become more difficult.

What's the best way to deal with this?

In my opinion, the best way to deal with it is to learn not to base your morale on the actions of others.

Take pride in your work. Feel good about the compensation you received. Learn to ignore what others do or don't do.

Presumably you felt good about yourself, your work and your compensation before this Bob appeared. And likely you will feel good again once the incompetant is let go. Meanwhile, essentially nothing about you has changed but your attitude. You have chosen to let another's poor performance affect you.

Stop comparing yourself to others. Work hard each day, and take pleasure in the work you do.

When I was very young, I used to feel the way you do. I've learned to get past that. For me this was part of my maturing process.

Answer 5

The best way to handle this is to focus on your work and let him fail. If he is getting in the way of your work, then bring it up to you boss. If your boss doesn't see things in the same point of view, maybe there's other things at play.

If what he's doing is not affecting your work, then I wouldn't even worry about it. Focus on what you're working on and (hopefully) you'll come across as harder working and smarter than him.

Answer 6

From what you are describing it seems more like your coworker is not as skilled at software development as you rather than just a slacker. They could be a slacker if they 1. Devote a large portion of their time to distractions or straight entertainment during work 2. Are unwilling to put in the time or go the extra mile when the project requires it or 3. Spend the effort to improve their (admittedly lousy) development skills.

If they are a slacker... Well it does not matter what you do, the problem will take care of itself. I am the kind of person who might consider giving them a short (polite as you can keep it) wake up call, some people need to get jolted awake and it could gain you an ally if you can convince them to be a team player.

It is possible that they are also truly incompetent and incapable of learning the skills they need. If that is true feel sorry for them because it does not matter how hard they try, they will be cut sooner or later

I am going to go with the assumption that "Bob" simply does not have the skills they need for the job. That is actually more common than you might think, a lot of times you want to hire the worker someone will become rather than the person they are (see any student out of college... ever). I would try to figure out why they were hired, dos Bob have a skill other than software development that no one else on the team has? Or some other facet that helps the team get a particular contract (you need someone who already has security clearance to get a contract that requires people with security clearance, so that you can apply for the rest of your team to have security clearance).

I don't know how you are sure he makes the same amount you do, not everyone in the same position does and most companies keep what they pay individual employees confidential. But if you can figure out the reason they were hired it could help with your morale problem. As to what you can do, assuming Bob is not lazy or an idiot I would provide some amount of help, and a whole lot of pointers. Recommend books, say things like "finding code on the internet works sometimes, but you need to move beyond copy/paste", explain good practices... straight up knowledge transfer.

The benefits are threefold. First, your team gains a true contributor. Second, you gain an ally in Bob. Third, your boss will notice and will value you more.

This relates to my personal experience, in one job I was Bob. I was hired as a software developer with limited programming experience (I had exactly one class programming in college, not in the language I was hired to write). The reason I was hired was that I did have a strong statistical background, which was an area the company wanted to grow in. So I did as much as I could on the projects I was given, I read, I watched Coursera videos, I Googled, I asked questions on Stack Exchange... Most of all I listened and learned from my coworkers. And I learned my stuff. In addition I made myself the go to person for statistics and mathematical questions. It worked very well, I was kept on despite the company not getting the contract they needed a stats person for, and our team was very amicable and very productive because we transferred knowledge between us when someone was trying to learn a skill.

Edit

There is another possibility. Bob may have misrepresented his skill set during the hiring process. The above answer assumes management knew that Bob would be training up and had a reason for hiring him anyway, if that is not the case then they should know about his lack of skills as soon as possible!

Answer 7

So.. I don't discount some of the solutions already provided. I have seen the "too busy" approach work (and used it myself), and I have seen the frank discussion approach work (and have appreciated it as a manager when I was the recipient of the frankness).

But... let's take the mushy problem that is Bob and dissect it, because it's actually a few different problems that may actually be handled separately:

• Bad work ethics - comes late, leaves early, etc. - even if this guy was great at his job, being unreliable, uncommunicative, a jerk, or other basic things sets a case where that if that's OK, this will become an unpleasant place to work. I'd tackle these with a polite question to management - "what's our start time? Oh... I'm confused, I see Bob comes in 1/2 an hour later than that every day... is everything OK with him?" This is a nice way of saying that you see an oddity.

• Technical competence - if you have a serious belief that this person simply doesn't know how to do their job... so that no matter how many hours he works, his output will be poor quality, inefficiently built, and behind the deadline - then say it flat out to the person who pays him. It's always better to have concrete examples - "I've had to fix 20 bugs generated by Bob in the last month, where I usually fix under 10 bugs for the entire team", or "when I peer reviewed Bob's output, I found that it fell far short of best practices, for example X, Y and Z" Don't hint here - but do keep it about the work. "Bob's work is not of the expected level of quality", not "Bob is ignorant of how to do his job".

The one thing I'll say as a manager who has some expertise in this field is that two of the problems you mention would not be deemed a problem (by me) in 100% of all cases. They are:

- It took him 4 weeks to make these modifications, while it had only taken me 2 weeks to write it from SCRATCH.

• Hearing just one side of this story, I'd like to say "yes, changing something is easier than creating something" - but my experience is that this is not true in all cases.
• My counterexample is that a design anti-pattern is very fast to create, but very hard to alter... so before you start comparing your work and his, be sure that you have other examples where this particular piece of work has been easy for others to maintain.. which presents the case that you've done a good, extensible design.
• The other counterexample, is that most of the time, I expect a new developer's first work be painfully slow. It's not unusual for a first project to be highly inefficient as a developer comes up to speed. I expect a 3-6 month lag, unless I expected that the skillset was an exact match.

- For the rest of his assignments, he tries to find something similar that I've written, downloads it from the code repository, and then asks me how he can modify it to do what he needs it to do.

• If you intend to raise this one, make sure you can clarify why this is unacceptable. I always want developers to use consistent design elements, so starting from a known base and emulating a good practice is not something I'd discourage. With that said, there should be decent enough understanding on the developer's part on when to copy, when to extend rather than duplicate code, and what to do when no pre-existing case fits the bill. But to understand whether the work was good or bad, I'd need a whole lot more context.

My last thought is - make sure that this issue is the boss' problem and not yours. Bob's manager is the one responsible for Bob's performance, and the manager deserves as much frankness as you feel comfortable providing when there's a performance issue that is impacting the team's ability to deliver high quality output.

Once you've done what you can to make management aware, let it go. In the end, you work is not Bob's work. There will always be someone around somewhere who does better work than you, and someone who does worse work, and pay scales are never entirely fair. So using this as a force for demotivation is to set yourself up for a lot of disappointment. Also - you'll never really know the full context of what Bob does, what Bob delivers and how Bob is compensated relative to yourself.

Answer 8

Having been on both sides of the fence, here are some things to consider:

• The programming market is extremely competitive. It's likely that if Bob is a recent graduate, he was desperate to get his first break in to the industry and took the first offer he received from an incompetent employer that couldn't tell that his skills didn't fit the job. Discrepancies in necessary skills don't matter very much to someone who needs money, so he had reason to not refuse the offer. In other words, try not to direct your dissatisfaction towards Bob but towards your employer; they probably could have seen this coming, and as a result your productivity has now gone way down. They need to know that, and if they won't do something about it then it may be time to think about making an exit. Plus they clearly don't understand your value if this newbie is getting paid the same amount as you are.
• Programmers often feel that their code is self-explanatory, hence they expect other programmers to immediately understand it and they don't bother documenting the code. In my first days as a programmer, I was given some horribly convoluted PHP with no documentation and nobody else on the team wanted to touch it. I spent a day and a half on it until I had to get someone's help to understand it so I could make the necessary modification. I bet I may have seemed incompetent, and I sure felt it. I also lost a lot of morale right off the bat. After that week, I didn't exactly want to show up to clean up someone else's mess. I'm not saying that I know for sure that your code isn't good, but maybe take that possibility into consideration.
• I was once on a project with someone very similar to your Bob. This was a final project in school where we had to write a full web app in 10 days; we didn't have any say on who could be in our groups and the selection was random. My Bob(who we'll call Fred) originally showed up on time and showed effort, but frequently displayed that he was lacking several skills. Half of our time was spent teaching him things he should have already known or doing his work for him. To top it off, he had a lot of ideas that just... weren't good; we spent hours debating ideas and many more hours debating with him on why we didn't like his ideas. It did not take long for his morale to plummet, as did that of the rest of the group. Soon he wasn't showing up on time or talking to anyone, and he wasn't getting his work done. Eventually, the rest of us had a talk and decided that we had to do something to salvage the situation. It turned out that he was actually half-way decent at one particular thing(basic JavaScript and AJAX) that the rest of us weren't terribly interested in. We decided to delegate Fred to work on those tasks because since he had some understanding of it he would be out of the way, feel useful to himself and others, and be free to make executive decisions in his realm of the project. Of course the problem didn't go away entirely, but the project went more smoothly in general. Maybe you could try to figure out what Bob is naturally good at and nurture him in that direction? Personally, I think it's a mistake for the industry to expect new programmers to have a cornucopia of expert skills.
• What's wrong with him using existing code to get the job done? Most good programmers do just that and it's a terrific way to learn; are you sure you aren't being defensive because he's using your code? What's important is the answer to this question: Is he getting the job done?
• Some employers are very relaxed about when to show up to work. Is it possible that Bob's previous occupation was that relaxed and the current employer hasn't made it clear that he needs to show up on time? Your employer already seems incompetent themselves, so it wouldn't surprise me that they wouldn't properly inform him on when to show up.

By no means am I trying to discredit you, because I've known people who deserved to fail and I certainly wouldn't want to work with them again. I just hope that before you leave this individual out for the vultures, you consider him as a human being and make sure you know where the real problem and blame lies.

Answer 9

I think you need to be open with this person and tell them this situation has to change. He can stop asking your for constant help, or the two of you need to go to your supervisor and work something out. The project may need to be adjusted for you to train and hold this person's hand. Don't be surprised if this lesser programmer was hired with the assumption you would help him along. It's the client that is paying for both of you.

If he doesn't want to do that, let him fend for himself.

Answer 10

Without seeing any of the code that you have written, it is hard to tell if you are a good programmer or not to justify your claims. Most programmers think they are good but actually write unmaintainable code because they lack the ability to plan far enough ahead. But let's assume for a moment that you are one of the few good programmers out there. What can you do?

First off, you probably have a boss. Talk to him or her. Let them know how you feel about the situation and give at least two specific examples. Your boss may simply be unaware of what is going on. If they are a decent boss, they will begin observing interactions more closely between the two of you and possibly call Bob into their office. If Bob is called into the boss' office, you should feel bad for them both because the situation is a sucky one. That is, no boss likes giving a dressing-down and no employee likes receiving one. If Bob reports to a different boss, your boss and his boss will have a discussion elsewhere about the problem. At this point, you've done everything you can do and it is up to management to deal with the situation. If you have difficulties forming coherent thoughts/sentences (discussing one's feelings makes many people very uncomfortable), jot a few notes down before talking with your boss.

Second, most employees have a "probationary period". During the first 3 to 6 months, an employee is evaluated for their performance on the job. Your boss has significant say in whether an employee stays employed during and after this evaluation period and is part of the legal agreement between Bob and the company. If this person is fresh out of college and they learned how to program in college, they may simply not have enough actual experience. Usually their salary reflects that. However, salary may be dictated by the job title description though and, if two people hold the same job title, HR will set salary requirements based on that. So fixing that might involve the complex matter of setting up another job title within the company for new programming hires (e.g. separation into Junior Programmer and Programmer).

Third, you should not know how much money that Bob is making. That information is privileged and should be known only to whoever does payroll. How you came across that information is a dangerous hole that needs to be plugged up ASAP since it could lead to a lawsuit. Go read Matthew 20:1-16. Your employer has the right to pay whatever amount of money they want to for each of their employees. You have no right to be upset/jealous about how much money someone else makes.

Finally, it takes time to acclimate to an organization. If there are hundreds of buzzwords flying around in a place, it can take as long as two years to fully acclimate. A newbie in such an environment is going to drown for several months before they can float for the first time.

Assuming that your side of the story is accurate though, Bob may be on his way out soon. He may have been hired due to a good interviewing strategy on his behalf but might be in over his head. It happens at every organization. However, the difficult part is making sure your own work ethic is not dragged down by his work ethic during his employment - especially the "being late to work" part. If he arrives late and leaves early, that behavior can drag down a whole team such that they end up doing the same. Once the team is in that rut, it is very difficult to get out of it.