How do I deal with a slow and undedicated colleague in the team? [closed]

Question

I have been working on a new project. The project works like this: The end user can access a webapp using a link and he can add multiple systems on his network and manage that particular systems details. My part involves the front end and the webserver, which is done in python. My python actually communicates with another project which is entirely done in c & c++. The c/c++ project is the main app which does all the functionality. My python sends the user request to it and displays the response from it to the user.

I am very familiar with my work and I will finish it soon. Since that's not much work in it. And I am a person who loves to work. I spends most of the time in office and only go home when I feel sleepy.

The c/c++ app is managed by another colleague who has 5+ year experience and can do things much faster than me, but he never does it. May be he doesn't like to do it. His app crashes often when my python communicate with it or returns wrong values. It's full of bugs. Since my app depends on it, I am having a hard time building it. Instead of fixing the bugs, he asks me to slow down my work. He asks me to tell manager that my work needs a lot of time. He is asking me to fool the manager and even forcing me to work slowly like him.

During project meeting, when manager asks him about the bugs he says that he fixed everything and it works fine. Since he is my colleague, I couldn't tell anything to the manager. I obviously need to have a good relationship with my colleagues more than my manager, since most of the time we will be with our colleagues, not with the manager.

I am not able to tell the manager anything regarding this, since if manager asks him why, then he may think I complained about him to the manager. And he keeps on lying in the meeting. And since he fixes the bug slowly, it even slows down my work. Now I thought of working on the front-end part of my app and finishing it off so that in the mean time he can make his project stable. Now he is asking me to tell the manager that my front end part require a lot of work and I may need more and more time, simply so that he can drag the project down. And the sad thing is our actual manager has gone to the US, so we have a temporary manager and this guy doesn't know about the project much, so the c,c++ just fools him.

Can anyone suggest me how I deal with this? I wanted to finish off the project soon. How can I make him work even by maintaining a good relationship with him?

Responses to comments:

If he's really deliberately misleading the company, you should report him to management.

I am new to this company and the other guy has been there for many years. And I have just started knowing my colleagues. If I directly go and complaint him, I don't think so I can make good relationship with my other colleagues. Even he has the power to mislead them. I am not telling he is a bad guy, he can do the work, but he is not doing it.

Doesn't your company have any kind of bug tracking system ?

Here actual bug tracking system isn't there. The company tries to finish off the project as soon as possible and gives it to the QA. And then fixes the bugs reported by QA.

This is why companies should give employees stock / options or some sort of ownership. That way you can literally tell the guy "You are costing me monetary growth... don't you want to make money also?".

The company has the stock options they have given me a 2500 share, mostly he too would have got some more.

Seniority does deserve some benefit of a doubt. You really need to speak to him first and try to understand the problem. He may be out of his depth, you may be able to help him, there could easily be variables you are unaware of. It may be hard now, but you could easily make the situation a lot worse by jumping the gun.

I even does it, first his app wasn't handling multiple requests at a time, he was using a queue to handle the requests I sent to him. I even suggested to him some of my ideas on it. He said he already had these ideas, and will be executing them. His explanations was: "Everything require certain time to do and this is a project which may need two years to complete and we are asked to finish it in two months". I used to have a hard time coding during first few weeks because of this bug. But now he fixed it. But he is using a single queue for a user requests and that is now slowing down the app, since it processes one request at a time.

What is QA doing this whole time? Why aren't they reporting/confirming the status of the project(s)?

The manager is the person who decides when to give to the QA. As of now it has not yet given to QA. He said we should give it by this month end.

Answer 1

You're in a bad situation, I wouldn't want to be in your shoes. It's unlikely that you could to sort it out without getting into conflict with your colleague.

This is what I would do:

• Don't become his partner in crime. Refuse to lie about the status of your project or his project.

• Implement (in your spare time if necessary) bug reporting to your application, so all bugs are sent by email to your coworkers and to your manager. If the bug is caused by his application, make it visible in the email (put [XYZ APP BUG] in email subject or something).

• Maintain a bug database (besides sending bugs by email). You can say that its primary purpose is tracking your bugs, when in fact you'll be tracking mostly his bugs. Among other things, it should track how long it takes to fix specific bug.

• Have all inter-process communication with his app covered with tests ("when I sent you this, you should return me that" style). You could set up a cron task which runs these tests every day and if they fail, email is sent to everyone.

Basically, try not to waste your time arguing with him about bugs and focus on your work instead. If his app is broken and thus you can't work on your app and manager doesn't do anything with it - well, that's a management problem and you're covered with bug database, emails and test reports.

