the language barrier

November 27, 2009 10:13 PM

You're talking to some people about computers when you realize that somehow, they know even less than you do. How do you figure out what they need to hear? How do you phrase it clearly, simply and accurately, but not condescendingly? How do you know when you're screwing that up, and how do you recover? And conversely, when people talk to you about computers, how do you figure out what they mean even when they are using a different set of jargon from what you've learned, or incorrect jargon, or plain don't themselves know what they mean?

My job frequently requires me to discuss technical topics with people of all levels of expertise. I can handle myself just fine when I'm the more ignorant one, or when we're about equals, because I just ask a lot of questions, but somehow when I know more than the other guy, things just go south.

To give a recent example, it took me at least five minutes to explain why it would be a waste of IP space to assign every computer a static IP and also reserve it a slot in the DHCP pool. Later that same day, my boss asked me to set up some arrangement that passed through a middleman server for analysis but, in case of technical difficulty, failed down to letting clients send data directly to the destination. It was honestly ten or fifteen minutes before I realized he was saying "direct pass-through" to refer to the failsafe mode where the middleman server wasn't doing any passing at all.

posted by d. z. wang to human relations (14 comments total)

It helps to take an approach that standardization is always better, because it's easier to support if everybody is set up the same way, and there are fewer exceptions to track. (If you're not running a large network yourself, you can still use the "the next person to look at this will expect it to look like this" method.) You don't want the users to come up with solutions - you want to give them a single option, find out what about that option doesn't meet their needs, and then make the fewest changes to the standard to accommodate their requirements. Repeat this until your users preface their requests with "I know it has to be supportable, but..."

I usually start by describing the usual way to do things, to establish a baseline; often, the standard deployment already does what the customer/user wants, they just don't realize it yet. It also lets you establish some basic terminology. So for the DHCP example, I'd say, "Typically, I would set static IP addresses for only those machines that need to have a dedicated IP that never changes, like mail servers, and then the user computers would get a dynamic IP address out of the DHCP pool, because that will let us conserve our IP addresses. How many of your computers would require a static address, and why?"

For the jargon mismatch, "I've always heard it called" is my catchphrase. "The firewalls/IDS servers I'm familiar with can either let all the traffic through when they fail, or block everything until they're fixed. I've always heard the two modes referred to as 'fail-open' and 'fail-closed', but maybe it's called something else by another vendor."
posted by five toed sloth at 11:40 PM on November 27, 2009

Maybe it's just my experience, but I've found that when someone's level of technical expertise is below mine, it can be helpful to ask even more questions than I'd ask if it were the other way around (then again, I always ask a lot of questions so...could be just me). I tend to more or less ignore the jargon and focus on the deliverable or the end goal "Ok, so when we're done, you want it to do or look like....ok, there are several ways to do that." Give people many chances to clarify what it is they're saying using simple language. "So you want people to be able to normally send material through a server to check for (xyz) and then what do you want to have happen if that doesn't work?" Five toed sloth's 'typically' approach can help in that step.

Also helpful, in some cases (like networking): diagrams. Sometimes if someone draws what they want, even stick figure style, it can make more sense to you. The big keys are:

1) Don't get caught up in terminology--the point of terminology is to act as a shortcut for people in the know, not as a barrier to people who don't.

2) Keep your tone even and genuinely curious and helpful: you want to make sure you give them the best possible product as quickly as possible so you're just making sure you understand what they want/need.

3) Remember that it really is ok to appear stupider than you actually are for the purpose of finding out what you need to know (yeah but...I learned this lesson the hard way). There is a delicate art to doing this while still appearing competent to your boss/coworkers, but if you can skate close enough to that line, you'll get the best possible information without making other people feel like an idiot (which, for a lot of people, is their experience of talking to someone more technically competent than they are).
posted by eleanna at 12:12 AM on November 28, 2009 [5 favorites]

And conversely, when people talk to you about computers, how do you figure out what they mean even when they are using a different set of jargon from what you've learned, or incorrect jargon, or plain don't themselves know what they mean?

