Do nothing (2020)

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.

This is called the Napoleon technique. The idea is to postpone addressing something that's likely to resolve itself.

Article: https://effectiviology.com/napoleon/

HN discussion: https://news.ycombinator.com/item?id=24419042

The military has a writing style to combat this issue.

BLUF is a military communications acronym—it stands for "bottom line up front"—that’s designed to enforce speed and clarity in reports and emails.

It has previously been discussed here. https://news.ycombinator.com/item?id=20964907

Good advice. I (proudly) ignore about 60-70% of communication I receive. The important stuff bubbles to the top naturally. The rest goes away. If I jumped on everything, all the time, I'd actually end up getting nothing done.

As someone who's gone through this recently, I don't think this is the best advice

Better to over-communicate and let others know what you're up to than to stay silent and do nothing

> The reason people make these requests is that it removes a burden from the requestor.

It also raises a question about your product/system. Someone had a problem. They asked for help. They figured it out. All is well... but they did have a problem, and that should be acknowledged. The software industry is moving more and more towards a UX and even a CX focus, where disregarding problems is questionable behavior.

I'm not saying it is a junior engineer's job to identify, explore, and devise a fix for every problem, but it should get logged in a way that the product team can see trends in questions to know where to improve.

I had this happen to me yesterday.

Hey, can you tell me why my query is slow?

<5 minutes later>

Nevermind! I had a typo.

It’s like people want to outsource their problem solving to other people’s brains.

I use the same technique when I feel the person has the experience/wherewithal to answer the question themselves without help. Basically it's like being treated like a rubber duck: https://en.wikipedia.org/wiki/Rubber_duck_debugging

I building an microblogging tool for company internal communication.

One thought I had, was, enforcing a delay for every message written.

But I don't know if I choose one or ten minutes, or if it's a good idea at all.

Or if I should just impose a fequency, like times a day new messages, etc

The idea I had was something like in the "Do nothing" article here.

People could write messages and might even delete them a few minutes later, because they solved themselves.

Also, it would remove "emergencies" communication from the timelines.

I have a jr. engineer this works well with.

You need to be very very careful not to let this become an excuse to not do your job. But sometimes you gotta take the training wheels away.

Two problems here:

1. Someone is ignoring a colleague's request for help. At least give some sense of whether and when you're going to help.

2. Don't just say "hello" in chat. https://www.nohello.com/

Doing nothing is often a good way of naturally assessing the importance of a request. Generally, if the request is really important, the person will keep on asking until you respond.

"If you see ten troubles coming down the road, you can be sure that nine will run into the ditch before they reach you."

—Calvin Coolidge

I have my own rule— it’s that I don’t respond to “hi and wait”’s on Slack (unless of course from within my own team/group/mgmt). “External” hi’s just go unanswered. Simply because I get too many of them.

If the person can’t take the time to include a concise summary of exactly what they need with that “hi,” well then, they’ll move on to someone else (they’ll be simultaneously pinging various other people on our team in any case). Usually they will get the picture and follow up within 15-20 minutes with their actual ask, but if it’s not important enough for them to make that extra effort, then it’s definitely not important enough for me.

BTW, I never do the “hi and wait” thing myself. If I need something from someone on another team, I of course say hi. But in the same initial communication, the next sentences are a summary of exactly what I need, as concisely as possible. I do this as a courtesy, because no one has time for hi’s, nor chit-chat.

As far as the actual article though— I highly do NOT agree with telling someone something is OK or resolved, when it’s actually not. That is simply very bad.

Very true. Knowing how to prioritize the most pressing work at hand is very important for the person having to make those choices. For those on the receiving end, try to remember the story of the boy who cried wolf.

A lot of times, people ask questions before they even know what they are trying to accomplish. Give them 5 minutes, and they may solve their own problem, which is a win-win.

there's definitely something to that approach. maybe not "do nothing" but "do little". I observed many times that doing less is even preferrable. it helps staying out of trouble. instead everyday you do just as much that you can refer to it - most of the times nobody seems to care about how "much" that actually contributed. as long as you can say I worked on X during your slot in the daily. beyond that learn from George Costanza how to seem busy - ask questions, complain about something, have a little meeting about every other day. especially the latter helps you appear as a committed teamplayer. doing more usually just increases risk of being blamed for something and attracts more work due to having to fix your own stuff in stressful and observed situations.