However, watch out and don't underestimate him. Long-time slacker like him might have a trick or two up his sleeve. He can turn whole team against you or something, but that depends on your specific situation and it's kinda out of scope of this question.

Answer 2

I'm going to throw in a slightly controversial view: You say that you are working as many hours as you can stay awake. So maybe he's not being particularly unfair to say "you're making me look bad and I'm actually working as many hours as I'm willing to." Maybe he's been there and done that and maybe he burned out. I promise you that you will if you keep that up.

Go out for a drink with him one night and see if you can't build a better personal relationship on which to base your professional. Maybe by his agreeing to put in a bit more and your agreeing to put in a bit less, you can both work together much better.

If I were you, I would also be very careful of this whole "my work, your work" attitude. Between the two of you, you have a product to get out there and this cannot possibly be good for that product, which in turn is not good for either the company or the customer and they pay for both of you to work.

However, I still agree with the other views that you need to revisit the importance of your relationship with your manager and you need to be careful of trusting your colleague. I'm just saying that maybe, just maybe, you need to look at your own actions as well as his.

Answer 3

Keep records. Document every error you get when communicating with his side, when you asked him to fix and when (if ever) he did it. That is the only way I know of dealing with this situation. So when your manager comes to you asking why things are not progressing you can clearly show without being seen as a whiner or a bad colleague.

Answer 4

I'd like to point out another possibility that hasn't been raised. You say that he wants you to slow down your work. Do you mean literally he is saying "work less hours" or that he is saying "write some tests, test this more, write some documentation" and other things you think will slow you down? I have seen new people run around writing code for 16 hours a day and then complain of bugs in the code they're calling when in fact they're passing invalid parameters, they're not checking return values, and so on. I can't rule out that your co-worker is thinking these things.

The next time you are in a meeting and he says all his code is fine, say "oh, good, the thing I told you about an hour ago, where it blows up when I call XYZ with a date that's not a working day, is fixed now?" One of three things will happen:

• He will lie, and say there is no such problem, you will say "there is so! We discussed it! I emailed you!" and the whole thing will come to a manager's attention
• He will tell you that in fact, that isn't a bug in his code, it's a bug in your code, because you're only supposed to pass working days, and you will soon find out what he's been thinking but not saying
• He will say "no, that one you just told me about I'll deal with today, but everything else is good." If he says that, just thank him for now.

You may learn that your long days of fast coding are not producing good code, and someone (your manager maybe) might translate for the other developer to explain to you what the issue is. Or, you may learn that you are working with a lying snake who will make you look bad to protect his cushy position. Bringing things out into the open can't really make that worse. Or, you may just get enough movement from him that you can stand it, without getting caught up in the politics.

Answer 5

What you have is a political problem. First your manager's opinion is far, far more important than you seem to think. This guy is blaming you for the delays and you are letting him. You are the one who will get fired if someone is thrown under the bus. As far as the manager knows, you are the one who is incapable of doing the work in a timely manner.

Protect yourself in any way that you can, through bug tracking, emails etc, but DO NOT go along with pretending this is your delay not his. Never give the boss a fake status report, it will come back to bite you. Tell the boss the truth about the problems you have (and show proof) with his code not working.

This person who is asking you to slack so he doesn't look bad is a snake (well that's an insult to the snake community (subtle Firefly reference), sorry to all the actual snakes out there). He will do anything at all to throw you under the bus instead of him. Do not trust him.

Answer 6

First and foremost:

Since he is my colleague, I couldn't tell anything to the manager.

You absolutely can and should make sure your manager knows the truth, even if your co-worker is lying to his face. If you don't want to say anything in a meeting with all 3 of you in the room, that's totally understandable. But you should at least pull your manager (the real one, not just the temp) aside and let them know that your work is almost done and is waiting on bug fixes from the other developer's end before the whole application is ready for prime-time. Don't accuse your co-worker of lying, but don't sit there and let your boss operate with incomplete information.