You know, some of the most technically-savvy people I know routinely use terms like "the thingie" and "that goo stuck onto the packet", or whatever is necessary for the other person to understand. Conversely, I've known many fakers who insist on using "proper" terminology, even though they really have no clue what they're doing.

Not slagging you, here, just a warning: using slang terms doesn't mean one is a know-nothing.
posted by rokusan at 3:57 AM on November 28, 2009 [1 favorite]

If I were your manager I would say you were an IT guy first, and a consultant second. Bearing that in mind, "I've got it under control" is all you ever need to tell anybody, because the more information you give them, the more questions they're going to ask, and the more answer you give them, the more they will erroneously believe themselves to know, and nothing will ever get done and you'll just all be sat there pushing bullshit around the room like dung beetles.

"I've got it under control, we're going to try a couple of things, I'll give you a full report in due course."
posted by turgid dahlia at 4:38 AM on November 28, 2009 [1 favorite]

Not slagging you, here, just a warning: using slang terms doesn't mean one is a know-nothing.

Seconded. I've worked with absolute systems geniuses who have asked me to pass them the wire...the fucking wire thing, in the box. That thingy!
posted by turgid dahlia at 4:40 AM on November 28, 2009

Sometimes self-deprecation goes a long way, even if not true, toward making sure everyone is using the same terminology without making you sound condescending. For example, since you mention DHCP, I've used this line with colleagues before, "hey, I know sometimes I use the terms 'fixed IP' and 'static IP' interchangeably, but since we're designing the address assignment policies for our new network, I want to make sure we are all know what we are agreeing to...".
posted by ellenaim at 4:59 AM on November 28, 2009

This is the frustrating thing about when I'm asked to do technical support. Some people seem to think that "web address" and "email address" are the same thing, for example, so when they say "I can't get through to this web address" it's a 50/50 thing whether they're using Explorer or Outlook. I used to get impatient but (since I work on a small campus) I usually just say "I'll be over in a couple of minutes" then I ask them to show me. Then I show them the fix. Eliminate the need for any technical words at all.

When it's to do with deeply technical matters (for example, the failover web server I just installed) I leave out all talk of rsync, authentication, MySQL replication, etc, and just go with the shiny "take-away": "We've got another webserver in Newark, NJ, which takes over when our main server dies." If they need any more detail, I apply the Stubby Pencil Rule: if I can draw the thing on one sheet of A4 paper, with a stubby pencil, it will probably be comprehensible even to non-technical people. Sometimes, I scan the pic I drew and put it in a PowerPoint: it looks a lot less intimidating than something I might draw in Visio.

If you need them to learn and take-away so they can talk sensibly about it later, point to parts of the diagram and say "See that bit? That's called a load balancer. It's like a traffic cop sending cars down four different lanes and trying to keep the same amount of traffic in each lane. That means, when someone clicks on a link in Explorer, they could get it from any one of these four servers. That means things can still keep working even if one or two of the web servers die."

"This bit is our email firewall. It looks at all our email before it gets sent to Outlook, and strips all the sh*t off of it. It removes spam, viruses and other crap and burns it, then sends clean messages to our main mail server."

Still, people can be dense about this kind of thing so mainly I keep the technical stuff to myself and just talk about effects. Some of my users, I arranged training because they need to know technical stuff, and I got so frustrated that they kept forgetting it from one meeting to another. I get an outside consultant to handle that, since (as we know) a prophet always has least respect in his own village.
posted by BrokenEnglish at 6:09 AM on November 28, 2009 [1 favorite]

I've found that it helps to describe a system/situation starting from high level down to the more specific as needed.

if someone is using unfamiliar jargon, ask more questions. "failsafe mode? wait, explain this to me... what happens when it's in failsafe mode? how does it get triggered, and how do we find out about it?" and then draw equivalences to shared terminology/jargon or just plain handwavey english. "oh, so you mean when this happens it just doesn't send data at all? okay."

if you're explaining things to someone unfamiliar with them, it helps to break it down into three parts - quickly explain what it is you're about to tell them, then the actual meat of the explanation, then a quick summary wrapping it up again and bringing things back around to the problem at hand. the summaries can be just one sentence, even, but it helps ease the flow from "blah blah conversation" to "TECHNICAL INFORMATION YOU ARE LEARNING A THING HERE" and back.
posted by rmd1023 at 6:15 AM on November 28, 2009

I found this in the Phil Agre thread, and saved it, 'cause I do helpdesk work and run tickets. This is the best explanation of the way my mentor taught me to communicate with clients, and it's gotten me far.
posted by aaronbeekay at 6:34 AM on November 28, 2009 [4 favorites]

Try not to use jargon they don't understand, and don't correct theirs unless absolutely necessary. (I have a friend who, when it comes to computers, will talk over your head and if you indicate you don't know what he's talking about will just continue to talk over it... Yeah, no. Don't do this.)

I would suggest, if they don't know what they're talking about, asking them to clarify. Perhaps something like, "What do you mean by XYZ term? I'm not familiar with that." You could also spell out the actual definition and ask them if that's what they mean... Not sure if that would be condescending, but I've had to do this a few times in normal conversation, and since I've moved I always follow it with, "Ohhh, we say ABC where I'm from!" so they assume it was a miscommunication instead of me being an ass.
posted by biochemist at 7:38 AM on November 28, 2009

Much of the job of communicating with those who aren't as knowledgeable as you in the subject at hand is specific, not only to the subject at hand, but to the particular person. You probably already know that you often need to figure out as best you can what they do and don't under stand, but doing that can be different every time. Experience teaches you which misunderstandings are most common, and which metaphors/explanations/phrasings will work best, but there will always be situations where you'll encounter someone with a slightly different confusion. In the best situations, you'll be in person, so you should watch the other person for signs of confusion or misunderstanding. Of course, the source of the confusion may not appear anywhere near the signs of confusion. In BrokenEnglish's example above about "web"/"e-mail" address confusion, it's quite possible for a long time to pass before they mention something truly incongruous like "click send" when you thought you'd been talking about websites for a while. Give the other person as many opportunities to present you with redundant information as possible, so that you can gauge the consistency of their responses with what you thought you were explaining.

In my experience as a teacher, most people in most situations where they don't understand everything use the technique of ignoring the parts they don't understand and latching on to the words and phrases that they do understand. This is a good strategy in some situations, but it confuses a lot of explainers because they are more likely to resort to different techniques (e.g. stopping and asking for explanation every time they don't understand 100% or asking questions they think they know the answer to in order to verify comprehension). So you have to realize that you can repeatedly use a phrase that means absolutely nothing to someone and they may never explicitly tell you that they don't understand it, either because they're ignoring it (perhaps hoping subconsciously that context will make it clear soon) or because they think it means something else. So you have to give them lots of opportunities to make their understanding clear.

Of course, this doesn't even come close to addressing the issue of people being willfully difficult. One way this can happen is if they decide that the conversation you're having is an argument with two people trying to convince each other of something as opposed to the situation where you think they'd believe you as soon as they understood the entire situation. That can be a difficult one because there's some antagonism in the air, and an attempt to fix a misunderstanding can be misread as an accusation of stupidity. A diplomatic approach can be helpful here. I'll use phrases like "I think I may have misspoke", "That didn't come out the way I intended", or "I think I said something confusing" as opposed to "I think you misheard me", "I think you're confused about something", or "That's not how it works" where I at least theoretically place the burden of the confusion on my own shoulders rather than on theirs. If they get frustrated or angry, you may have to wait for a while before you can get in a sentence to point this out.

You may also have to deal with impatience as well. They may think they're being extremely clear and get very frustrated when _you_ don't understand them. (e.g. A: IE won't open. B: What exactly happens when you double-click the IE icon? A: I already told you! Nothing! It doesn't open! B: So the screen looks exactly the same as before you double-clicked the icon? A: What? No, a window pops up.) So you might have to either calm them down, perhaps by taking the burden of ignorance onto yourself, convincing them that you're just being extra careful, or finding ways to get information out of them without asking for it directly.

Of course these few things only touch the surface. You've asked an absolutely enormous question here, encompassing the entirety of education, training, and technical support. Experience helps a lot, but only if you're paying attention.
posted by ErWenn at 7:52 AM on November 28, 2009 [1 favorite]

rokusan, it's interesting that you mention "thingie". I do get pretty loose with my words when it's just techies around, but I've always tried to clean it up outside the server room because I thought it would be clearer. Maybe next time I'll try BrokenEnglish's drawing and just point to things. "This is you...and then they go through that server..."

A couple of you have sugested asking even more questions. This is what I do when I'm the one who can't keep up, but when the shoe's on the other foot I worry about sounding patronizing. How do you phrase the questions so it doesn't feel like Socrates interrogating a student?

Part of this, I think, is that people get sensitive about their ignorance. I don't think less of myself for not knowing how my newspaper gets published or not making small talk about cuneiform, but somehow people feel like it reflects badly on them not to know these obscure details of my job. How do I make it clear that, "Yes, you just said something totally incomprehensible, so now I have to ask a bunch of question, but that's okay. You're justifying my paycheck. On a good day, it's even kind of fun! Let's get through this and you can get back to refuting Kierkegaarde."
posted by d. z. wang at 1:43 PM on November 28, 2009

How do you phrase the questions so it doesn't feel like Socrates interrogating a student?

Make it about their needs, not your work, and act like you want their input.

"Okay, I can do that a few different ways. What are your main goals with this?"
"Yes, we can do that. But are you okay with these couple of downsides?"
"Hm. I can definitely see how that would help you. But you know, there might be an even better way to do that, can I ask you a few questions about how you intend to use this?"

In other words, follow this pattern:

(1) YES; (2) Hm, by the way; (3) What do YOU think/want?

Or go away and come back a few hours later with "I've been thinking about your problem, and I have a few different ideas on how I could do it. I'd like YOUR INPUT on..."

Then they'll be impressed you were thinking about helping them even when they were NOT in your face.
posted by rokusan at 8:06 PM on November 28, 2009 [2 favorites]

On preview, this got kinda long, so very short version: Good questions start by being open-ended (not yes/no), give the person a chance to clarify, and are delivered with a smile and open body language. Ask good questions, make the person a partner in getting their issue resolved, and you will be able to ask as many questions as you need to most of the time.

Tone of voice and facial expressions. Rokusan's nailed a lot of the basic phrasing and I really like his pattern. Particularly helpful in his answer: start with some variation of either 'yes, we can do that' or 'yes, I understand that that would be a problem' and then you can add 'I'll just need to ask a few questions to make sure we can fully..." A lot of it, though, is what I was taught was a 'service ethic'. That is, if you're clear that you want to help them and are just trying to understand, a lot can be forgiven. Also, it can be helpful to phrase it almost like a sentence with an upwards inclination at the end rather than a question.

Other people upthread have suggested phrases I use a lot, like..

"So you want/need/are having problems with...?"
"I want to make sure that I understand that so that I'm meeting all your needs/doing this in the most efficient manner possible/saving money/(whatever excuse you want to use, true or not).."

Or, a variation on the standard question that all reference librarians are taught to ask:

"Would you tell me more about what you need to know/have fixed about..."

Short version: Treat the person as a partner in getting their needs met and smile and you can probably ask all the questions you need to.

Looking upthread: Erwenn's point about making any confusion your fault is also helpful. Here a phrase I have also used is something like:

"I'm sorry, (Optional for particularly problem people: it's Monday/too early in the morning/been a long day and) I think I may have misunderstood what you need. Could you tell me more about..."

Oh, and last tip from Reference that really does work in almost every service profession: Your last question should be some variation on:

"Does that meet your needs? Is there anything else I can do for you?"
posted by eleanna at 9:41 AM on December 2, 2009