How do I politely coexist with a help vampire?

Question

I'm a senior developer at my workplace. A coworker in my sister team… isn't. They're also a textbook help vampire: they face an issue, they don't understand it, they miss the error message, they misdiagnose the issue, they ask people for help (often privately, via video-call), they misunderstand the advice, and they move on to the next person, until finally they stumble upon a misfix that happens to dribble around the original issue.

This approach to problem solving gives me the proverbial red mist — the computer program is telling you right there in plain English what it is that you need to fix, and whatever it is you thought you were doing in this fixup patch has absolutely nothing to do with the suggested fix — to the point where I end up missing the obvious and end up providing incorrect advice. For example, this coworker misconfigured an environment variable, and the program complained about it in very actionable terms. I got so caught up on my coworker's inability to follow basic instructions, I missed the trees for the forest: the correct fix wasn't to adjust that variable, but not to set it at all in the first place.

Unfortunately, being better than this is something that is expected of my role. I'm genuinely trying to help my coworker help themselves by pointing them to the diagnostics and encouraging at least a modicum of critical thinking instead of just spoon-feeding them the answer, though neither approach has really worked. However, their simple presence is now starting to cause irritation in me, and that's... unproductive. I wish I could have a real-time blacklist of people I never want to work with again and have it stick, but life isn't always going to be so accommodating.

So... how can I change this unproductive behavior of mine?

Answer 1

So... how can I change this unproductive behavior of mine?

+1 for recognizing that your own behavior is part of the problem.

I'm genuinely trying to help my coworker help themselves

That's the ticket! However you probably need to try a more formal and managed approach with this co-worker. Doing this ad-hoc on a case by case basis obviously isn't working .

Here is one approach. (CW = co-worker)

1. Schedule a 1:1 training session with CW. Go through the basics of debugging (read error message, unit testing, start with the simplest use case with known answers, etc) and make a check list together.
2. Next time CW asks for help, go through the check list together. Ideally they should do it themselves, but chances are they won't. Amend and refine as necessary
3. After 2-3 or three rounds of this, require the CW to have the check list done themselves before you engage. Be friendly but firm. No checklist: no help. Poorly executed checklist: do it again.
4. If this doesn't work, escalate to the CW's manager.

BEFORE you do any of this, you should have a discussion with CW's manager, just to bring them in the loop. Let them know that CW needs help, that the current way of doing this isn't particularly effective and that you want to try this approach. Do not complain or blame. If the manager has any feedback, incorporate it. If CW's manager refuses, you need to escalate through your own chain of command, since this impacts your own productivity.

This approach to problem solving gives me the proverbial red mist

Hopefully having a complete plan of attack will help you to calm down your emotions. Don't engage when you are mad. Take a quick break (bathroom, "Sorry, I don't have time for this right now", "I'm busy, let's talk later", etc.) to remove yourself from the situation until you have regained control.

Answer 2

So your mission is to help the other team succeed, but a member of that team needs far more help than normal, and is still just barely scraping by, and you are frustrated that the situation is not improving.

If things are this bad, the employee needs a formal training program, with a clear structure, goals, and accountability. Training members of other teams is likely beyond your remit, and even if you had the inclination and time, you have no means to hold that person accountable for their progress.

That is, the only thing you can do is to make this problem visible to the people who can solve it. Providing excessive help, aside from being frustrating for you, accomplishes the opposite of that, because it makes that coworker appear more competent that he is.

That's why I would stop providing excess help, and only provide what a reasonable person would require. Either he'll get his act together on his own, or his team will get its act together and start training him, or his management will get its act together, and move him elsewhere.

In addition, I'd make sure to provide most of my help in writing, preferably in a way that is visible to the rest of his team. For instance, by using an issue tracker, email with CC to other people who might help him, using the team chat, and so on. This accomplishes 3 things:

• it allows him to refer back to your advice, so verify that he followed it correctly, did all the steps, and so on
• it makes the amount of help visible to the rest of his team
• it creates a permanent record of the amount of help provided, allowing you to prove that you did your job even if he should screw up

In particular, I would accommodate "often privately, via video-call" only rarely. In fact, their preference for private modes of communication that don't leave a permanent record might indicate that they are actively hiding their incompetence from their team (which would not be a very productive reaction on their part, but not all people are productive when overwhelmed by their job).

To conclude, let me briefly relate a personal anecdote. In my last job, I was in a similar situation with a new employee another team had hired, which needed about 3 times as much help as a normal employee. Whenever he would call for the 3rd time about the same issue, I'd just reply with "please do what I told you last time. I have verified that it works!". That lessened the volume of calls some. 2 months later, I heard the employee had been fired, and when I informally talked with their team lead and manager, they were like

Manager: Yeah, unfortunately we had to fire him. We found out that nearly all the work he did was done by other people he had asked for help

Me: I see. Yeah, he needed a lot more help than normal. I was like answering an email every day.

Manager: What, he asked you too? He went through our entire team! Man, if we had known, we'd have fired him earlier!

On his last day, the employee sent the following farewell note:

Thanks everyone for all the help. You are the best team I could have worked with, and I thank you for all your patience. I realize now that IT is not a job I am cut out for, and will be seeking employment in another field.

Wishing you all the best

Of course, an anecdote is not data, and your situation might be different - hopefully, it is! Still, it shows that if someone is not working out, it can be better to address this issue rather then prolonging the inevitable.

Answer 3

So... how can I change this unproductive behavior of mine?

Learning to coach others is a valuable skill.

If someone's coming to you with a problem, is your first instinct to resolve the problem, or to ask how they've tried to resolve it?

I've had similar conversations several times with people when I was a content management system manager dealing with user frustrations. The gist of the conversations was:

Them: "Karl, help, this thing's broken!"

Me: "OK. Can you show me the issue you're seeing?"

Them: "Here it is" (they open the web page) "There should be a component here" or "The component's not looking right."

Me: "Can we walk through how you created it?" or "Can you show me the steps you used to create it?"

Them: "Like this..."

The conversation would either end with "Oh, it works now!" or me saying "Ah, I see where things aren't right. Tweak this."

If you can, ask really stupid questions as they're talking you through the steps.

In the example you gave - where the error message shows - ask them what the error message suggests. "This error message says it's missing a variable, how do we check it's still set correctly?" This phrasing suggests they might have done it right (even if you suspect they didn't) and "something" went wrong (which can happen) to unset it. It also guides them towards checking the error message to get the variable name and checking the variable's actually set.

Do that a few times and they should start to think problems through better. If nothing else, you get practice coaching people.

If it becomes too big a problem, a quiet word with your manager to see whether there's additional training the other person's manager can offer them would help. Manager to manager conversations can save a lot of headaches, I've had mine do that a few times when an issue's getting out of hand.

Answer 4

Train them or lead them to training

I spent roughly the first 8 months at my current company as a borderline-help vampire to anyone and everyone who would provide it. From my perspective, the issue was that I was completely out of my depth - to the point where I didn't understand what questions to ask. This boiled down to a lack of training on the programming language I use (i.e. I straight up didn't know it, and they knew this when they hired me) and the fact that I took over for someone who created the infrastructure I was using without adequately documenting it (and who didn't overlap with me). I improved by asking a lot of questions early on and learning from them. Additionally, I was very forward with these lapses in knowledge in cases where "figure it out" didn't work, to the point where my supervisor understood that I wasn't just being lazy. This is to say, I got the help I needed but easily could still be that person, or could have quit, had I not been forward about these lapses.

The fact that this person is missing these obvious markers of an error sounds to me like they don't understand that the markers are there, or don't know how marker a leads to fix a. Are they new to the environment, languages, or infrastructure?

If they are failing to improve because they aren't being forward about their knowledge lapses, you (or a supervisor) could ask in no uncertain terms if they understand. If they say they do, plan a time to chat with them about the process, so you can assess what lapses are occurring. If they do not, set a time to teach them, and when you fix one of their issues, explain what went wrong and how you would fix it.

It's likely frustrating to you because they take up your time with their issues, but I think a little training would go a long way.

Answer 5

Produce a checklist they can follow.

When you next have to help them, don't try to solve the issue directly but try to come up with a process they can follow next time and document it. If the steps don't exist somewhere you can both see them, you're destined to go round in circles as seems to be happening.

When doing this, don't take shortcuts because you already know what the answer is, but go through the "unnecessary" steps together (or explain and document why you'd skip them). So maybe you know that particular error message is vague and unhelpful, demonstrate doing a search online and seeing the wide variety of results and together decide to move on to the next diagnostic step (rolling back to a previous version for instance).

