本文发表在 rolia.net 枫下论坛Recently, someone here asked how to answer this interview question: how do you explain technical ideas to a non-technical audience? My answer: avoid jargons, avoid abbreviations, emphasize key points, downplay details, sacrifice accuracy, use examples from the domain of your audience.
Last few days, I thought about the case some more, especially about "downplay details and sacrifice accuracy". I asked myself: why is this necessary and is it the right thing to do? The result of my thinking is a principle in communications which is universally applicable, beyond "explaining technical ideas to a non-technical audience".
The key here is the needs of the audience. Our goal is not to be accurate, or to be truthful, or to be bound by details. Rather, our goal is to satisfy the needs of the audience. Different audience may have different needs. A guy who's only mildly curious would be annoyed if we give him too much details. A guy who only needs enough information to make a decision wouldn't have patience to listen to our lecture. A guy who just needs a simple answer would be frustrated at our explanation and could reach a wrong answer on his own, ignoring our message.
If my neighbor the plumber asks me what a programmer does, I may say that it's just like him programming the VCR. If a banker asks me the same question, I might use the example of a bank machine. I could say that the simple act of withdrawing money from a bank machine requires a lot of work behind the scenes. All these work have to be programmed by a programmer. If someone on Rolia asks me the same question, I'd ask her to describe the steps she has to take in the morning from getting up to going to work. Then I'd tell her that she just did what a programmer would do at work every day.
My neighbor the plumber probably asked me the question out of curiosity, so it's a bad idea to burden him with a complicated answer. The banker may be trying to understand his IT staff, so a detailed somewhat accurate answer makes sense. The Rolian may want to become a programmer, a hands-on session gets the point across.
My first job was working as a programmer for a small company in Toronto. The big boss would often drop in to ask me how it's going. Each time, I would describe in detail what I'd been doing and the problems I had. If I was stuck, I'd explain to him why I was stuck. Sometimes I would talk to him about my ideas in detail: why I don't like some guy's code; how I'd like to redesign the user interface; etc. My boss would often cut me off and ran out. Most of the time, he didn't seem to be listening. And he'd turn cold when I talked about problems. Slowly I realized that he's not interested in what I was doing at all. He just wants to know everything is OK. From then on, every time he dropped in, I'd say everything is great. I'd tell him the good things I've done if he's still listening. No details. No problems unless I solved them already. I stopped talking to him about my ideas - I'd just implement them. Both of us were happier: I was no longer disappointed at his inattention and he was no longer bored at my details or annoyed at my problems.
A while ago, someone on Rolia asked a question regarding TN visa. Most Canadian programmers work in the United States under a TN visa. The requirements are simple: a job offer as a "Systems Analyst"; certain level of education; relevant experience. I've never heard of anyone refused a visa and there's zero implication for the employer. What do you say when the employer asks if you're legally qualified to work in the US or if you require sponsorship? I was asked the question at least once. I told the guy, without hesitation, that I'm legally qualified and I don't need sponsorship. I never even bothered to check if TN visa requires sponsorship in the legal sense. To me, the need of the employer is not to learn about TN visa. Rather, he just wants to know if I break the law by working for him and if he is implicated in any way by hiring me. The answer is no to both. My reply is totally appropriate in satisfying this need, even though it may not be accurate. The alternative is to teach him about TN. And most likely, he wouldn't be interested in learning. And he could decide in a matter of seconds that hiring me is troublesome and he'd want nothing to do with it.
Once a manager in a consulting company asked two programmers why they'd have a meeting again with clients since they just met them a couple of days ago. One programmer said because his stuff doesn't work in client's environment but works on his machine. The manager wasn't convinced. Then the programmer said he's using JBoss but the client uses WebLogic. The manager was still not convinced. Then the second programmer said that they had many questions in the first meeting but the guy from the client wasn't able to answer them clearly. So this time the client is sending a more senior guy. Now the manager was convinced. The need of the manager is to ensure that his programmers appear competent to clients. Having two meetings in three days seems fishy. The first programmer's answer may have reinforced his suspicion. The second programmer reassured him that the problem was on the client's side.
An effective communicator identifies the need of his audience and tailors his message to that needs.
--------- to be continued
(see link for previous articles)更多精彩文章及讨论，请光临枫下论坛 rolia.net
Last few days, I thought about the case some more, especially about "downplay details and sacrifice accuracy". I asked myself: why is this necessary and is it the right thing to do? The result of my thinking is a principle in communications which is universally applicable, beyond "explaining technical ideas to a non-technical audience".
The key here is the needs of the audience. Our goal is not to be accurate, or to be truthful, or to be bound by details. Rather, our goal is to satisfy the needs of the audience. Different audience may have different needs. A guy who's only mildly curious would be annoyed if we give him too much details. A guy who only needs enough information to make a decision wouldn't have patience to listen to our lecture. A guy who just needs a simple answer would be frustrated at our explanation and could reach a wrong answer on his own, ignoring our message.
If my neighbor the plumber asks me what a programmer does, I may say that it's just like him programming the VCR. If a banker asks me the same question, I might use the example of a bank machine. I could say that the simple act of withdrawing money from a bank machine requires a lot of work behind the scenes. All these work have to be programmed by a programmer. If someone on Rolia asks me the same question, I'd ask her to describe the steps she has to take in the morning from getting up to going to work. Then I'd tell her that she just did what a programmer would do at work every day.
My neighbor the plumber probably asked me the question out of curiosity, so it's a bad idea to burden him with a complicated answer. The banker may be trying to understand his IT staff, so a detailed somewhat accurate answer makes sense. The Rolian may want to become a programmer, a hands-on session gets the point across.
My first job was working as a programmer for a small company in Toronto. The big boss would often drop in to ask me how it's going. Each time, I would describe in detail what I'd been doing and the problems I had. If I was stuck, I'd explain to him why I was stuck. Sometimes I would talk to him about my ideas in detail: why I don't like some guy's code; how I'd like to redesign the user interface; etc. My boss would often cut me off and ran out. Most of the time, he didn't seem to be listening. And he'd turn cold when I talked about problems. Slowly I realized that he's not interested in what I was doing at all. He just wants to know everything is OK. From then on, every time he dropped in, I'd say everything is great. I'd tell him the good things I've done if he's still listening. No details. No problems unless I solved them already. I stopped talking to him about my ideas - I'd just implement them. Both of us were happier: I was no longer disappointed at his inattention and he was no longer bored at my details or annoyed at my problems.
A while ago, someone on Rolia asked a question regarding TN visa. Most Canadian programmers work in the United States under a TN visa. The requirements are simple: a job offer as a "Systems Analyst"; certain level of education; relevant experience. I've never heard of anyone refused a visa and there's zero implication for the employer. What do you say when the employer asks if you're legally qualified to work in the US or if you require sponsorship? I was asked the question at least once. I told the guy, without hesitation, that I'm legally qualified and I don't need sponsorship. I never even bothered to check if TN visa requires sponsorship in the legal sense. To me, the need of the employer is not to learn about TN visa. Rather, he just wants to know if I break the law by working for him and if he is implicated in any way by hiring me. The answer is no to both. My reply is totally appropriate in satisfying this need, even though it may not be accurate. The alternative is to teach him about TN. And most likely, he wouldn't be interested in learning. And he could decide in a matter of seconds that hiring me is troublesome and he'd want nothing to do with it.
Once a manager in a consulting company asked two programmers why they'd have a meeting again with clients since they just met them a couple of days ago. One programmer said because his stuff doesn't work in client's environment but works on his machine. The manager wasn't convinced. Then the programmer said he's using JBoss but the client uses WebLogic. The manager was still not convinced. Then the second programmer said that they had many questions in the first meeting but the guy from the client wasn't able to answer them clearly. So this time the client is sending a more senior guy. Now the manager was convinced. The need of the manager is to ensure that his programmers appear competent to clients. Having two meetings in three days seems fishy. The first programmer's answer may have reinforced his suspicion. The second programmer reassured him that the problem was on the client's side.
An effective communicator identifies the need of his audience and tailors his message to that needs.
--------- to be continued
(see link for previous articles)更多精彩文章及讨论，请光临枫下论坛 rolia.net