Hacker News Reader

Comment by aaronschroeder | Hacker News Reader

Please don't follow this advice if you are in any kind of IT support role. It may make sense for developers who need large blocks of uninterrupted focus time, but even then the issue to resolve is working with team members on best practices for interrupting developers.

Doing nothing is akin to saying my time is more valuable than yours, you silly plebian. It's the sort of attitude that reinforces the unfortunate stereotype that IT people are arrogant and view their expertise and role as more important than others'.

I found great success providing IT support by always responding immediately when I'm available, and establishing focus times where others know I may not respond right away. An attitude of service and humility can go a long way in winning the respect and trust of your colleagues and supervisors.

View on HN

I disagree.

I work in IT support and get tickets sent to me. I review the ticket when it's sent to me as soon as I see it to determine if I need to make myself available straight away or not. If I don't and it's for something minor, I often leave it open for some time, because these tickets already have estimated dates on them and I still get back to the client within that time, however in doing so at least 50% of these tickets resolve themselves or the client forgot they even logged one in the first place.

If it was more urgent than it seemed at first, the cilent will chase up and then I will get back to them straight away.

You say my time is not more valuable than there's, but my time at the role is purely on helping others, so responding to someone straight away or not has nothing to do with me deciding if my time is more valuable than there's, it's me deciding which client deserves my attention the most at this moment.

There is no 'my' time when I working in a support job because all my time is already on helping others.

Agreed- I worked in IT for 4 years, and the biggest takeaway for me was learning how to "placate" requesters while reprioritizing issues: there is a balance between a cold shoulder, and outright hand-holding.

I find initially responding something like, "Hi ___, thanks for reporting this. I'm taking a look at this first thing tomorrow. Can you let me know when you first noticed this happening, and anything you've tried so far?" It takes 30 seconds to respond with something like this, but it saves hours of time later, and usually issue resolves itself. Soft skills in IT go a long way.

I think following a process to triage and resolve issues within expected timeframes is different than just not responding at all. In these examples hopefully somebody already responded to the client and set expectations, right?

A product support team is one of the most important sales engines for a business. If clients rave about your support, they will sell your product for you. Hard to do that if the attitude and approach is "do nothing" and wait for issues to hopefully resolve themselves.

This! It's totally true that being anxious to please can be wasteful and long term harmful, but there is a long way between that and "do nothing". Here are some scaled responses to low-value requests:

- Nudge for a better request. Create and refer to a standard for making requests that helps people get past their psychology and into substance before seeking help.

- Ask for impact assessment. It is fair for people to seek help before attempting to resolve a problem if the scale is large enough, but it's important you get info that helps you prioritize. Ask for it.

- Set expectations. Being honest about where helping fits into your priority queue lets the other person plan accordingly, and gives you a way to be responsive without constantly switching gears.

The main reason not to do any of the above is to obfuscate your own process, which is long term harmful to your team relations. On the other hand, when dealing with competitors, unwanted services, etc, "do nothing" is an underused strategy...

The problem is that most of that is work, sometimes considerable work. However sometimes interruptions are impossible to avoid, and also you need to do some of that work anyway.

Generally you want at least the following two tools to handle it:

"interrupt shield" mechanism - it involves having a set time for answering interruptions, and if you have more than one person on the team, having them cover different time frames as the point of contact person.

Setting expectations about time frames for reaction etc and enforcing them. Which means not just making sure you answer on time, but also to ensure you don't unnecessarily overcommit. Do not create an expectation of jumping to it.

Yup.

I've been in ops last two years, and few things will kill us more than somebody not following up on a raised issue.

Now, in responding to a raised issue, absolutely: look at priority, big picture, context; maybe point them to a more appropriate resource or person.

But look at time stamps - unspoken part of this equation is:

1. Could you have helped this person resolve this issue by 12:17 by providing them a simple answer, instead of letting them struggle to find answer (likely through somebody else who bothered to respond) by 12:28?

2. What if EVERYbody took your approach - would they still have resolved the issue by 12:28?

I think they have found an approach that works for THEMselves, and are completely ignoring what's best for the system/project/team. As the op said - this is what perpetuates stereotypes of IT.

I know this kind of colleague unfortunately. Actually there are a couple of different types that express themselves in the way the article shows (or slight variations of).

One type is the one that just never gets it. They really have no idea how to do their job but they know how to work other people to do their job for them. As long as _someone_ responds to them this will continue. If _everybody_ stopped responding to them, someone in charge might actually get a clue and just get rid of them, because their "output" would go near zero.

Some do this via being nice, sociable people, while others try it through intimidation. Like "I need to get X done. You need to help me, VP of XYZ needs this by EOD", basically implying that you're on the hook for their work and the VP of XYZ would see it as _your_ failure if you didn't do this guys work for him.

You often know your users. Some people need to be left to figure it out. Those users will call ever day to ask for things they can and should do themselves. For that sub group you should avoid helping at all costs.

Others, if they raise a flag it's time to drop everything and stop at nothing to fix it because you know they wouldn't be talking to you unless it's critical.

"What have you tried so far?" is a phrase I say a lot when colleagues request assistance. Those six words can be remarkably effective at focusing the requester's efforts without giving them the cold shoulder.

It depends on who is asking for help. But for many, it doesn't help them to answer too quickly:

- sometimes it's like giving the spout to a child who doesn't know how to use a spoon yet.

- sometimes it's like answering someone who could have found the answer by searching 20 seconds on Google.

Answering too quickly can make your interlocutors dependent on you.

Similarly, before asking someone for help, it is usually a good idea to spend 30 minutes looking for the solution yourself. The time lost is more than made up for later.

If your relationship with the requestor is a mentor/mentee or you are their supervisor, then sure, go ahead and let them stew a bit to see if they can figure it out.

If you are in IT support, it isn't your job to treat every colleague like a child who needs to learn. It's your job to serve others and remove any IT-related barriers to their productivity.

When I was doing IT support, half the requests were things people could figure out themselves if I just waited. But I was there to make their job easier and make them feel supported. Making them wait doesn't make them feel supported or instill confidence. Knowing they could call or text and have an immediate response is a huge boost to their productivity and feeling of confidence vs. wondering if or when I might reply.

> If you are in IT support, it isn't your job to treat every colleague like a child who needs to learn. It's your job to serve others and remove any IT-related barriers to their productivity.

No, it isn't. If you do so, clients will start calling you even for minor issue that they can solve themself, just because it's more easy to have you do that, or it's faster, or they simply doesn't want to learn to do new things.

> Knowing they could call or text and have an immediate response is a huge boost to their productivity

To their productivity I don't completely agree, because they don't learn to solve the problem in case it happens again, to your productivity surely not, maybe you are busy doing something, and they keep calling you for trivial things that they can figure out themself.

I think we're conflating two different things. "Do nothing" in the example given was to basically ignore the person and hope they figure it out.

Responding quickly and being available doesn't mean you don't also teach. When I did desktop support years ago I always explained what I was doing and why. Your mouse isn't working? I'll be right there. Let's see, sometimes disconnecting and reconnecting can fix. Let's try that. Yep, that worked. Oh, thanks - I'll try that myself next time!

I also found that responding quickly and having a humble/service mentality builds trust and respect. Those are the very things that give others pause and a desire to figure it out themselves because they trust you and respect your time. If you treat others poorly by ignoring them, for example, they are less likely to care if they are bugging or interrupting you.

That depends. Does your org really want to pay for IT to support everyone? Or do they want selfservice systems that only need IT when something genuinely breaks?

I'm a partner in a pretty successful services company, our success is mainly built on the prevalence of the do nothing attitude in IT departments in contrast to our 'drop no request' attitude.

This is my problem when being on the other end of "do nothing". We subcontracted our it support, this means no one in our company has direct access to systems supported by contractors. And then you need some trivial information and have to wait or ask multiple time. Compated to past when you had tools and access to get that information yourself.

"SCCM got my dog pregnant"

This was the phrase used, around every patch tuesday, when every little hiccup on our network was blamed on patching.

It was never SCCM.

As the guy in charge of patching, I built a delay in the feedback loop to allow for the 'real issues' to present themselves before researching that, yes, for the 800th time, it wasn't SCCM.

> Doing nothing is akin to saying my time is more valuable than yours, you silly plebian. It's the sort of attitude that reinforces the unfortunate stereotype that IT people are arrogant and view their expertise and role as more important than others'.

But... It's (for developers) ! They are building things, value. That is not the case for everyone.

> I found great success providing IT support by always responding immediately when I'm available, and establishing focus times where others know I may not respond right away. An attitude of service and humility can go a long way in winning the respect and trust of your colleagues and supervisors.

Or you will be the go to person for EVERY little issues that could be solved with little effort. Been there, done that, will not be that person again.