Report your statuses honestly. If your work is being held up by bugs on another developer's end, document that you've found bugs in the C/C++ and have reported them (please tell me you're using some form of documentation that leaves a paper trail).

In the meantime, go ahead and wrap up your work, and let your boss know when you're done. If your manager wants to know why the rest of the project isn't up and running yet, you can refer him to the other developer, and maybe mention that it's probably very complicated/large/requires a lot of testing/other developer is very busy/etc. If you know C/C++, you can offer to help on the main application logic to get things moving with that as well. Yes, you'll be doing the other guy's work, but it makes it clear that you're the employee working hard and being productive, and the other guy isn't, not to mention making you even more valuable to your boss. It may even put some pressure on the other developer to step things up and get them done quicker.

Answer 7

There are a number of issues at work. Be aware that:

1. You are making assumptions about the motivations of other people
2. You are coloring facts with opinions.
3. Outsiders (anyone else) are not aware of the history and are not aware of your frustrations with your colleague.
4. You may look childish if it appears that you are playing a "gotcha" game. Your colleague can probably play it better - after all he still has a job doesn't he?

Therefore, when presenting the status of your project:

1. Do not mention the other person.
2. When reporting errors or issues with the code - not the developer. Say "The call to method FooBar() is returning 1 when it should be returning a 2". Then any issue is not a personal attack, you are just talking about code - not people.
3. stick to the facts that you have proof for.
4. If your colleague gets defensive or hostile, ask questions. "I don't understand why you think that I should do _ "
5. Be oblivious to social slights or innuendoes. Pretend you don't get the personal attack.
6. Get lots of sleep the night before any status meeting, so you are mentally nimble.
7. Document, document, document.
8. Don't be shy about asking this guy to help you with some interesting problem, he might take to you if he feels that you respect him. This is about building rapport. (note this is not sucking up - this is something else )
9. Be prepared to leave if you have to, so that way you are not needy or emotionally trapped. This will help with keeping your head in meetings.

Answer 8

"I am a person who loves to work. I spends most of the time in office and only go home when I feel sleepy."

This is not healthy and cannot be expected of colleagues, unless you are compensated to the point of being able to take years off for the inevitable burnout. (Something like >10% ownership in the company or above $200k a year). Maintaining expertise to get to the point where he can develop very quickly takes time. Some of your time should be devoted to developing expertise.

"The c/c++ project is the main app which does all the functionality. My python sends the user request to it and displays the response from it to the user. ... May be he doesn't like to do it."

Python is a more agile language than C/C++. His app seems to contain all the functionality; your app just the UI. More likely than not, these are not equal in difficulty. He may not be producing code quickly; but quality coding is much better than quantity coding. You very well may have unrealistic expectations for how fast he can code in the hours he's willing/expected to work (typically ~40 hr week; and remember if he's been there for years, he's likely accumulated other tasks like managing others or help maintaining older projects that take up a significant part of the work week).

Don't lie for him; but again don't criticize him either. Talk about how his system is great; granted it needs more work until its finished. Give your manager an accurate status update without naming names/assigning blame. Write a mocked-up version of his system that conforms to the same standard that his system should conform to. Make sure your system works perfectly with your mocked-up system with an automated test suite. Then your system can be finished (e.g., it syncronizes perfectly with the mock-up), even if the live system is still buggy.

Then you can write a automatic test suite for his system being called externally that conforms to the agreed upon standards. E.g., test than Foo(1,2,3) gives back a response of "Bar 4 5 6". This could help him identify bugs and speed along his development (and doesn't need to mess with his code). Once those things are done, you'll be able to move on to another project/task (such as helping him with the C/C++ parts).

Answer 9

As others have mentioned, behaving professionally is the single most important thing for your long-term career. And honestly, as long as you behave professionally, you'll be in pretty good shape, no matter how those around you behave.

In this situation, there are a couple of considerations you need to take into account.

First, you need to understand that you are responsible for your program working to the desired specifications, by the given deadline. If your program interoperates with someone else's program, you are also responsible for making sure that that other program also works by the same deadline. To put this differently: If the other person misses their deadline, then you have also missed your deadline, even if your own part of the project was on time. In management terms, this is called owning the inputs.

You have correctly noted that when your colleague declares in a meeting that his program's bugs are fixed, that you can't immediately declare him as incorrect to the manager (your manager would see that as "throwing your co-worker under the bus"; a very bad career move). Others, on the other hand, have pointed out that it is unprofessional not to declare the true state of the project to the manager. Both sides are completely correct.

So if it's bad to contradict your colleague in front of the manager, and it's also bad to not contradict him, then what do you do?

The answer is actually pretty simple: You need to talk to your colleague well before the meeting with the manager, and let them know that at the upcoming meeting you're going to need to tell the manager about the troubles you've been having with their program, and that it's impacting your ability to deliver your side of the project on time, and whether there's anything you can do to help them address the troubles you've been having. You need to have this conversation at least two full days before the meeting where you will tell the manager, and preferably a full week in advance.

In most cases, just telling your colleague that you're going to have to list their program as a risk at a particular meeting will get them motivated to address the problems you're having, and you never have to talk to the manager at all. In others, where the problems are more schedule-driven, the colleague will often agree with you, and the two of you can go to the manager together.

I've never had a colleague who didn't either fix things up for me quickly or else agree with my concerns, when expressed this way. But if it did happen, by giving your colleague advance warning you'd still be in a better position when talking to the manager. Since you talked to your colleague and tried to work out a solution on your own, and warned them well in advance that you would need to raise the issue at this meeting, your colleague won't be surprised when they do, and the manager won't think that you're simply trying to shift the blame.

Do please remember that when you express your concerns, either to the colleague or to the manager, that your concerns are about your colleague's program which is returning bad data (or whatever else it's doing); these are measurable things which can be verified and fixed. Your concerns are not about your colleague being slow or undedicated; these are not measurable things, which may or may not be true, and which are unlikely to be fixed by bringing them up in a meeting in front of the boss.

Answer 10

What bug tracking system are you using? I would have expected that at least to highlight where bugs are not getting fixed in due time. Where your code is waiting on input from the other layer, the delays should be highlighted in project tracking documentation. Is this not happening either?

It sounds to me like there is inadequate project management here. You need to a) track the bugs that are affecting you and b) follow up discussions in writing.

