Seek first to understand, then to be understood

Seek first to understand, then to be understood

  • Comments 1

One of the most important (and most difficult) lessons for a technical professional to learn is to not jump to the solution. Perhaps you’ve done this, or had it happen to you. As the person you’re “listening” to is speaking, your mind is performing a B-Tree lookup on possible solutions, and when the final node of the B-Tree in your mind is reached, you blurt out the “only” solution there is to the problem, whether they are done or not.

There are two issues here – both of them fatal if you don’t factor them in. First, your B-Tree may not be complete, or correct. That of course leads to an incorrect response, which blows your credibility. People will not trust you if this happens often.

The second danger is that the person may modify their entire problem with a single word or phrase. I once had a client explain a detailed problem to me – and I just KNEW the answer. Then they said at the end “well, that’s what it used to do, anyway. Now it doesn’t do that anymore.” Which of course negated my entire solution – happily I had kept my mouth shut until they finished.

So practice listening, rather than waiting for your turn to speak. Let the person finish, let them get the concept out, give them your full attention. They’ll appreciate the courtesy, you’ll look more intelligent, and you both may find the right answer to the problem.

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • Great advice, Buck (as usual).

    In line with that, IMO, the very next step after listening to what the person said is to ask "Why?"

    In my experience, more often than not, the person with the problem has also already done the "B-tree" search themselves in an attempt to solve the problem.  However, they have probably also "invented" a few routes and leaves to their tree consisting of "facts" they believe to be true about what technology (or "other people") are capable of providing, and have coloured their description of the problem to match the route they took through their B-tree.

    Asking "Why?" (at least five times, I'm told) can get you past some of the assumptions that have changed the "problem" from the real root problem.

    So yes - listen!  But then ask why, and listen again!

Page 1 of 1 (1 items)