Your boss should do the same maybe.

Copple: Hey can I get a raise?

Boss:

As an industrial software developer, my golden rule when dealing with support requests is: I will not do anything until they tried whatever they can try. If they just want to offload the issue to me, it will be a dead end.

I did nothing.

Mom's email was broken (@verizon via aol). The web mail is working. So what, the imap/smtp server is down. Tell her the server is broken. If she has immediate need just use webmail for now. It'll probably work later.

Come back the next day and she's blown 2 hours waiting on phone tech support. They've got her generating temporary passwords or some shit that their documentation has no mention of (This is standard imap/smtp config with SSL and a slightly modified username). She's frustrated and deletes the whole account in her email client.

Sometimes it backfires.

I find I resolve a lot of problems by speaking about them to someone, I think that is a big part of this. We think that we think alone like a computer, but when we are stuck we often need to talk it through to someone.

There are questions, and there are questions.

You learn which to react to, it's an experience thing.

You also learn about people who want you to do something, only to have you redo it, and redo it yet again, until it's back to the original state. In which case, you learn to do nothing.

And there are people who think they are important, but in fact it's _your_ job that's more important. Postpone it, maybe they pester someone else or it can wait.

> Do nothing

"I follow this advice all the time."

- Solo entrepreneur with no customers and no income.

This reminds me of a lesson I got from a guy working in a specialised factory. Always when he got a call, in panic, for some new part that was needed, he would do nothing and call them back 30 minutes later to ask for details. In 90% of the cases, they solved the problem themselves. In the other 10%, he started working on it straight away

In my first job we had guidelines for using communication:

- if it needs to be answered immediately - phone or come personally

- if it needs to be answered within 15 minutes (or was it 1 hour? at any rate - not immediately and not long time) - use jabber (text communicator used at the time)

- if it needs to be answered some time today - write an e-mail

I quite liked the system. It reduced distractions a lot.

Maybe by doing nothing, he went to someone else that did it for you! Or he sorted it out himself, but you won’t know. Usually this “do nothing” solution is very situational and you will need lots of experience to know when.

Sometimes is do nothing for a time period to see if it escalates, that’s what you can usually do.

Very close to another concept called, "masterly inactivity," that appears in a number of disciplines.

https://medical-dictionary.thefreedictionary.com/Masterly+in...

https://www.theguardian.com/football/2021/may/10/busy-doing-...

and:

https://timharford.com/2021/04/cautionary-tales-masterly-ina... (podcast from FT columnust)

This exact scenario happened to me twice just today. Amazing what waiting for a little while before responding can do.

The downside of this, however, is that you miss out on information. What if it's multiple folks asking the same question, but then figuring it out on their own? Or what if the requester "figured it out" in a way that doesn't actually solve the issue or outright introduces new ones? For me, the "nvm I figured it out" message is almost more frustrating than the "hey can I ask you a question" message.

Sadly IT support and to some extend sysadmins (SRE?) need to cope with the fact that even though they may work closely with engineers their pay is typically much less and are there to help those teams. This causes resentment and sadly leads to the arrogant sysadmin/IT support stereotype. Now there is concrete reason why it makes sense to be arrogant and not respond right away. I hope no one takes this advice except the very overworked and stressed who'd probably be wiser taking another job anyway.

> At some point we realise that we aren't paid to be psychologists, we are paid to solve problems in the order of most important first.

As a senior programmer I'm paid to do both. Sometimes to answer a question you have to guide the other person through the entire process of clearing up their problem until they get the "a-ha!" moment.

So depending on your seniority and responsibilities, you might have to teach people how to acquire problem-solving skills.

> At some point we realise that we aren't paid to be psychologists, we are paid to solve problems in the order of most important first.

This advice will have wildly different effects depending on the organization you work in. Hopefully you already know how it would go down for you.

I personally call this 'fish market' system: Whoever shouts the loudest get served ;-)

Good one. My challenge is about remembering to respond after that x minutes gap .

At least respond a "No" or "I'll look into it tomorrow / next week", basic courtesy and respect.

More like slow down your response (to see if things won't sort themselves out) than do nothing.

This is crap advice. Way to piss off your clients.