Having done this, the next time they come to you, you can compare what they've done with the list. If it didn't work on the next error, then you know it needs more steps. If they've missed a step and not done it dillegently enough then point them to it and ask them to do it again.

Reinforce that investigating issues is not always quick and taking time is vital. It may be that their manager is putting them under pressure to fix things and they're making the call that it's more expedient to ask someone else who "knows" than work it out for themselves.

This can be a lot of work, but is in an investment in getting them off your back, and identifying whether they really can't do this work, or can be helped to.

Answer 6

Is the problem that you hate dealing with this person, or is it that they're preventing you from doing your other tasks?

If it's the second, just let the person know what you need to do that day that is higher priority than helping them. If you want, you can give them some limited time box ("I can help you only for 15 minutes") or point them to someone else who might be able to help. This helps with a lot of people, because once they realize your time is not a boundless resource that they can use whenever they want, they start trying to filter their help requests before coming to you and seeing what they can figure out on their own.

It's good to actually know what your priorities are supposed to be; if you're not sure you can ask your manager what work is higher priority than helping X, and how much time in a day or week is appropriate to help X. Don't go on a tirade about how terrible X is, just ask them how much time they expect you to spend on it. A smart manager will read between the lines here and ask you what sorts of things X has been needing help with, and solve the problem in an appropriate way. A less observant manager will still give you a way of telling X to go away after a point, or at least give you an excuse for when your own work is not done on time ("well, I've been dropping everything and helping X, like you told me to").

If you really dislike the person, and would rather never help them regardless of work priorities, then you have to go to your manager and tell them you're finding it difficult to work with this person and it's making you unproductive. A normal manager will expect to hear compelling examples of what's so bad about it. They will also try to get the other person's story. So don't get personal with it, stick to the facts and let them speak for themselves. Also, although you have totally given up on this person, the manager will wonder if he can just convince you to deal with the other person, so don't expect them to just make the problem go away. Be patient, and don't look like you're the problem.

Answer 7

Senior devs helping with noobish questions during work hours is a waste of money for the company.

I would say something like "I am unfortunately very busy with project X" or "No, thank you" or "Person X may be able to help you" or "My manager has assigned me to this task, you can ask them to re-prioritize".

Or I would ask my manager if I should stop working on my assigned task to help my co-worker and, if the answer is no, relay that information to the co-worker so that the blame has been shifted.

Another option is to do the task badly, and late. They'll never ask you for help again. They might think you are incompetent, lazy or untrustworthy, but they are not your boss and it will stop them from asking.

Finally, there is an awesome technique called the "Wally reflector":

Source: https://dilbert.com/strip/2005-07-10

Answer 8

Software development is a continuous loop of issues that need to be resolved. Those issues sometimes require hours, days or even weeks of research and testing, yet it looks like your coworker gives up way too soon after facing one and goes on a search for someone "smarter". Perseverance is an important skill for a developer.

You either teach your coworker that he needs to spend 2x/3x/4x/whateverx more time on each and every issue he has or you can continue doing his job for him.

Answer 9

I'd like to propose an alternative perspective, but since Stack Exchange is incredibly pedantic about answers, I'll answer your question by saying that putting an upfront investment to help this person learn how to debug new issues is worth a shot, BEFORE escalating to a manager.

Now for the alternative perspective. From a productivity perspective, it's better if this person is able to do work. Regardless of varying rate of work output, it would be better if this person is another thread that can do work to finish tasks. The problem as I read it above is that this person is spending a lot of time blocking work because he's asking for help, and this asking for help draws resources from other developers, which supposedly brings others down.

Firstly, I don't agree with the statement "the program is telling you whats wrong". I think that's an incredibly simplistic reduction of what happens in normal debugging. Many times, an error that's surfaced can be a result of myriad possibilities. Getting an ENOTFOUND exception for example isn't trivial to debug, especially if you're new to working in node or working with services, which is extremely common for new developers. And this is just 1 example, I've dealt with 1000s of errors across all the projects I've worked in, and i would say probably < 10% of the errors were clear cut, as they were related to unit tests. A lack of understanding on how to debug an error usually results from not understanding the system or the call flow, and that's incredibly common with junior devs and not necessarily indicative of a performance issue. In college, you don't deal with a lot of the errors that you get in a corporate environment. Your issues are extremely isolated, and your codebase is like 10 files max vs 100s of files across multiple microservices. Furthermore, many corporate environments have their own internal tools and patterns that make it difficult to just simply google the answer for. The company I work for has its own internal build system for example which is a beast in of itself that even mid level devs have to be onboarded to and still have trouble with.

