5

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.

17
  • 5
    So, there is no-one other than you and no process for setting priorities on fixing issues with the things you’re responsible for? Maybe it’s time to be more transparent about the list of things that are “on your radar” and to set up a place to document issues that have been identified so it doesn’t seem like they’ve been forgotten. – ColleenV Jan 25 at 17:45
  • 2
    @neubert It’s really tough to be in that position... I think setting up a process would help you manage other people’s expectations. I find it’s a lot easier to change the environment than to change people. If you can give your coworkers a place to add a “happened again today” comment and attach a log it might defuse some of their frustration. – ColleenV Jan 25 at 17:51
  • 1
    I've seen a number of cases in the past where flaky code, with a nominally easy workaround, has come in practice to dominate a substantial part of a support FTE (not to mention the time it cost the clients collectively), or to otherwise consume a large amount of administration time (including that attributable to blame, complaints, judging whether the situation is one to which the simple workaround applies, backfilling disgruntled leavers, and reproducing knowledge of computer systems that must constantly be tickled just right to get anything done). Food for thought. (2/2) – Steve Jan 26 at 3:43
  • 2
    @neubert, if it's annoying (and certainly you say your support colleague is expressing vehement annoyance), then are you sure it is truly an easy workaround? Have you consulted the end users, and asked them whether they see it as a trivial issue, or as something that is confusing or significantly inconvenient? – Steve Jan 26 at 4:38
  • 3
    How often does that come up? If I need to close and restart my entire browser ten times a day for a bug, I'm going to raise holy hell too, because that's just ridiculous. If it's once a week, I'm just gonna be annoyed, but accept that there's more important stuff to do. – Erik Jan 26 at 8:16
7

I don’t know if his 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, the most difficult “people problem” to solve is apathy. If you have a coworker that cares, you are more than half-way to a solution.

4

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.

8
  • I agree with a lot of what you’ve said here, but I think you missed the part about how small the company is... I don’t think there’s a service desk. I think there’s one support person and that too much process could be just as much a problem as having too little process is currently. – ColleenV Jan 27 at 15:44
  • I think much of this can be implemented without massive processes; a shared spreadsheet and some definitions of SLAs. The SLAs help everyone because they give the users clarity on when their issue will be addressed but also help the help desk to decide "won't fix" which either gives everyone closure or allows the issue to be escalated (and again gives closure, it's someone else's decision now) – matt freake Jan 27 at 16:26
  • 1
    @mattfreake I agree, and I’ve upvoted this answer. It was more a comment about the perspective it seems to be written from than a criticism of any point in particular. I have worked in companies as small as two people and in my experience when you use “big company” terms like “service desk” and “SLA” folks immediately push back anticipating something burdensome even when that’s not what you’re proposing at all. – ColleenV Jan 27 at 16:33
  • 1
    @some_coder SLA is service level agreement, it stipulates when and how issues are to be reported, categorized, analyzed and fixed and the financial repercussions of not fixing them (i.e. you pay your customer money for not fixing it in time or he pays you money if he incorrectly reports something trivial as absolutely critical for our business fix it now fix it fix it!) – mishan Jan 28 at 9:25
  • 1
    Yeah I didn't want to advocate adding more "process" than needed, but I think the frustration of the tech support guy shows that right now there's not enough process to guarantee that issues get resolved within a reasonable timeframe. That's in essence what an SLA is - an agreement how much effort and speed you can expect. Tech support guy doesn't have any clue what he can count on and that makes it hard to do his job. – ObscureOwl Jan 28 at 16:17
2

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.

3
  • We use Jira but the way our organization works we don't do sprints - we do it more kanban style, by necessity. Sprints require you don't take on additional projects during the course of your two weeks sprint and any dev who pushed back on impromptu projects being thrown on their plate would be fired. Also, whereas sprints normally have a planning phase, my company doesn't. There's a lot of it that's ad hoc. Usually, it's the managers who create the tickets and they have the benefit of having the bigger picture but the desktop support guy doesn't and thinks his issues should be #1 always – neubert Jan 25 at 23:19
  • "If you don't start fixing immediately, because it's not the highest priority, then that's tough." - but then he might just be back to square one? If you impose formalities on the recording of issues, but then still don't process them at an acceptable rate, then in general you'll only up the ante of aggravation. Putting the issues on a list is only a solution if your users are primarily concerned that you've innocently forgotten about issues, not if they are concerned that (in their view) you're intentionally ignoring issues or have the wrong order of priorities. – Steve Jan 26 at 3:06
  • @neubert ultimately, your boss decides what your priorities are. If your boss says something is important, you bump it up the priority list and start working on it. – Simon B Jan 26 at 10:04
1

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.

1
  • 5
    "Prioritization comes from your scrum master" What? No. Just a big fat no. In Scrum, prioritization is the Product Owners job. If not, it's not Scrum. If it's not Scrum, what is a Scrum Master doing there? – nvoigt Jan 26 at 7:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .