[HN Gopher] Do nothing (2020)
___________________________________________________________________
Do nothing (2020)
Author : gurjeet
Score : 196 points
Date : 2021-07-12 05:07 UTC (1 days ago)
(HTM) web link (paul.copplest.one)
(TXT) w3m dump (paul.copplest.one)
| ajuc wrote:
| 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.
| wombatmobile wrote:
| > Do nothing
|
| "I follow this advice all the time."
|
| - Solo entrepreneur with no customers and no income.
| 271828182846 wrote:
| 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.
| loopz wrote:
| Or, learn what applies to each situation, and either apply it
| yourself or delegate to the correct person to have a look at
| it, when their time allows it.
|
| 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.
| Redheir wrote:
| 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.
| WesolyKubeczek wrote:
| 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.
| [deleted]
| soheil wrote:
| 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.
| loopz wrote:
| Even if the pay is a bit less, all the work in IT may
| unfortunately often be both more urgent and important, than
| tending to developers. This is why one should have proper
| ticket system and internal SPOC for IT support. It's just
| patently false that IT works as support for developers first
| and foremost. Who gave developers that idea? Maybe that would
| be a great idea, or maybe developers should be able to make
| their own sandboxes. These are questions for collaborative
| projects and for leadership to prioritize (just as with
| "pipeline" - which was an old idea developers resisted until
| leadership got involved).
|
| 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.
| slmjkdbtl wrote:
| At least respond a "No" or "I'll look into it tomorrow / next
| week", basic courtesy and respect.
| brushfoot wrote:
| 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
| siva7 wrote:
| seems like an useful technique for learning
| tsjq wrote:
| Good one. My challenge is about remembering to respond after that
| x minutes gap .
| another-dave wrote:
| Sounds like a good Slack plug-in -- mute the original
| notification & only ping you after X minutes.
|
| Bonus points if it could be disabled for particular
| channels/users.
| indigodaddy wrote:
| 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.
| hermannj314 wrote:
| I found this only works with my American and Indian colleagues.
|
| 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.
| NortySpock wrote:
| I haven't had any complaints (yet) if I gently push the
| conversation towards business with a response to the initial
| pleasantries followed by "What's up?", "What's cracking?",
| "What's going on?" etc.
|
| 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]
| indigodaddy wrote:
| That is my rule for external teams/groups/pings. Within my
| own team/group/mgmt, I relent to chit-chat.
| Stubb wrote:
| "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
| trhoad wrote:
| 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.
| disgruntledphd2 wrote:
| I work with someone who uses this strategy, and normally what
| happens is that they ignore the original communication and then
| come back months later wondering why their
| data/product/whatever isn't available.
|
| Personally, I think this strategy can work if you intentionally
| ignore things after reading, but tends to fail hard otherwise.
| makeitdouble wrote:
| > 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.
| joelbluminator wrote:
| Your boss should do the same maybe.
|
| Copple: Hey can I get a raise?
|
| Boss:
| sdevonoes wrote:
| Copple: ah no worries - it's sorted already (I just quit!)
| cableshaft wrote:
| Going to be me in a couple of days. Although it's been six
| months in my case (since I last brought it up, actually been
| a couple of years since I started pushing for one, would have
| left already if not for the pandemic).
| Deestan wrote:
| Copple: Hey, I forgot my key card, can you let me in?
|
| 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 .-~' _~_ '
| booleandilemma wrote:
| 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.
| majewsky wrote:
| In many cases, they actually need a rubber duck and don't know
| it: https://en.wikipedia.org/wiki/Rubber_duck_debugging
| WesolyKubeczek wrote:
| You need to actually believe that the rubber duck is going to
| bestow its wisdom upon you for it to work.
|
| 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.
| OJFord wrote:
| I do the same thing - I just haven't quite managed to reach
| the level where I do it as a deliberate method, I always
| think I'm going to send it!
|
| 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.
| evilduck wrote:
| In your case, your rubber duck is the email editor.
|
| 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.
| swader999 wrote:
| I explain my code to my cat. It always helps.
| yellowstuff wrote:
| There can be a thin line between doing too much of your own QA
| and too little.
|
| 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.
| [deleted]
| motohagiography wrote:
| 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)
| einpoklum wrote:
| Indeed, "Masterly Inactivity" is an established concept:
|
| 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?
| m3kw9 wrote:
| 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.
| Markoff wrote:
| More like slow down your response (to see if things won't sort
| themselves out) than do nothing.
| drloser wrote:
| 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.
| [deleted]
| RalfWausE wrote:
| I personally call this 'fish market' system: Whoever shouts the
| loudest get served ;-)
| krona wrote:
| 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
| neilv wrote:
| 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/
| Waterluvian wrote:
| 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.
| ToFab123 wrote:
| 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
| another-dave wrote:
| I think you're responding particularly to the pointless "hi
| copple", first message?
|
| 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.
| TeMPOraL wrote:
| I hate those pointless messages, to the point I developed a
| stress reaction to them.
|
| 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.
| swader999 wrote:
| It is better to put the salutation and the request in the
| same comm. Then it is perfectly appropriate and even
| professional to address your recipient in a cordial way.
| rompic wrote:
| This!
|
| 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.
| combatentropy wrote:
| Newspapers had the same rule, called the inverted pyramid,
| https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
| [deleted]
| heurisko wrote:
| I don't think this is the primary point of the article.
|
| 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.
| swader999 wrote:
| Similar to business writing - in any correspondence you need to
| put your hard request in the first sentence after your
| introductory salutation. Be very explicit what you need and the
| following paragraph should provide details that expand on it,
| enabling strategies. Lastly, justification or selling if
| warranted.
|
| The five C's also help: Clear, concise, correct, courteous and
| considerate.
| codingdave wrote:
| > 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.
| alfor wrote:
| 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.
| jeroenvlek wrote:
| That sounds a lot like Rubber Duck Debugging [0]. I do it all
| the time and in my first full-time job, my colleagues gave me
| an actual rubber duck. [0]
| https://en.wikipedia.org/wiki/Rubber_duck_debugging
| huijzer wrote:
| 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
| k__ wrote:
| 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.
| mauli wrote:
| Nice idea coming to my mind reading your problem: time based
| growing circle visibility
|
| 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.
| sovietmudkipz wrote:
| I like this idea. It maps nicely to the concept of 'andon
| cord' applied to software engineering.
|
| 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.
| k__ wrote:
| Interesting idea.
|
| Thanks for the input!
| pif wrote:
| 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.
| Cthulhu_ wrote:
| Yup, don't try and fix a problem they themselves don't
| understand either. Don't try to fix a problem if they just say
| they have a problem - see if they ask you to fix it (= offload
| it to you) or if they ask you a specific question that you can
| help or refer them to something.
|
| 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.
| cogman10 wrote:
| Any tips on how to do this nicely?
|
| 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.
| swader999 wrote:
| I typically ask them what they've tried to address and then
| tell them the tasks to try that they haven't already.
|
| 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.
| aaronschroeder wrote:
| 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.
| jdauriemma wrote:
| "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.
| Deestan wrote:
| 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.
| rytis wrote:
| 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.
| pc86 wrote:
| > _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?
| jt2190 wrote:
| > 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.)
| ChildOfChaos wrote:
| 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.
| wildrhythms wrote:
| 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.
| aaronschroeder wrote:
| 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.
| bayindirh wrote:
| 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.
| drloser wrote:
| 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.
| aaronschroeder wrote:
| 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.
| xupybd wrote:
| 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?
| alerighi wrote:
| > 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.
| aaronschroeder wrote:
| 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.
| evrydayhustling wrote:
| 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...
| 45ure wrote:
| 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.
| oytis wrote:
| 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.
| NikolaNovak wrote:
| 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.
| tharkun__ wrote:
| 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.
| xupybd wrote:
| 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.
| zaat wrote:
| 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.
| vincnetas wrote:
| 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.
| Damogran6 wrote:
| "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.
| nimbius wrote:
| 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.
| Phenix88be wrote:
| > 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.
| _ZeD_ wrote:
| > Doing nothing is akin to saying my time is more valuable than
| yours
|
| but it _is_
| matheusmoreira wrote:
| > 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.
| doctor_eval wrote:
| 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.
| NikolaNovak wrote:
| 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.
| timomax2 wrote:
| This is crap advice. Way to piss off your clients.
| fart32 wrote:
| I wouldn't follow this advice when it comes to clients or other
| developers. But I intentionally postpone stuff like this when
| it comes to pretty much everyone else. I read it, evaluate if
| it's critical and then I'll either take an action, or postpone
| it (usually replying I'll deal with it the next morning).
|
| 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.
| sdan wrote:
| 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
| mlac wrote:
| Especially working from home. It just looks like you were away
| from the computer and not paying attention.
|
| 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.
| torh wrote:
| 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.
| woutr_be wrote:
| I often face the same problem. Sometimes I just don't really
| know what to look for or how to search, asking for help through
| email / IM often helps, because I need to explain the issue to
| someone else, and articulate what is expected. It just helps me
| rephrase my internal thought process, and take a step back.
___________________________________________________________________
(page generated 2021-07-13 23:02 UTC)