Your colleague should not be asking you to inflate your development time to cover his lack of will. At some point, this is something which will have to be addressed with your manager. As things stand, you are covering up for your colleague and that will almost certainly backfire.

Answer 11

Nothing wrong with sticking up for a collegue, but for someone to expect you to lie to your boss on a daily basis has to go. I could not respect him as a person and would have no desire to have this person as a casual acquaintance. He wants to be an enemy, bring it on.

How can you argue delays on the application layer because of the front end? That's why you do this so they can be separate. What's next, he has even more delays because someone wants to build a mobil front end?

Get your work done. Document any issues you're having with a failure on his app. And then GO HOME! I don't care if you're sleepy or not. Find some friends worth having.

Answer 12

I've just read "The Clean Coder" by R.C. Martin (Uncle Bob). The main point of the book is that programmers in general don't get much respect because they are not behaving professionally. That means mainly that they don't communicate effectively with management about the status of the project.

Lying is certainly a very very bad form of communication. Your colleague is being extremely unprofessional and so are you. You both are doing nothing good to improve the perception of programmers.

I would advise you to go right away to management. However, I have gotten in trouble in the past for having been too "honest" (in some unrelated situation), so I'm not sure you should take my advice. Also, as many have pointed out, maybe your perception of the situation is not as accurate as you think.

Answer 13

It's difficult and unreasonable to estimate the relative effort and complexity of another project if you aren't familiar with the code base. You say his code is error-prone, but it could be in great shape with all of the remaining issues at a very high level of abstraction... Problem is, that is the only code that your front end needs!

Or, maybe he's a bad employee and taking the company for a ride. I can't say, and you may not have all the information you need to know with confidence, either.

I'd suggest a midway tactic. Next time you meet, bring some details of a major bug in his code that is affecting you. When he says everything is fine, politely say there is one outstanding issue that's blocking your progress.

Politically, saying it like that let's you assert that he's not quite correct, while still giving him an opening to play dumb and not be put on the defensive.

Your manager should ask at the next meeting if it's fixed. If not, the pressure falls on him to fix one bug. If it is fix, say thanks, it's working great now, and you found a new blocker. If you want to be especially nice, say you ran into it shortly before the meeting.

You're not lying, per se, nor are you taking sides. You're playing politics by calling attention to problems and letting your colleague save face if things are really not proceeding all that well.

It's tempting to just talk to your manager, but don't forget which one of them you have to work with the most.

Answer 14

Pat's answer was great. I agree 100%. Don't go sneak a meeting with the boss. Either take it with your colleague between 4 eyes or do it with all 3 of you. But Pat's suggestion to focus on the code issues and not on people is the right way to go.

Btw, 40h/week is enough dude. You need to keep your motivation high!

Answer 15

Ask for some else to help you both in integration testing. The person shall be able to say where the issue occurs. As temptar pointed out i wonder why there is not even an excel to track the issues! since there is no tracking, its like every time th other guy is escaping in saying everything is fine as of now! it doesnt work out that way!

Its your module if you need to get it done you need to raise the Red flag on whats causing the delay on ur side. Experience in MERE Years has nothing to do, its just the knowledge and thats what your manager should be insisting on. As said even i feel there is a poor management of project happening here.

Answer 16

1. Showing initiative by requesting additional tasks and asking how you can add value to the organization is the best way to earn trust.

Your manager might not be technical enough to figure out who is slowing down the project, but they are probably smart enough to recognize that a developer who is actively seeking out new tasking is breezing through their current tasking. This will lead to a conversation where you can make it clear that you are waiting on bug fixes from others on your current tasking. Frame the discussion in terms of how you can add additional value to the organization by efficiently using your free time, not how your colleague is being too slow with his bug fixes.