For the past few months, I have been constantly haunted by a team member for "help". This dude continues to play ignorant and gets me to do his work. I am stuck, can you help, and get me to sit in his chair, and exactly show me how to solve his issue. Takes a lot of my time.
Without being offensive I need to get the message across that the meaning of help me cannot be, "do it for me, this one time", time and again.
This is a similar situation as the one described in How should I deal with colleagues asking me to hide problems with their work?, and I think Robert Harvey's answer applies here as well:
Saying "no" is a very useful skill in the workplace.
You may not immediately see the similarities with that other question, but since I am the lead developer the question is about I think the core problem in both situations is letting a behaviour that is a bit counter-productive go on for a while just because you can't say "no".
But you must, especially if your colleague's behaviour is becoming disruptive to you own work. If you want to sugar coat it, you can say something along the lines of:
I'm sorry, but right now I'm swamped with my own work and I simply don't have the time to help you.
Continuing to help him past the point he became annoying is only enabling his behaviour. If he doesn't get the message after you decline to help (a couple of times) and continues with his vampiric ways, I'm afraid you'd find yourself left with only one option, and that would be to discuss the matter with someone higher up the hierarchy chain.
I can understand how uncomfortable your position is, and I must admit that early on in my career I exhibited vampiric tendencies as well. What worked for me back then was structure. The colleague I was hassling set some time off during the week, usually Friday afternoons, for us to discuss my questions. I complied, and started writing down all my questions and at first he gave me ready solutions. After a couple of weeks he started giving me helpful directions, but not solutions, and about after a couple of months my training was over and I was rubber ducking and solving my own problems. I'd still need help once in a while, but I'd only ask for it when I was absolutely stuck. Few years later, a junior developer pulled this exact trick on me!
If you can't say "no", this would be the next best thing. Creating a schedule (and keeping it) means he won't disturb you any more while you're working on something else, and will also give an air of formality to the process, this isn't spontaneous help vampirism any more. Writing down the questions in advance will help him become a little bit better in communicating his issues (and perhaps researching his issues before he comes to you - or anyone else - for help). Gradually you should shift from giving him complete solutions to explaining your thought process, and... well... hope for the best?
It might work, but it completely depends on your colleague's willingness to learn and your mentoring skills. And it's really not part of your responsibilities, if you decide to create and go through such a process, you should first realize that you are creating work for yourself, you are putting yourself in an informal mentor - protégé relationship that usually works best when there's a clear and established hierarchy between the two of you. Just saying "no" might be preferable, and save you both from a lot of trouble.
I like Yannis's answer, but I just couldn't let a 1 answer question go by. Partly since I think any question may benefit from a diversity of view points. Here's what my escalation process would be.
(Almost) Never Sit in the Chair
If you find your butt in his chair, you can be almost certain something has gone wrong. Do let him drag you back to his workstation, and look over his shoulder, but keep his hands on the keyboard and yours off. I don't care how slow the guy types or whether he can't find the mouse with both hands... it is far, far to easy to give unhelpful help when you are the one with the hands on the keyboard. For a good developer the mind/body connection between self and computer is so tight that many have real trouble explaining every step (particularly the really transformative ones) when they are plugged in directly. Having him type will slow you both down and that's good.
IFF (if and only if) you've worked on this one problem for 20 minutes or more and there's no progress, you MAY consider a hands on solution. At this point, my instinct would be to still go back to your own computer, look into the problem locally, and then when a clue is reached, return to him and repeat the hands-off instruction. If, however, you have a situation where really the only way you can solve it is at his workstation (danger - that's an indicator of risky CM practices) then you can sit down and look, but be sure you are so very clear on what you have changed that you could change it all back.
Progressive Explanations
Teaching should almost never be rote instructions. If you are spewing off a list of commands for him to type or syntax for him to fix, you have a serious skills problem on on your hands and it's probably time to talk to a supervisor. Forgetting or not knowing a single simple command due to a memory lapse is one thing. Being a "baby bird" who can't find a single worm without being hand fed simple action after simple action shows a lack of training and competency.
As you explain the steps of a process, be sure you cover "why" - the mental model for how you solve a problem and the ways you hypothesize, learn and correct your model for how to produce good work is key insight that this person needs to learn. I spend a lot of time on this, and look for a light bulb to go off. If I don't see interest and enthusiasm for learning why I get worried about motivation.
The first time you explain a "why", detail is great.
The second time, reference the first time and ask him to remember. Clean up any mistakes.
The third time, expect he's got it, or that there's a serious learning problem. If it's not clicking, it's time to ask him what he's unclear on.
Expect by the fourth time, he doesn't need any of this, he can just do that part.
Look for Issues - Give Feedback
Keep an outside eye on why he's needed help so many times. If he's rushing, get him to slow down. If he keeps forgetting an important step, point that out and ask him to find a way to remember it before he bugs you. If he has real trouble remembering commands/syntax or with other basics, recommend a book or website he can use. Sometimes we just don't realize we have issues until someone points it out.
You can even give feedback on how soon to call on you. I like the idea of a short sit down every week, so he can collect issues and have help addressing the most difficult - that forces a bit of discipline and organization that may be lacking.
But if your project is high-speed, your team may not be able to wait that long - in a 2 week sprint, that's 2 opportunities to get help. You may, however, want to set a time line or a checklist to have ready before he bugs you. Saying "try for half an hour before you give up, I know you can get it" may actually be all the guy needs. In particular, I've seen newer workers have trouble realizing that they are not a failure just because they experience an hour or two of complete confusion. Also, if there's an easy set of things to check and prep before asking for help, have him be clear on that, and refuse, point blank, if he hasn't done it yet.
When to Raise to Management
There are times when this has to go to management. My rule of thumb is that you should not let yourself be pushed into a position where your work and progress are being sacrificed for his. Whenever that point is hit, your management deserves a chance to be in the loop, becuase it's entirely likely that your work is more important, and the management should have enough insight and control to be able to point that out and expect their guidance to be obeyed.
Here's some other indicators:
Serious skill gap - Needs very specific, very detailed instruction on a tool that is the common standard. Exceptions are granted for legacy equipment or very, very new tools - but if it was on the resume (or so simple as to not be something you put on a resume) - then the person should be able to perform basic commands.
Needs more repetition - You repeatedly explain the same tool, command, process - there seems to be no comprehension when you ask him to repeat your explanation in his own words.
Can't follow guidance - you've given a check list or set mentoring hours but the guy can't stop interrupting you.
Slacking at other times - If this person has needed so much help he's become a nuisance, he shouldn't be someone you see chit chatting or goofing around - he's struggling and he needs time to focus nad learn on his own. Also, be aware of how much help he gets from how many different people - if 6 people are helping him for an hour a day, then he's literally managing only 2 hours on his own!
