In a previous meditation, I talked about communication. The way things are going at work, it seems to be my running theme for the last few weeks, so I'm planning to do two things: write down what I've figured out about communication, and solicit any tidbits from others that I can pass on to my coworkers (and even integrate into my own communication style).

I had previously said that "Even if you are the hardest person in the company to talk to, if you consistantly get what needs to be done faster, cheaper, and more reliably than anyone else, you'll be invaluable." I'm really starting to see the error in that statement, as husker pointed out.

While there is a certain amount of eccentricity permitted to higher-performing employees, the bars are set much more extreme than I may have implied at the time: the bar for "high performing" is quite high to be permitted minor eccentricities.

Tanktalus' Rules for Effective Communication

Communicate in the language of the listener

You may be a very technical person. However, the listener may not. Do not describe your problems employing any technical jargon that the listener does not know or understand.

If the listener is amenable, you can educate them on some of the terms, but this isn't a university class they signed up for - they have an actual job to perform, and learning a new discipline is unlikely to be it. So keep it brief, and keep it straight-forward. Don't leave them with enough information to be dangerous, though1.

Understand the listener's motivation

This is part of the above, but is important enough to get its own point. You need to understand where the listener is approaching the problem from, and why they want it solved. Yes, at the core, many people are doing what they do just because they're getting paid. But you are unlikely to be able to influence their pay directly, so the next best thing is to help them look like they're performing well.

What is it that they want or need?

Give it to them.

What? Are you daft, Tanktalus? No, actually, I'm not. (Well, I don't think so anyway - my wife isn't so sure.) In a competition, there are winners and losers - for someone to win, others must lose. What you do in your day job, or even at home with your partner, is not a competition: it's a team sport. The way for everyone to win is really to try to give the other as much of what they want as you can without sacraficing what's important to you. Of course, to do that, you need to know what the other person or people want.

By ensuring their needs are met, they will be less likely to resist you getting what you want or need. And, funny enough, this works at home, too ;-)

Be transparent

There's an old saying - those who have nothing to hide, hide nothing. It works at work, too. Do not lie or mislead those you work with. Make it easy for coworkers to understand your perspective and motivation. That makes it easier for them to communicate with you. And, especially, do not lie or mislead your reporting chain(s). Not only is this an "actionable" offense (translation: you can be fired), ... well, isn't that enough reason?

You want your reporting chain on your side at all times in case things get rough. By keeping them informed and aware of your successes and roadblocks, you can be sure to get timely feedback if it is your performance faltering, or timely help to remove those roadblocks that you don' t have the influence to remove. Of course, this helps your performance, which is usually what you're getting paid to do, so it's like a win-win-win situation here.

1There are three types of people in any given area of expertise: those who know what they're doing and know they do; those who don't know what they're doing but know they don't; and those who don't know what they're doing yet think they do. It's the last group that gives everyone else problems. It's also the last group that most people fall into most of the time.

All that said, there are specific exceptions to every rule. There are definitely some coworkers where the best way to communicate with them is, when they ask a question, to laugh maniacally and walk away, shaking one's head. ;-) But I'm more interested in the generalities of good communication from a technical person to someone who may or may not be technical, and, if they are technical, may not be an expert in the same area.

Replies are listed 'Best First'.
Re: Programming skill #1: Communication
by Nkuvu (Priest) on May 26, 2005 at 17:11 UTC
    You may be a very technical person. However, the listener may not. Do not describe your problems employing any technical jargon that the listener does not know or understand.
    Note that this may involve (gasp!) asking them if they're still following the discussion. Drives me bonkers when I'm talking to someone and they start out making sense, then continue on into Never Never Land of Technical Issues. I don't mind technical issues at all but I don't know everything. Just because I understand object-oriented design doesn't mean I know how a TTP bus works. (No, no relation between the two AFAIK, but this was a recent issue -- the person giving me info was surprised that I knew one but not the other)

    And if you're communicating using the written word, double check things before you send it off. Just like Previewing on PM.

      Communication is a two way road, if you are not following, why wait for the other person to ask you if you still do? Tell them! Of course this takes some courage, but to me this sounds better than to have to keep asking. If I don't follow, I ask and I kinda expect the same from the other person. Of course paying attention to the face expression of the other person helps preventing confusion as well ;-)

      Jenda
      XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

        Assuming, of course, that you can get a word in edgewise. I have no problems admitting that I am not following. But some of the people that I speak to have difficulty stopping themselves from talking. Which is the basis for the note in the first place...
