I own a platform with several thousand unique monthly users within the company where I work.
In order to get to the point where you can raise a support ticket, we gently usher people through a flow that asks them whether they've checked our FAQs (that cover 90% of all tickets raised) and then provide them with examples of the kind of additional information that will help the support team to provide quick and useful responses.
Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" with no attempt to report what (if any) error was experienced or what parameters were supplied or what indeed their expectation for "work" was or whether this was "working" before etc.
I'm sort of coming to the conclusion that for some fraction of users, there is nothing that can be done to get them to think at all before raising a trouble ticket. Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support.
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support.
You can move this one out of the theory column and into the fact column. It is very real. :-) Not only is this common but I once even had the misfortune to be in an environment that was so high pressure and under-resourced that the only way to meet ticket quotas was "by any means necessary" I learned this and a bunch of other sketchy tricks to buy time there, such as the reverse of this, which is when the support person asks a question to the customer that is not actually relevant or they already know the answer to, just to buy time till the ticket queue is less overloaded.
It can be easy to think that since your problem seemingly happened so easily, surely it must already be well-known and you just need to identify the problem to the support staff so they can give you their already-known answer. I've fallen into this trap myself sometimes. Also, sometimes it's true. I get support emails where I see the subject line and know immediately what's wrong.
Another thing is people are trained to ignore the content of error messages, probably because usually they're totally useless or meaningless. I used to teach computers at school and kids would demonstrate the problem they're having but when the error message popped up, they're reflexively close it. I'd have to get them to start again so we can read the message. Error messages really are stupid. If you try to copy photos from an Iphone to a Windows, it can fail with either "A device attached to the system is not functioning.", "The device is unreachable.", "Can't read from the source file or disk", or "The requested value cannot be determined.". What the hell is the difference between them? What does the last one even mean?
Weeeelp… I See both sides of this. There’s some things you anticipate to go wrong, like a disk being out of space, or an API to not respond. Those are the type of things you can (and should strive to!) provide meaningful error messages for.
But then, there’s also that class of things that fail in exciting and unexpected ways: a bit randomly flipping in memory, a cable detached in an untimely moment, a missing system library that was there when the program started… you cannot enumerate all things that may fail unexpectedly, hence the only viable solution is to have a special case for those - „Unexpected error“ doesn’t sound wrong from that perspective.
Still, it’s completely useless to the human in front of the machine, so there’s that.
In such cases the dialog box could at least have a button "Show details" which provides the technical error message or code and some context, such that an advanced user has a chance to fix it. To the average noob this will make no difference, therefore A/B testing will select against it. But all the advanced users, admin will keep being infuriated.
The useless error messages are still my number one reason to avoid anything from Microsoft.
My favorite lately is "Something went wrong". Thank you, error message writer! How is this even a remotely acceptable error description? You might as well just crash.
Yes, exactly. I kept getting a "Sorry, something went wrong" with no error code when trying to give a third-party app permissions with my (paid!) Google account, and the most probably reason was that my accounts were locked temporarily due to suspicious activity.
There is no information on how long this will last, there is nothing I can do to fix this, and of course, there is no customer support available. I can't even confirm that waiting will actually fix this, as there is no error code. I thought the people at Google would know better.
Not to the user, but to the program, it can be expecting some errors as natural outcomes of a certain call, while not expecting others.
“Unexpected error” basically means “I called a function that threw an exception, but didn’t have code in place to catch it, so it hit some toplevel global exception handler that just aborts the whole thing.”
Another theory: we spend most of our lives interacting with people and trading care and attention.
Maybe some people don’t have a natural instinct to pore over text looking for a case study that sort of might fit their troubled experience.
Automatic funneling through FAQ’s and documentation may be the only way for a company to service it’s 100M users, but necessity doesn’t mean it’s a good fit for the users or that there’s something wrong with the users who don’t take to it well.
If I am looking at a company FAQ about how to open a ticket, then the emotional interaction here is that the company is putting in not only 0 effort, they are asking me to put in more additional emotional labor to figure out how to get _them_ to address the problem that is causing _me_ harm.
To then ask the user to do yet more labor to fill out a _good_ ticket for the company just adds insult to injury at that point, so it should be no surprise so many tickets have nothing worthwhile mentioned. At that point I'm frustrated, have been given the cold shoulder by your company, and have no desire to do your !@#%$ job for you, to help you fix your software, that should have been working already.....
I understand that a company might not be able to dedicate a human phone call for every ticket, but I guarantee if they did so, the mere fact that the company would be putting in emotional labor on their end to address the harm their 'bug' has done so far, would cut the number of empty raised issues down massively.
In lieu of doing a phone call for every ticket, perhaps try to figure out ways to interact with your customers when they have a problem, that isn't as emotionally barren and uncaring as an FAQ page and forced work to submit a ticket.
If customers were, on average, willing to pay enough to companies to staff an employee per 100 customers (or whatever the ratio is to allow prompt, individual service to issues), I think you’d see some companies doing that.
That’s more or less how AWS support works when you have a large enough account with them. I don’t directly see the bill for the team who works mostly on my account, but I do know that I’m paying for them (and am happy with that arrangement).
A lot of customers (users?) with low or zero spend level want personalized hand-holding. I’m not surprised that they often end up disappointed.
While it is annoying I can definitely see why some companies operate this way. I mean, if an individual customer is a large recurring revenue stream, then they should be strongly incentivized to keep them around.
For the googles and amazons out there, they have enough customers who don't require manual service that they can afford to just let go of any customers who do.
Of course most companies are somewhere between "little shop that needs your money" and "google."
I've come to accept it as the standard. You must try to solve the problem yourself, and look for help when you're completely stuck.
In many cases it's just respectful of the other person's time.
But at the same time it's starting to feel like every experience is becoming like self-checkout. You end up doing everyone's job so that the employer can cut costs.
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support.
Agree, but sometimes it isn't even the user's fault and they do things like this out of desperation or frustration.
Imagine working in a place where nothing works right, you always have to search through shit documentation to find tiny nuggets of wisdom, and everyone is always pushing to get more done in less time. Then, if you sense a chance to have a short break by throwing something over the wall to another team, you might also choose to do that rather than work even harder to try and find some missing answers for the questions you seek.
Don't forget actually putting the work in to understand an issue, and then becoming the go to person for all problems related to X as there's no chance support will solve it in any reasonable timeframe.
Yup, the old "hey, X fixed it once, they can do it again" combined with "fixing this permanently will cost too much time" resulting in "X" having to repeatedly tape together the paper airplane carrying the load of a 747.
If I've hit the point where I'm deciding to contact your support channel, I have absolutely zero interest in looking through any other documentation. Anything that's preventing me from contacting a human is a waste of time.
At the point of contacting support, I've probably already done my research and have come to the conclusion:
* I don't know how to explain my issue. I want a human that might be able to make the connection for me.
* I've already searched your docs. They're either too confusing, don't answer my question, or lack clarity in a critical detail.
* I haven't searched your docs because I suspect it's a glitch (like downtime) or bug (like clearly bad UI)
* I haven't searched your docs because, I don't care. I'm doing a courtesy of informing you of a problem, but I don't expect you to fix it.
* I'm a potential customer. I want to understand how your team will actually deal with me if I have issue. Good documentation is great, but useless if you don't have a human to support weird edge-cases.
> Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" with no attempt to report what (if any) error was experienced or what parameters were supplied or what indeed their expectation for "work" was or whether this was "working" before etc
As a user I have given up on providing this info. Any time I start a support conversation with a detailed analysis of what’s breaking, what I’ve tried, and even which resources I looked up …
… the first question is always “Have you tried this obvious thing you just said you’ve already tried?”
I wonder if some support depts (I look at you Tumblr) have this first response automated. MLOps if you want to use a fancy name, but basically a dumb canned answer based on the keyword(s) in your ticket title.
Some of them (iirc Logitech is one), surface the automated answers and make you click through that you've tried them before letting you contact an agent. I imagine others have this done but don't make it as obvious to the user.
> As a user I have given up on providing this info. Any time I start a support conversation with a detailed analysis of what’s breaking, what I’ve tried, and even which resources I looked up …
I love tickets like that, they are so rare and make a resolution so much easier. So I try to compliment them without gushing too much.
And then, yeah, I sometimes still want to confirm that they've tried turning it off and on again. I'm that stupid, so it doesn't feel insulting to think that they might be too.
Some people cannot be bothered to (or are incapable of) finding information unless it is spoon-fed to them at the exact time and rate they require. I think this might be the valid use case for support chatbots, even though I personally despise them.
Ex: I was selling an item on Facebook Marketplace. The price of the item is in the item header, and in the item description. Multiple people started a chat with me - opening a chat window that has the price again in the chat header - to ask me what it costs. I don't know what you do about that other than have a bot spoon-feed them that information.
I refuse to answer them and wait for the next customer. I'd rather wait and sell the item passively (or not at all) than deal with answering questions for people who mostly aren't going to buy the item anyway.
I think well implemented support chatbots are amazing. They collect all the information they need upfront, and forward it to the correct person who can then quickly solve my problem.
I could see that happening. My experience is mostly with the awful ones for big companies. The kind that are basically like a 1990's era text adventure game where there's only like 6 things you can possibly do, but instead of listing them out they make you guess the exact right phrasing. It's like they figured out the only possible way to make a phone tree even worse than it already was.
I think companies with shitty chatbots would otherwise have bad support anyway, though. For companies that do care about support, chatbots can be a pretty useful tool.
On the other hand: please don't make it an odyssey just to email you with a problem. I find it so disrespectful when I have to jump through a million hoops to confirm that yes, really, my problem isn't solved by the FAQs, it's something that you haven't thought of.
One particular blind spot that I've come up against again and again is on websites that aren't really for tech, they're for selling some product or service. In their ontology, customer problems are only ever to do with things like accounts or payments or deliveries, never technical aspects of the site itself. In the designers' minds, all their forms work flawlessly, all information presented to the user is consistent, all links work, etc. When any of this fails, they make it hard to report. Things like: dropdown menus for "what is your problem" that don't have an "other" option for anything not listed.
Remember that there are always unknown unknowns that need an escape hatch.
As a lot of other comments here indicate, having to confirm multiple times it's really not in the FAQs is not out of disrespect, it's out of necessity for all the people asking the same question again and again. When I encounter that I check the help pages one more time, and just go through the motions to get to the real support.
On the other hand, it does bother me when there is just no way to escalate from tier-one support. Some customer service person sends you a canned reply, you respond that the problem persists and you already know there's a technical issue with xyz, and after a few cycles they just go quiet or say "sorry can't help you". After investing time to get this far, that's incredibly infuriating.
I've also encountered your issue with "other problems", and how much it matters really depends on how easy it is to get beyond the initial support stage to someone who really listens/reads your messages.
I'm sort of coming to the conclusion that for some fraction of users, there is nothing that can be done to get them to think at all before raising a trouble ticket.
I think this is correct, but I also think it's fine. Users shouldn't have to think about your job. They have their own jobs to fill their time. Implement systems that capture and trace errors, that provide an audit trail of user actions prior to an error event, and capture the state of the system when something goes wrong (or when they hit the help button). Don't rely on users to have to learn how to describe an error in a meaningful way in order to make your job easier. That's not their job.
I agree with you if it's a customer reaching out to a company whose product they use, or service they've purchased, etc.
But if you're using internal company support, it is by definition your job. You should be expected to put in the minimal effort of reading through the "What to do when X doesn't work" documentation when your ticket subject is "X doesn't work" and the body is "help"
Having had the displeasure of dealing with several large oligopolies, I have been trained to ignore FAQ funnels/forums/chat windows/phone menus. They seemed to be designed to frustrate the user into giving up.
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support.
I would like for this to be the case, unfortunately I've run into this same thing in many open source projects where it's random users that don't need excuses. I suppose an alternate theory for open source tickets like this is: users who are trying to buff up their github activity regardless of what that activity is.
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely
What I do in these cases is link back to the docs in question format, e.g. "have you tried [link to relevant docs page]". Puts the ball back on their court and kinda puts them on the spot for not doing due diligence without coming off too passive aggressive.
On occasion, I had to also explicitly spell out "please include error messages, expected and actual behaviors, repro steps, what have you tried, etc" as a response to a question in slack chat. Some people just lack self-awareness.
I think a big problem is discovery. I search google and it shows me reddit or stack overflow and I have my answer. In larger orgs there is no one stop search for all company knowledge or if there is its painful and returns thousands of useless items.
I ran a service desk for a bit. 70% of tickets are password resets, and 95% of those resets can be done online. We deliberately put password calls in a flow that required a 25 minute minimum wait time, which actually increased the number of calls from some cohorts of users.
We reduced the call count by a significant margin by requiring remote users to report to the office if they needed a password reset first thing in the morning, after discovering that cohort was like 5x more likely to call, and most likely to call before 10am.
Some customers just don't like to do their homework and want you to do everything for them. When we get a ticket like this at our company, we have some "Saved/canned replies" to resend which basically asks them for things like "screenshot, error message text etc etc" and only then we even jump in further with any follow ups.
My favorite is when there is no info but they expect us to resolve the issue asap. :).
Supporting your customers is a different scenario than interrupting co-workers. You want to make sure you have frictionless communications within your team. But your customers are already feeling friction if they feel they need to contact you - don't make it worse for them. Just take their call and fix their problem.
I'm in a similar position, and it is an incredible struggle to convince people to raise their head up from their work and think about the context in which they are doing that work.
I've generally treated obnoxious bug reports as being my fault, in that the API or interface I've shipped is not sufficiently obvious. In that light, they're a good source of insights on possible new features or design tweaks. All the same, it's demoralizing as hell to see that onslaught of laziness from your coworkers.
Tell these people that their tickets will be closed as WONTFIX. The company should back you in just never solving problems specified in such a useless way.
If they respond to this not by opening a new, better ticket; but rather by just sitting around doing nothing indefinitely… well, sitting around for weeks when you could be working (where “helping IT to solve your problem” is working) is a pretty good justification to fire someone.
This is not the right approach. Your users finding issues in your system is your users doing a service for you. Help them do it better, don't put your head in the sand because they're not doing what you had hoped.
> Your users finding issues in your system is your users doing a service for you.
Well, yes, but if they don't report the issue in a way where it can be resolved, then they haven't actually done the service, yet. They've half-done it.
> don't put your head in the sand because they're not doing what you had hoped.
To be clear, the point isn't that these issues shouldn't be addressed; it's that users need a disincentive to laziness / an incentive to engage actively with the ticketing process. Because, by default, there is no such incentive.
By default, in most companies, IT helpdesk workers are seen as a kind of lower-class servant to the people submitting the tickets, where the entire responsibility for solving the problem — including diagnosing the problem — is placed upon them; and anything they might ask of the ticket submitter, e.g. information about what's going wrong in order to do the diagnosis, is seen as an impingement upon the submitter's valuable time. Like a maid interrupting their master's important conversation to ask how they'd like their tea.
Nothing needs to change about the workflow of helpdesk ticket submission. In many cases, it's already pretty good. As the GP states, we've tried putting tons of work into guiding people through information-collection flows in such a way that people motivated to do so will submit all useful/relevant information for diagnosis.
The only thing that needs to change, is the relative status with which ticket submitters see the IT people. The incentives, on who needs to "put in the work" for whom.
In every organization with a sane/healthy/functional IT system I've ever seen, the system is sane/healthy/functional precisely because someone high in the company, e.g. the CTO, happens to also be the head of the IT department; and therefore IT workers, in some sense, have an "ear to power."
It's a bit like the setup of the show Undercover Boss — "flipping the script" of traditional organizational power dynamics, by giving those on the bottom of the organizational hierarchy a direct line to those at the top, such that the people in the middle will get in trouble for disrespecting the people who nominally "work for them" (but, in reality, work for those at the top, just assigned to be managed by them.)
I disagree. Whether the bug can be resolved is on you, not them. It's nice when they make it easy. It's smart to incentivise them to help more than just a basic report. It's stupid to ignore the existence of a bug just because you don't like the way that someone reported it. You might deprioritise it based on a time ROI consideration but you shouldn't ignore it.
Well, extra-large FAQs run into the access/completeness trade-off. A 200 page manual is a poor substitute for targeted help. But it's true that StackOverflow and FAQs are fantastic resources.
Ultimately, though, perfect reprexes move you nowhere in the queue since no one triages based on issue report quality beyond a bare threshold.
For the most part, they get directed back to the user with a link to our "helpful guide to writing a good problem report" and put into a "pending user response" state. If the users don't update the ticket within 5 days, the ticket will go self-resolve.
where i work, alot of this could be fixed by recording/watching what users are actually doing then improving the UI so its more obvious what is supposed to be done.
its like the old story about how on a college campus some administrator put up dozens of signs about not walking on the grass between buildings, put up mini fences around the grass, etc etc, eventually someone just built a sidewalk where the students were walking.
I've been working from home for most of the past 15 years, and I've worked at some companies that had remote-first development teams and some where development started in-the-office and then branched off into remote. I believe in the former there was more understanding of:
1. Providing useful context up-front
2. No "hello" message sent while waiting for further input to be typed in
3. More emphasis on written communication
4. Less of a need to jump on a video conference
5. Use of headsets for video conferences
In some of the latter cases, the "office-first teams" still had management working out of the office and I believe that remote employees are kind of second-class citizens in these cases, and I found it less enjoyable and less productive to be a remote dev in that sort of situation.
I believe also that headsets for video conferences allows for full-duplex conversations where one or more people can talk at once and be heard, but I've not seen anybody else talk about this and may be wrong.
> In some of the latter cases, the "office-first teams" still had management working out of the office and I believe that remote employees are kind of second-class citizens in these cases
100% agreed. For a long time, I think I was the only remote employee, and always felt forgotten unless I bothered people.
Even after it became more balanced after COVID, it became clear to me that in office people were given far preferential treatment. Ultimately, it's that that caused me to leave for a remote first company.
> headsets for video conferences allows for full-duplex conversations
That makes since most video conferencing services have complex audio feedback canceling algorithms. If the mic can't hear the speakers then there is no feedback to cancel.
I found that when I'm about to ask someone a question, in the process of writing down all the details of what I want to do, what I've tried, what happened, which alternatives I've tried, and why it can't possibly be the fault of my own code, at least half the time I find the answer on my own.
So these days, I start writing down all this stuff as I'm exploring the problem, and much of the time it helps discover the solution and I don't need to send the message.
I find when I ask questions in public forums and provide a lot of detail about the issue, it seems to get ignored because there's too much information compared to other people who ask more basic questions that require follow up questions.
Also with a detailed message, people don't seem to read (or grasp) the entire thing and get fixated on parts that aren't the issue or ask questions that I already answered in my initial question.
I guess you need to know your audience and adjust your question style based on that.
What's daunting is when you don't know the audience-- like opening a new tech support case.
I could write a thorough narrative with a good description of my environment and details of all the things I tried to do. Then I get dismissed by a technician who says (this actually happened): "Your issue is to complicated to be solved over email. We need to have a call." The call lasted less than 5 minutes. It consisted of me reading my email (verbatim, because I'm an asshole and took being dismissed personally), the technician telling me what I needed to do, and me doing it.
I could go with the whole "quick question" route and spend more time than it would take to write having a back-and-forth with a technician who can't let me speak and keeps interrupting with suggestions (for things I've already tried or aren't applicable), repeated questions( because they aren't keeping written notes), or out-right confusion (because they have preconceived ideas about my situation and haven't validated them with questions).
I find it easiest to just grind away on a problem myself, reverse engineering, referring to source code, etc. Then I don't have to feel bad or make someone else feel bad. I loathe having to involve an unknown third-party. My confirmation bias says that it'll usually be bad.
Yep I suffer from this too. From my perspective it's trying to "prove" that I at least did some work on my part to figure it out and if someone were to ask me a question I would hope they do the same. I don't want to come off as the person who didn't spend a small amount of time researching myself before using up other people's time.
But it's a double edged sword. I am not the most articulate person so sometimes the information ends up becoming more confusing for the reader which doesn't help either.
I’ve been looking for “how to ask questions the smart way” for years! I kept googling the wrong title … I love how thorough it is, in the style of a Linux how-to or RFC.
I’m a solo developer and receive maybe 10 emails a day from end users. I can answer 90% of the questions with a few characters on my phone via “text replacement” so if I type: lllic it’ll automatically insert https://label.live/faqs/licensing/can-i-use-a-license-on-mor...
You know, as an example…
A few other favorites:
Llty “Thank you for the email.”
Lllmk “Let me know if this helps.”
I should really invest in Text Expander or similar. Although, maybe ZenDesk will come out with some wild AI integration that allows me to piece together a response based on my prior responses. Surely that’s coming.
Working remotely day to day, I've seen some patterns of communication that feel like they could be slightly better for this mode of work.
Personally, doing calls with screen sharing when they could have been replaced by a screenshot or a code snippet alongside a text message feels like not the most efficient way to do things. Much like the "this meeting could have been an e-mail joke".
And yet, most of the sites that out there that encapsulate some of these ideas feel a bit emotionally charged:
https://nohello.net/en/ has a facepalm as a reaction to the behavior (though the design is great)
So I went ahead and made my own little page that attempts to offer similar suggestions in a slightly more boring manner. Maybe some day I'll get a proper domain for it.
Overall, asynchronous communication just feels like one of those things where you can improve how well it works with minimal effort.
The pleasantries description feels out of alignment with the practice outline as an example. The good message still starts with 'hello', it just doesn't treat it as a statement that requires individual acknowledgement. Which is great, that practice is great, but I think the framing could use some work.
But it also has a special badge so that can communicate to other people that you bundle polite greetings in with the payload of the message, which I think is weird, and is probably a clue that the author and I don't share a cultural context here.
I help people with tech problem all the time and I don't like it when they tell me what they tried in too much detail. It means I have to read through it all and be sure I'm considering everything they said even when the likely problem and solution is already obvious. I'd rather they just say "I did this and then that happened." and if my obvious answer is wrong, then we can dig into the details. Perhaps that serves my interests more than theirs, but if you're trying to help the tech support guy, then why not?
I've noticed how much I write tends to depend on how long I think it will take to get a response. If I think it will be a live chat, I'll say just a sentence or two. If I think it'll be maybe a few hours to reply, maybe a paragraph or two. If a day or more, then often multiple paragraphs.
If it's a day or more, do you still prefer they share just a little info or would you also prefer more info if a longer response time?
Ah, yes, I can imagine in such a customer service interaction the one being paid to do it all the time may not mind it lasting as long, or at least there may be a discrepancy in preference.
I've been texting with someone over Whatsapp and she seems to treat it more like email: no read indicators, no set response time (sometimes minutes, days, or weeks), longer responses when she does. It can be so hard for me as I associate WhatsApp and texting with relatively real-time chat and the differences in expectations have caused conflict between us quite a few times.
Heh. I'm known for fixing things that don't work. I do it by looking over someone's shoulder while they show me. I don't have to say anything, just agree to watch. Then I walk away, all fixed. It's like magic.
I’d like to come up with a series of interview questions to evaluate whether someone can interpret error messages and ask reasonable questions regarding them.
Too many technicians seem to freeze up as soon as they seem an error message.
> given this code, how would you return errors to an internal audience? How would you change the errors if you knew the error was going to be presented to the end user?
Because for sure crafting actionable errors is a life-skill
Great stuff. One related hack I have for oral communication: if you mishear/aren't sure about part of what someone said, repeat back everything you did hear as part of your question, so they only have to repeat that one part. (Bonus: It validates that you were listening!)
Examples:
"We saw <garbled> and so we left."
'You left because you saw what?'
"I collect samples with <garbled> at the beach."
'You used what to collect samples at the beach?'
Otherwise, they will repeat the whole thing, or rephrase it, or even worse, start by appending detail that assumes you heard the original part correctly.
I pushed all of my support to an issue tracker, at work. The only requirement is to put a basic description of what's going on, the version that they're using, and include the error text, in full.
This immediately cut the time I spent, with support, by half. Some people realized the solution its almost always in the error text. Others spend hours trying to figure out the problem themselves, just to avoid submitting a ticket. People are strange.
I've been there. I don't like barriers personally, but I do understand they can deter people to the point of the problem solving itself or at least the urgency of the problem.
People will go through hell and back to not fill out a quick form for help.
Strangely I've found at my current workplace no matter how much time I put into preparing the initial message with detailed info, screenshots etc., it just gets ignored and we end up doing a call anyway. And to be fair it usually is quicker to resolve issues with a live/screen-sharing session, but obviously it relies on the other party's availability.
That’s because talking to someone is always nicer than perusing error message. Plus it’s a nice break. I am always a bit baffled by people who are full remote and want even less social interaction like if it wasn’t already hard enough to somewhat get to know people when you never see them.
It depends on how many interruptions those people receive during the day. If there's a question once or twice a day, the call could be a pleasant break. If it happens every 15 minutes, the person being interrupted may not be able to get any work done at all.
What I find baffling is that when someone is working from home, they can answer a call any time. When someone is working in the office, they have to find a meeting room before getting on a call. And yet, the office is officially declared to be more conducive to collaboration. When Microsoft still had individual offices with walls and doors, the open plan offices were called "more collaborative" which is 100% incorrect.
I work remote, and also have anything up to a full eight hours a day scheduled as meetings. Another video call really isn’t a break for me, and I’m not suffering from a lack of social interaction at work. Throw an error message, nine times out of ten I’ll be able to point you in the right direction after a quick glance at it, and by not insisting on getting on a call to talk about it you also get to avoid an exciting game of 20 questions about comparative availability of meeting times.
Actually I do agree with that, but...it's still annoying when you think you've done the right thing by providing all the information upfront and placing no expectation that you need the problem solved immediately, just to have it ignored.
I work on the Platform team at my company, and so we do a lot of internal tech support. It's a daily struggle to get people to ask good questions, provide details, provide links when possible, etc...
Sometimes it's really hard not to get incredibly frustrated with it. The questions can be as vague as "hey we're having trouble authenticating to the artifactory, how do we fix it?" A few people really shine in explaining themselves clearly, giving the context, copy-pasting the error message, etc, and I truly treasure those people. The proper context can really turn an hour of debugging into 5 minutes debugging
I see way too many questions in the Slack channels for teams that manage common services at work which are just “Is there a problem with [service]?”
Clearly there is, at least from your perspective, otherwise you wouldn’t be asking. Come out with it and state what the issue you’re seeing so someone can either tell you it’s known and point you at the ticket tracking an open incident, or do what needs to be done to resolve your issue.
Also learn to send multiple paragraphs in the one message. (Usually shift+return.)
Frustrating watching the description slowly emerge, line by line, like an old teletype machine or something. Get the entirety of what you want to say in one hit in one message. I know then to respond and not sitting there waiting for the next nugget of information.
I have a few people who send text messages like this. Each stream of thought comes as a separate message which can be incredibly annoying when I’ve turned my brain off for the day because I only have so many spoons for anything other than sitting there with my thoughts (actually very enjoyable) or maybe a book and the phone out of nowhere starts dinging every two seconds because I’m on the receiving end of a disjointed and scattered series of someone’s thoughts.
I love my friends. I hate how they communicate over text.
Haha yes. I have just one friend that does that. I also have a friend on the opposite end (late 50's early 60's I think?) who treats text messages like old-school letters.
"Silas,
I hope this message reaches you well. The sun is setting and I am optimistic about the future. I am wondering if you are interested in the upcoming conference, where you are sure to find many fans of that course you like. Let me know what you think and get back to me.
Not gonna lie, I vastly prefer that. Not to say I bombard people with entire encyclopedias when messaging, but…I dunno. I guess, maybe this is the result of being one of those “elder millennials” I send text messages with the kind of intentional and to the point messaging style with the brevity of someone who pays $0.50 per message like it’s 1999 and isn’t running across the house to respond to every blip and beep my phone makes.
(Interestingly once I scared off a potential dating partner who is heavily into texting constantly and called me out for my asynchronous messaging habits and I flatly responded “sometimes I just want to put my phone down and do literally anything else”)
I won't do it deliberately, but, if I'm unsure of the answer, posting what I think is the answer, in a confident way, tends to get results. ;)
I've also learned to ask fairly detailed, well-researched questions, from StackOverflow.
They bitch at you, if you ask a "stupid" question (but usually answer it, anyway), but I have found, if I ask a detailed, well-researched question, crickets chirp.
I have basically given up on SO for anything useful, these days. I'm sad, because it used to be a great place to learn.
If I ask the kinds of questions they'll answer, I get sneered at. If I ask the kinds of questions they say they want, I get ignored.
When you start at SO all your questions are so easy anyone can answer them, and so people feel smart by informing you how you didn’t follow the rules.
Soon you are asking moderately complicated questions that some can answer (but probably have been asked before). This is where you can get some help if you’re lucky.
But later you’re asking questions so advanced nobody can answer them, and they never get answered unless you remember to come back and answer your own question.
> If I ask the kinds of questions they'll answer, I get sneered at. If I ask the kinds of questions they say they want, I get ignored.
Damn that is true. I actually have 94,000 rep on Stack Overflow, but I got banned for no reason. I appealed 9 times with no response, and finally they said someone was upvoting my stuff as a scam. I tried to cooperate to clear my name, but they are just ignoring me now for weeks.
I don't care if you say hello as long as you follow up with a detailed question. What grinds my gears is developers not linking to tickets or error logs, or not pasting the error messages into the question. I'm not going to play detective and investigate your failing CI logs -- provide me with the exact line where the error occurred.
It's a little ironic how the field which continuously talks about the importance of communication doesn't understand the basics of communication, and how synchronous communication made them a luxury.
Being cooperative, specific and transparent is really all you need to start with. Even synchronous communication benefits from this.
Nothing makes me more fucking annoyed than the singular "hey". I will always, always ignore it. If it's important, fill in more detail, we're not on a phone call.
Different people have a different "style" for this. I prefer to work people whose style is similar to mine. I think most people are the same way. That's all this comes down to, sadly. There's no formula to that will ever solve this mismatch.
Be tolerant of others and gently suggest they can help themselves, in the future, by helping you. Be thankful for the times you get to work with people who share a common style with you.
Teammate: hey can we hop on a call real quick, I need some help
Me: yep, give me like 2 minutes and I'll send you a zoom link
There is almost always value in seeing what happens right before the problem, and I almost always have questions I want to ask them about it, and it's so much faster just to do it with screensharing and voice. A lot of the time anyway.
> There is almost always value in seeing what happens right before the problem, and I almost always have questions I want to ask them about it, and it's so much faster just to do it with screensharing and voice.
This is a pretty good counterpoint to my site! I think that for some, voice is just the preferred medium of communication and that should also be taken into account when possible.
Of course, I'd argue that a little bit of context of what the problem is related to could still be helpful, not to have to waste a bunch of time trying to find some Jira ticket that had some relevant info from like 2 weeks back during the call.
I did not notice that at all but in hindsight it seems obvious. I am a fan of a well crafted email. I find chat can be an excuse for half-baked thinking and I really appreciate it when people put care into their words.
I try to write good questions for stackoverflow (which I'm certainly not dissing, I think it;s a great resource used properly) and I usually miss something out and have to throw in an edit.
Fair enough, but it amazes me the number of people who pile in, clearly without reading what I wrote, seemingly unable to readjust when I point out "no, that's not what asked"
A while back I asked a question. Let's say it was about destructors (it wasn't but for example). People started answering about constructors. Repeatedly. One of the SO editors came in and pointed out that there was plenty about constructors on SO already so he was closing the question. I rather lost it at that point, spelt out DEE-STRUCT-ORRS I was asking about. He wiped all the comments (his own included), reopened the question and today it remains unanswered.
That was an extreme case of this phenomenon but stone the bladdy crows, it's not rare.
I find that with friends a slower conversation style works fine, but in any professional context (even if you are otherwise friends) you should try and make your questions snappy.
"Hey, you there?" works for a text to your partner
"Hey, are you available at 12:00 tomorrow?" works much better for your coworkers.
I like to ask "Do you have a problem or do you have a complaint?"
A problem has three distinct parts: 1) What you tried. 2) What you expected. 3) What you got instead.
Anything else is just complaining and I don't deal with complaints.
Usually there's enough information in the triad to begin troubleshooting. I will roughly know the steps to reproduce, what that reproduction returns, and what the user thinks they should have got.
If I get told "Hey, the calculation is wrong." I'm going to check the calculation. And if the math is solid, and passes all of the cases I can send it, that's the information I will give back. Usually while also asking why they think it is wrong. Sometimes, the only thing that is wrong is user expectation.
I thought the right way to get answers quickly is to ask them and post a wrong answer (under a different name) which will then cause people to correct you quickly :^)
I see this often with very junior engineers. They just haggle around before getting to the point. But something that rarely see in more seasoned people.
Sharing what you’ve tried already helps in two ways. The respondent can tell if you’re barking up the wrong tree or not and give a better, sometimes briefer answer.
Second, the respondent can tell if you’re really trying to fix the problem and are stuck, or if you aren’t bothering and are instead simply asking. I,e, if you’re worth helping.
On the r/bread subreddit, I am greatly irritated by people who post a picture of their failed bread along with the title "what did I do wrong???"
Please, tell us what you think is wrong with your bread, as well as the details of the recipe you followed. Why are you expecting us to be mind readers just so we can help you?
Person 1 wanted to have a video call and was using messaging as a way to facilitate that call.
For situations where it's a complicated problem, this can be reasonable. That said, there's little excuse for "isn't working" or being vague about the error message.
Yep. In general, advice on how to treat people better is often used as an excuse to be an asshole to people who aren't following it. Which is kind of ironic, really.
A case I personally encountered was somebody who wanted to have better relationships with people and read the book "How To Win Friends And Influence People". Unfortunately, that book is just full of advice on how to make others feel good about themselves, which wasn't their aim, and it really backfired into blaming others for not following the book's advice.
I don't like this. You're demanding a sync interaction from someone who is probably very busy.
If you have a question, just ask it. If you want to have a 5, 10, or 30 min, discussion, ask for that.
I'd prefer a long form question with all the communication from your side fully expressed, then I can ponder on it and multiplex it between my dozen other things.
As someone who receives lots of questions as a core part of my job, often concurrently via multi async comms channels, my biggest challenge is controlling cognitive load so I can be efficient and effective. Having a spot of politeness in the interaction, as the parent suggests, helps me meter the flow of information in my direction. I much prefer it. Horses for courses I guess.
Reducing the information content of a message, effectively concealing the information that you already plan to send after “Hi”, isn’t being polite to people with this personality, it’s frustrating.
I guess you can feel less obligated if the question hasn't been fully asked yet.
Still.. the question is out there. At least when it's written out, you can know if it's a worthwhile question. Or ask some quick follow-ups that they hadn't thought to nail down first.
I'm sorry, but this is wrong. By including a brief description of your problem you are actually giving them a choice whether or not to respond, rather than just guessing at your intentions. Don't worry about a huge message appearing on screen, almost all popups truncate the message after a certain length.
I think there’s a middle ground. “Hey, are you free to talk about Project X?” is a perfectly valid entry to something where you know an actual conversation will be needed. Likewise “I’m having trouble with the frobinator, when I run frob -x blah it gives me this error: XXX, are you able to help?” if you just need an answer.
Niceites are, well, nice. They help to make sure everyone remembers we’re all human beings rather than question answering machines, but we are also talking to get a job done. Unless you’re actually a good friend of mine if you drop me a message asking me how my weekend was, I know that you’re just lining up to ask me a question, but now I have to do The Dance to work out what it’s going to be about, whether I have time for it, and if I’m even the right person to ask.
I much prefer the first situation where someone says hi and that leads to a discussion on their issue to the second one. All the things the article asks for will come forwards in the discussion anyway and ninety percents of the time the people asking for help have a different problem than the one they thought they had anyway.
I am not a robot. I don’t want to be treated like one.
In order to get to the point where you can raise a support ticket, we gently usher people through a flow that asks them whether they've checked our FAQs (that cover 90% of all tickets raised) and then provide them with examples of the kind of additional information that will help the support team to provide quick and useful responses.
Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" with no attempt to report what (if any) error was experienced or what parameters were supplied or what indeed their expectation for "work" was or whether this was "working" before etc.
I'm sort of coming to the conclusion that for some fraction of users, there is nothing that can be done to get them to think at all before raising a trouble ticket. Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support.