Do nothing (2020)
paul.copplest.one
paul.copplest.one
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.
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.
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?
- 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 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.
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.
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.
- 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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
but it is
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.
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.
Article: https://effectiviology.com/napoleon/
HN discussion: https://news.ycombinator.com/item?id=24419042
There are many comments in this thread mistakenly thinking that OP was advocating outright ignoring the ticket forever.
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
I know some people find that annoying, but personally, I thin k that's fine. If I _am_ interruptible & I do respond to the initial ping it's nice to have some human interaction before the "down to business" part. Esp when we're all remote. If not, I just get the first & second message at the same time and respond to the query.
I think the author is also calling out "doing nothing" even for the meat & bones of the real request — e.g. in his example, even if the collegue did BLUF ("Live Client Issue: Strip integration missing from Xero") the issue still "went away" by itself without his attention if he left it 5min.
In business contexts[0], you don't have to choose between being impolite to some people and annoying others. There's a solution that satisfies everyone: just follow your pleasantry with the thing you really wanted to say. Do it immediately. Start typing your request immediately after sending "Hi $name", so that the other side sees the typing indicator. Or better yet, use the magic of Shift+Enter, supported by most IMs out there. Send a single message containing a bunch of pleasantries, followed by a newline (Shift+Enter), followed by the real payload.
--
[0] - This is slightly different in personal space. When a long-forgotten acquaintance reaches out to me, I already know they want something, and I wouldn't be offended if they skipped the useless pleasantries - but apparently enough people demand to be taken through the "how are you and your kids?" dance first, that it's unsafe to state the actual purpose up front. But in business conversation, you're not supposed to go deeply personal like this, so there's no ambiguity - the reason for communication is business-related, by definition.
I even put https://www.nohello.com/2013/01/please-dont-say-just-hello-i... in my status.
I still think adding the name after the hi goes a long way.
I not only say hello, but also ask how they are doing, and I actually want to know if they are ok, sometimes I even go on a tangent about their day or anything they want to talk about, only after all that is when I ask what I wanted.
We are human and we should behave like such, or else we'll just die little by little while we're working.
And I don't think it is a case of "bottom line up front", either, which applies to synchronous or asynchronous communication.
I think, if anything, the colleague is breaking https://nohello.com
The point of the article is that they would ignore your request to start with, regardless of how efficiently it is communicated.
The five C's also help: Clear, concise, correct, courteous and considerate.
Personally, I think this strategy can work if you intentionally ignore things after reading, but tends to fail hard otherwise.
Better to over-communicate and let others know what you're up to than to stay silent and do nothing
I get uninterrupted flow states, but if you’re in a customer facing role (and nearly everyone is or has some customer they provide a service to), you need to be able to respond and gauge the priority, manage expectations, and point people in the right direction. Often times in large companies people are trying to find the right person and you may know who it is. Other times it may be a question of how to solve the problem themselves.
If someone approaches you with an emergency multiple times, it may be a problem with that person, or it may signify a larger process problem, which can be fixed to make the organization more efficient.
Doing nothing creates churn and pisses people off.
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.
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 usually write a detailed question to a colleague whom I believe to be more knowledgeable than me. The trick is, I never send it unless I'm really stuck despite my research.
When I do send it, though, the question is good and usual suspects are ruled out.
The trick is that your efforts to summarize and clarify the problem for someone else and doing your due diligence for others that you may not have done for yourself at first before you _actually_ press send is oftentimes enough to solve the problem outright. If it doesn't work, you're ready to go with an amazing summary of the problem already.
I've on occasion done it to StackExchange sites too, nice thing about that is when you have your Aha moment, you can just tick 'Answer my own question', detail the answer, and post both together for other people's (your future) benefit.
The flip side is when I've spent 30 minutes QAing an issue and another 30 minutes writing up what I've learned, and then the response is "I brought that server down for maintenance, it'll be back in a few."
After a few times of that the sys admin is going to get some very poorly thought out bug reports from me, because I don't want to burn any more of my time QAing known issues.
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.
The person's close cycle is seeing the post first, then his team, then sub-org, until everyone has it on the news feed.
Poster can choose to pause/stop the growth. Peiple getting the link are able to view all details, but do not immidiatelly have it on their timeline.
If an engineer has an issue, pull the cord to broadcast to someone on your team. Then your entire team. Then a sister team. Then eventually to everyone in your org.
Maybe even the initial message only gets sent out after a reasonable amount of minutes, in case the engineer wants to rescind the call for help.
Thanks for the input!
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.
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/
—Calvin Coolidge
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.
My co-workers in the UK and Europe made it clear it was rude if I didn't do a good morning / how was your weekend /.etc. song and dance with them on every interaction.
Them: Hey!
Me: Hey, what's up?
Them: How is your morning going?
Me: Pretty good, yourself? Working on X, had a relaxing weekend. What's going on?
Them: Yeah, good. [back to business]
There are so much that always need fixing. If everyone would do what you suggest, nothing would ever move forward. The need to have meetings for every minor issue, is like running on brakes - unless the meeting really can be used to resolve something.
The downside is nobody notices your work, but there are upsides to it and less risk.
having said that my suggested mo is directly related to organisations that fail to properly motivate and instead implement punish dedication. ime that's the norm in many teams.
Copple: Hey can I get a raise?
Boss:
Colleague: [no response]
30 minutes pass
Copple: Ergh... nevermind, I set up a mobile hotspot and am working from the cafeteria on my laptop until it runs out of battery and then I'm heading back home.
PROBLEM SOLVED .-~'~ '
This goes for non-work stuff as well; I see a trend happening (on- and offline) where people just posit a Problem, instead of asking a question or working towards a solution. Stupid example: people saying "I'm hungry" instead of a "Wanna get some lunch?" or solving the problem for themselves in silence.
There was a thing on Facebook as well (remember Facebook? That was a thing) where people would make posts or comments to the tune of "The worst thing happened today!" without explaining themselves, instead waiting for / fishing for people to ask "What's wrong???". It's a way to fish for attention in a sense.
I always like lending a hand to someone and helping them solve problems, but as of late some of my new coworkers have been taking advantage of my nature. They don't even try to look up the docs, I'll give them a bit of sample code and if it doesn't work without blind copy/paste they'll come back and have me go through a debug session with them.
I have a hard time saying no because they are in India and have stayed up late so they could get me on a call. Yet, I also am irritated because it's apparent they've not made any effort to solve the problem themselves.
There was significant cost savings to offshore to India on paper but its not up to you to fix the reality of a 12 hour offset in team availability. If it takes 3 sessions to fix a problem, there's no going around it. They need to learn and learn by doing and you cheat them if you do it for them.
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.
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.
"I follow this advice all the time."
- Solo entrepreneur with no customers and no income.
- 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.
Sometimes is do nothing for a time period to see if it escalates, that’s what you can usually do.
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)
https://en.wiktionary.org/wiki/masterly_inactivity
and used to great comedic effect in Season 1 of "Yes, Prime Minister":
https://www.youtube.com/watch?v=ESIJ_C9mUBI
> Q: I've been asking myself what can I do to continue this run of success?
> A: Have you considered... masterly inactivity?
> Q: No, Humphrey. A Prime Minister must be firm.
> A: Indeed. How about _firm_ masterly inactivity?
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.
The problem is expecting "magic", when nobody is hired to tend to your exact problems with technology.
This is btw exactly what DevOps aimed to solve, developers and operations working together towards shared goals. It's a two-way street, or it doesn't work.
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.
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.
Bonus points if it could be disabled for particular channels/users.
Some people tend to ask as a last resort, others do it before trying literally anything else. Well, at least they used to back when I was failing to prioritize my work. Now some of them can figure out the problem on their own pretty fast, because they were forced to learn and become more understanding of the system.