Re: Programming skill #1: Communication
by chas (Priest) on May 26, 2005 at 17:53 UTC
    "Communicate in the language of the listener"
    One thing I've discovered (after over 30 years of teaching) is that the process of understanding is extremely mysterious. You can explain something in a perfectly grammatical and unambiguous way to someone and they'll look at you with glazed eyes understanding nothing; on the other hand you may tell them some kind of heuristic which isn't really the whole truth at all, and suddenly they'll "get it" more or less completely. The moment of understanding seems to be some sort of chaotic event - like a phase transition, maybe. But it's certain that different people understand best by precise explanation or maybe pictures or perhaps examples, etc. I think that a major communication skill involves understand that and taking advantage of it. (Of course, if you are lecturing to a group, you have to compromise this somewhat, but it still applies.)
    Very interesting post!
    chas
Re: Programming skill #1: Communication
by husker (Chaplain) on May 26, 2005 at 19:53 UTC
    Those are good rules. I think you left off a very important one, though: "Listen first, then speak". I hardly ever learn anything when I'm the one talking. Listening skills are at least as important as speaking skills.

    Another rule is "Your actions and your words should agree". Perhaps this is similar to the idea of transparency, but you absolutely must DO what you SAY. It builds trust, and allows other to communicate transparently with you.

      Listen first, then speak

      Very much so, but don't stop listening just because you've started speaking.

      The OP says "Communicate in the language of the listener", and I think few people understand how insanely difficult that actually is to do.

      The way most people instinctively listen is to translate things into their own terms as they hear it ("the compilation phase"), then throw away the source. What you need to do is build a mental model as you go of how the other party sees the world, trying not to get too sidetracked by any deficiencies you spot, and then using that both to determine the answer to give, and to determine how to phrase it.

      One of the most useful communication skills is the ability to give the same answer in different words - and that doesn't just mean referring to "thingies" instead of "objects", but rather more like writing a lisp program to solve the same problem as an existing one in C: going back to the beginning and coming at the whole thing from a different angle.

      For advanced students, the trick is finding the right angle simply by correctly discerning from the question itself all the clues necessary.

      For anyone wanting to become a better communicator, I highly recommend giving support for some application that can be used by the techophile and -phobe alike, such as an editor - to practise discerning from the nature of the question, and the tone, and the vocabulary, and any other clue that presents itself, which of the myriad possible answers is appropriate for this individual.

      Hugo

Re: Programming skill #1: Communication
by crashtest (Curate) on May 26, 2005 at 20:51 UTC
    Understand the listener's motivation
    I think this one's especially important. Whenever I get asked a question by a functional person that doesn't make sense (or I can't fathom why they'd want the answer to the question), the first words out of my mouth are: "What is it you are trying to do?".

    I've gotten a lot of mileage out of that question. More often than not, it reveals an error in the questioner's previous understanding of the topic at hand. This way, they then learn a) that they've misunderstood something, b) what question they should be asking and c) the answer to the right question.

    The best communication in the world won't help your group's performance if you're talking about the wrong things.
Re: Programming skill #1: Communication
by 5mi11er (Deacon) on May 26, 2005 at 18:50 UTC
    Yes, this is another post hammering home the Communicate in the language of the listener point. The best description I've seen of this point was to "build a bridge from where they are, to where you need them to be".

    I have a cow-orker that likes to try to build this bridge using a shot-gun type brain dump, and it is usually impossible to figure out what his point is until he's completely finished. This isn't effective. The message needs to start at your audience and methodically trace back to your point.

    -Scott

Re: Programming skill #1: Communication
by tilly (Archbishop) on May 27, 2005 at 21:32 UTC
    I've noticed that, Programmers tend to be both precise and ineffective in their communication.

    Being unambiguous and correct in what you say does not generally mean that you've actually communicated. In fact if your speech is overly precise then you probably have not because the getting your message depends on understanding every last nuance of what you say, and the listener probably missed or misunderstood a key nuance.

    Effective communication is highly redundant, and sets itself up so that the listener pretty much expects to hear what they are going to hear. It helps a lot if the speaker and listener are both working from a common frame of reference. (These rules of thumb accurately suggest that effective communication is not always possible...)

"The Incompleteness of Communications"
by eieio (Pilgrim) on May 26, 2005 at 20:58 UTC
    Agile Software Development by Alistair Cockburn (ISBN 0201699699), does an excellent job describing the importance and challenges of effective communication. He claims the key to mastering agile software development is to manage "the incompleteness of communications." This book reinforces a number of the points made here besides being a very insightful book about software development.