Exactly.

And in either scenario, responding "bit busy, will check in 30 mins" both allows short lived transient problems to fix themselves, and lets the sender know that yes you got their message and that you can not look at it now but you are not ignoring it either.

But it can also have a different effect. If you don't reply, the requestor does not know if you even read the message, so they might try resolving the problem by themselves. However if you say "I'm busy, will check later" they know they don't need to even try, as you are going to resolve the problem for them. That's the best case. Worst case, they'll report to their manager that you're "blocking" them and they aren't able to work for the next 30 mins because of you.

> they know they don't need to even try, as you are going to resolve the problem for them

It's unlikely that the team is best served by you treating your coworkers like children who you are responsible for teaching.

> Worst case, they'll report to their manager that you're "blocking" them and they aren't able to work for the next 30 mins because of you.

If you are, what's the problem?

You would be a sociopath’s dream colleague, let me tell you :)

As an HPC sysadmin who's helping a lot of people, I do both, selectively.

We're very helpful as a team, but this helpfulness is being abused by some people after certain point. You need to distance yourself from these people and tell them to RTFM and do their homework first.

Otherwise I can neither do my work or help anyone else.

In support, when there is technical competence disparity between the one who asks and the one who answers it is true.

But I though this was more about developer-to-developer communication where asking a question and expecting immediate answer is also a form of putting your own time ahead of the other's time.

I experience it from the other side on a couple of open source projects. I asked a question, nobody jumped in to solve it, and I had to actually read the code carefully, debug my issue and file a patch. Which kind of makes sense, because I am the most interested and informed person when it comes to my use case. Works the same way for closed communities of colleagues.

> Doing nothing is akin to saying my time is more valuable than yours…

And what if it actually is?

Technical people, in particular, are often working on improving system throughput over the long term. It can take a lot of discipline for an organization to stay focused on these goals, and unfortunately it can mean short term pain for individuals.

The other extreme is a staff that is very, very busy and yet can’t keep up with even routine upgrades and maintenance.

(This is the classic “urgent versus important” problem.)

In the context of the article, a strategy of selectively doing nothing only works, where the usual behaviour is well known to support, devs, colleagues et al. in an organisation. It is more of an exercise in how to manage expectations, mitigate frivolous attempts, seamlessly categorise and delegate requests, rather than any overall inaction.

s/IT support role/support role/

coming from an engine mechanic here...this type of 'bury your head in the sand' malarkey is seriously acceptable for IT?? let me give you an analogy:

customer: can you check the differential too? my team driver says whenever she does a full lockout the steering wheel makes a clacking sound.

me: does nothing

customer: the clacking noise is gone nevermind.

newspaper: two dead after truck wheel shears from axle and collides with minivan.

Just because the symptom goes away, doesnt mean there isnt a problem that could require your attention. "do nothing" is a solution to your own poor attitude and disposition. in the authors example that button disappearing could be a cyber attack, could be malware, could be anything.

you are making excuses for yourself and gaslighting the requestor to avoid handling something you should either automate or investigate.

I think that's a rather extreme example.

As support, you often have the knowledge to accurately determine whether a request is truly important, or can be ignored temporarily in lieu of more important issues.

A more accurate example using your particular automotive context would be a customer complaining that they don't know how to change the radio stations.

Feel free to drop everything in the middle of your engine replacement job to teach this person how to use the radio.

> Doing nothing is akin to saying my time is more valuable than yours

but it is

> Doing nothing is akin to saying my time is more valuable than yours, you silly plebian.

Well, isn't it? Just calculate how much you make per hour. Your time is more valuable than the time of anyone making less.

> It's the sort of attitude that reinforces the unfortunate stereotype that IT people are arrogant and view their expertise and role as more important than others'.

This is probably a good thing. Too often IT doesn't get the respect it deserves. Other people also view their expertise as more important than ours.

Just because a caller earns less than you means nothing. If they’re a junior clerk and they can’t enter a million dollar invoice without your help, well their time might well be more valuable than yours.

I have witnessed plenty of cases where a lower-paid employee is performing a critical function that if not resolved has phenomenal cost.

e.g any number of administrators/co-ordinators/financial officers may get "paid less" than an IT support person; but a) the IT support person is explicitly being paid to support them and b) the value of actions they make is not 100% tied to their hourly rate - processing an invoice, writing up a contract, fulfilling some SLA, whatever.

Reply on news.ycombinator.com