How to deal with a coworker who keeps turning up the heat over things beyond my control?

Question

I'm the most senior of two software developers at my (small) company and we have a desktop support guy as well. Sometimes the desktop support guy will defer issues to me that he thinks aren't computer issues so much as website issues.

The problem is that he's incredibly persistent about issues (which, in and of itself, isn't a problem) and that every time he re raises an issue he's raised before he tries to turn up the heat and he makes increasingly bigger fusses about it until I react in such a way that causes him to go to HR to complain about me. Like last time this happened he stormed off saying "I'm just trying to do my f-ing job!" when I was trying to explain to him why I couldn't do what he wanted me to do.

This presents several problems.

• The fact that he's always trying to turn up the heat is effectively him trying to jump to the top of my priorities. If I'm working on a task given to me by the owner of the company and the thing he's having issues with has an easy workaround then people should utilize that workaround. If he doesn't agree with my prioritization of things the proper course of action, in my opinion, would be to go to my supervisor (ie. the owner) or something idk
• Sometimes the issue is one that's simply beyond my control and having it by #1 and only priority won't make a difference

Sometimes I think it can be helpful to give people the illusion that you're doing something about an issue if only to placate them. Like people used to complain about the website being intermittently slow and so what I'd do in those situations is I'd sit behind them and do nothing but watch them for 10m. If the website was slow I'd see it real time instead of it taking x minutes to get to me through the proper channels. There was no guarantee that this would actually result in a fix but it was useful for optics purposes. eg. people would see that I was giving the issue my full and undivided attention and thus they'd get off my backs. But in this particular case the issue is one that sometimes happens, at most, twice a day, and sitting behind someone doing nothing but watching them for 4h is excessive pandering. Doing it for 10m isn't so bad but 4h? That's a half day! And for this particular issue, doing that would be 100% for show. Like at least for the slow website scenario I could maybe do SHOW FULL PROCESSLIST when I saw that the website was slow but for this particular issue I can't even do that - a nanosecond disruption would cause the issue he's convinced is a dev problem and I can't move my fingers fast enough to capture real time data on a nanosecond long issue.

Answer 1

I don’t know if this situation has escalated past the point where this solution will work, but it might help in the future.

Based on your description, I think your coworker feels like the issues they’re raising are being ignored and they have no control or input over the prioritization of their issues other than to try to convince you to change your mind and stop ignoring it. If talking to you isn’t working, then they will try other methods until they feel like their concerns are being heard by someone. I know that’s not how the situation looks from your perspective and I don’t mean to imply their feeling is correct.

One way to resolve that is to change the way you react when they bring you an issue you can’t fix right away. What can you do to help them see that you take their reports seriously and that you appreciate them taking the time to report the issue?

You could have a shared place to document issues and update their status. Ask your coworker to help gather information about hard to reproduce issues. You could have a monthly meeting to go over all of the “open” issues so that you can get help from the rest of the team with assessing the impact of issues instead of shouldering that burden entirely on your own.

What would work well depends on your specific office environment; I would involve my coworker in coming up with a solution by saying something like “I was thinking about doing X to improve how we track issues with system Abc and I’d like your feedback. Would you take a look and let me know if if you have any suggestions?”

You have a coworker that is actively engaged in your work; if you can turn the negative form that engagement is taking into something more constructive, not only will you solve a problem that is distracting you from your work, you might be able to to get some help that will make your job a bit easier. In my opinion, one of the most difficult “people problems” to solve is apathy. If you have a coworker that cares, you are more than half way to a solution.

Answer 2

I've worked tech support so let me look at this from that guy's perspective. You say:

Like last time this happened he stormed off saying "I'm just trying to do my f-ing job!" when I was trying to explain to him why I couldn't do what he wanted me to do.

Have you considered that he might be right? That you make it really hard for him to do his job.

He gets called by people with various real and imagined problems. Some of them are trivial and affect only few people. Some of them are major and affect everyone. And some are in-between. Like a lot of people experiencing some weird slowdown or stutter that's just annoying. It doesn't make using your product impossible, but it increases the chance they'll switch to a competitor. Or if this is some kind of in-company service, maybe it just distracts them from doing their real job. Anyway, even though it doesn't make it impossible for people to work, it's still a problem. The question is, is it going to be fixed?

It doesn't sound like you have a very structured approach to handling issues he forwards to you. Is there an SLA that any problem has to be handled within a certain amount of working days, based on severity? Are there statistics on which repeat problems are the most frequent? If he reports a problem to you, does he even know if you're going to solve it at all? And if you decide "won't fix", when do you communicate that?

A healthy tech support desk has an SLA that says what the maximum turnaround should be for a given issue, based on its priority. Usually this is a matrix: amount of people affected times the severity of the problem determines how much priority to give to the solution. This then sets a turnaround time. For example, the SLA might say that a problem that causes significant hindrance to one person ("secretary can't print") should be resolved in five business days and that a problem that stops a lot of people from working ("nobody Accounting in accounting can log in") should be resolved in one bussiness day. So every problem has a date when it needs to be resolved. So sometimes a minor issue from last week is more urgent to solve than a somewhat bigger issue from this week, because most of the SLA timespan is over already. This system guarantees that all issues are addressed.

It doesn't sound like you have this - problems are to be solved whenever they drift to the top of your kanban board, if they get there at all.

It doesn't mean that you'll solve every problem, either. Sometimes the amount of work it takes to solve an issue is just disproportionate to the problem. But if you have an SLA for resolving issues, you at least have to do this estimate on time and send your decision "won't fix" back to the support guy.

And it's also possible that he doesn't agree - that he thinks an issue is important enough and that the time should be spent on it. You mention a problem that can be resolved by users restarting their web browser. How many tabs do you have open on your browser? How do you think customers like this fix? So maybe spending 40 hours fixing so that thousands of customers don't have this small annoyance is worth it.

But that decision shouldn't be your decision. That's your boss' decision. Basically, if you decide not to fix an issue because your estimate of work/value is that it's not worth it, the tech support guy can appeal to your boss. And if you have a structured issue tracker and he can show that hey, this issue has been reported 200 times over the last quarter, maybe it's more important than you thought. Deciding how to spend the company's money is a bussiness decision, not your technical decision.

Answer 3

You haven't mentioned any issue tracking system. If you haven't already got one, you need to make or buy one (or use something open source).

That way, issues can be logged, showing what the problem is and what's being done. Issues can be prioritised according to how big they are (who it affects and how easily they can be worked around). The ticketing system should be open for people to view.

So next time your coworker has an issue, you log it. If you don't start fixing immediately, because it's not the highest priority, then that's tough.

Answer 4

This sounds like an issue of prioritization. Prioritization comes from your scrum master, or if you don't have one then your manager. If this guy wants you to do something urgently and you think it will take you a long time, tell him to prioritize it with your manager. Give your manager some heads up that he spoke to you, but you're otherwise occupied and you'd like your manager to talk to him to prioritize the issue. Something like this:

Hey Joe (manager). I just spoke to Rob (IT guy) and he's having a problem with the XYZ widget. He asked me to look into it for him, but I'm busy this week working on the ABC feature that was planned for release this sprint. It's going to take me a while to debug XYZ, so I've sent Rob to chat with you to give you context on the issue and you can let me know if XYZ is urgent or if I should continue with ABC as planned.

You may want to give your boss a heads up that this will be happening, or else a sudden change in your work demeanour might be shocking. Something like, if you have a 1-on-1 meeting with your boss that would be best, but if not, a note like:

Hey Joe, recently something's been bugging me. Rob has been coming to me a lot asking for special requests for my help. I've been trying to help as much as I can, but it's getting in the way of doing my projects, so I'd like you to help out by taking the requests from Rob and prioritizing them into my work catalogue so we can still get our projects done on schedule.

Send that note, and then proceed as above. If the IT guy thinks his issue is that important, he'll take it up with your boss and your boss will prioritize it for you. If the issue is not important enough to take to your boss to prioritize, then it's not important enough for you to deal with.