While a dev should have independence, this independence isn't a personality trait that's automatically given to everyone, and even if it is, there's bound to be situations in which it doesn't really surface simply because of deadline pressures or other issues. If I'm pressured to finish a code review by the end of the day, and I'm running into a really strange build issue that I can't google because it's internal to the company, and I have to a Depth first search on a 100 different internal docs to learn about the build system to fix this one issue, I'm going to opt for the easier route and ask someone.

As a senior dev, you should be in the position to provide assistance and guidance. If a problem is genuinely obvious, then rather than seeing "red mist", just point out that "hey, maybe its written in the error." Walk through how to debug an error with that person. Assuming that instructions are already written or there are docs isn't a good approach IMO because docs can be unclear or outdated, and people absorb information differently. Going back to my example, the internal build system we use is so complex we have a dedicated wiki for it. But the wiki is so complicated, that 1 dev in the company made a video on the system distilling the important parts and explaining it differently, which garnered a lot more positive support than the wiki. And even in that video, the dev states that the wiki is confusing and verbose.

Finally, consider your relationship with the coworker. You might not care about how he/she views you or working with him, but your interaction with this person will shape both his output and his impression of working at this company. I've been in a situation where I asked a senior dev for help, and he rebuffed me in a way where I basically never spoke to this person again. To be fair, I didn't do enough research at the time, but sometimes when you're in the midst of the problem, it's not clear what you're supposed to look at.

the end goal should not be reprimanding this dev nor should it be getting pissed off every time he asks you a question. If this dev is junior, this honestly sounds partially like an onboarding issue + lack of knowledge about how to debug corporate systems because of misalignment between professional development and school development, or its misalignment between what the dev is used to and what dev processes are like within your company. Getting angry at him only make things worse.

You may not have ever been in the position where you needed help from a senior engineer when you were a junior, and that's good for you. But others might have a different starting point than you. And as someone who was that kind of junior, and is now a fairly strong SDE 2, I benefited far more from the people who sat down with me and took time to explain things than from the ones who rebuffed me or just saw "red mist" and threw links to wiki docs or READMEs at me that they clearly have not read before.

Answer 10

Solve the problem and not your co-worker

You tilt because this is a troublesome worker. If you are responsible for the worker's output, it's reasonable for you to focus on how they are troubleshootng. It's also reasonabe for a decent person to want to help people, but this has passed that. If your role is getting the product working, keep your focus on that and ignore the things this worker does wrong.

Answer 11

The first question: Is the helpleech one of your reports, or do they report to someone else?

If they report to someone else, you (and the rest of your team) need to re-direct the requests to the proper channel. Only when you (and your team) are formally tasked with helping people outside of your team should you permit this.

Second, whether this behavior is allowed or not, document every instance of it, if for no other reason than to include it in any end-of-day or end-of-week reports on work done for the week. That way if helping causes you (or your team) to miss deadlines (or fall short of some other expectation), the reason will be part of the record.

Third, talk to whoever is responsible for training the helpleech. Whatever that person is doing is clearly not succeeding. If there is no such person, that's the problem.

If the problem persists long enough, HR will (or at least should) get involved, and you will need your own ducks in a row at that point.

Answer 12

It might be they lack confidence and now they have become use to asking you.

Could you 'timebox' non-urgent help, so you both have expectations on the day. Ask them to write notes, as if they were asking on SO and run though ways you fix solutions, such as regular breaks to clear the mind (I sometimes walk the dog for 10 minutes if I am stuck). "Desk time does not equal work time" is a mantra to me!

Lastly, have an informal chat (tell them about a pet you have etc..), a catch up on what is going on in life, my performance (and confidence) dropped through the floor when there was a person issue, you do not eat/sleep so your tired, so you cannot think, and it spirals. Sometimes you just need a nudge and a cuppa.

Working out the cause is key here.