SQL Cruise 2011 - Communications Part 2

13 July 2011

...this is part 2 of a blog post series on communications, based on Buck Woody's (b / tSQL Cruise 2011 session.

When you communicate, Perception is Reality.

Everything is in the eye of the beholder

That is a hard idea to accept. As a developer and data professional, I have faith in data and numbers. However, I have (grudgingly) accepted that with communications, perception is critically important. The reason is people understand and judge information based on what they can understand, and what they believe. A story is just as important as data. Data that is hidden, or that is hard to understand, is given less importance. Therefore people judge based on appearances: a person is judged based on the way they dress, their posture, personal cleanliness, speaking style, whether they mumble, etc.

Buck’s suggestion is elegant: know my goals, and do what is necessary to get to them. When I communicate I should use whatever tools I have to get my message across. Humor. Intuitive language. Clear analogies. Animated diagrams. Wear a suit. Pranks. Whatever is effective. If I want my message to get across, I should first figure out what the point is that I’m trying to make. I should work backwards from there. This becomes a cycle:  pick my goals, change my communications to meet them, and repeat.

My speech should be tailored to who I’m speaking to. This is important, because people have very different ways of absorbing information. At one extreme is someone who is dispassionate; they prefer to discuss an idea neutrally, as if discussing a theoretical concept. At the other end are people who won’t respect me unless I step up and forcefully present my idea; respect is given to people who interact personally.

In either case, the lesson for a presenter is: adapt yourself to your audience. Don’t let you become a barrier to your own ideas. The idea is paramount; it is the point. If the idea is attacked, don’t respond personally. If you respond personally, you are giving the other person control of the conversation; they now know how to control your reactions and manipulate you. One tactic during debates is to get your opponent upset. Upset people don’t think clearly.

Sound stressful? It is. Most engineers I work with are far more comfortable making stuff run than communicating how, why, and what they are doing. That difference is stressful. Stress is the difference between perception and reality.

Top 3 Lessons

  1. Perception Is Reality
  2. Change your communications to suit your audience
  3. Don't let yourself get in the way of your ideas

SQL Cruise 2011 - Communications Part 1

07 July 2011

[![Sleeping child

"Not everyone who understands something can explain it" - Buck Woody

Last time I wrote about why I went on SQL Cruise 2011, and how I did it. Now I'll be going over some of the training highlights, starting with Buck Woody's (b / t) session on Communications.

Why is Communication Important?

"Your UI is how you communicate with others"- Buck Woody

Communication is a top 10 required skill in most careers, including IT and software engineering. That makes sense to me. I have a harder time working with engineers, customers, and managers who don’t communicate well, or at all. Working with them is far more difficult than going to someone who can tell me the information I need.

The corollary to this idea is: people who have a hard time communicating also have a hard time understanding. That makes sense as well; I often ask clarifying questions to make sure I understand someone’s intent and message. Communication skills are just as important when learning as they are when teaching.

Your Verbal Style

Buck's first key lesson: each of us has a style. That struck a chord in me. Our style is many things. It is our cadence, our word choice, the common phrases we use, and when we use humor. His argument is that we should each seek to refine our personal style, instead of adopting somebody else’s. We should take the best parts of our own style and tweak them to be more effective.

Another key lesson? We already communicate, every day. It is unavoidable. So instead of learning to communicate, the lesson is to improve what you already do.

I don’t know what my personal style is, exactly. So I have been asking around. I found out that when I speak, I have a distinctive style. I am sometimes wordy, and I add nuance to avoid being too forceful. I also like to make my ideas a little abstract, because I want them to be broadly useful. I like my ideas to be seen like software patterns: useful in lots of situations.

If you don’t know your own personal style, ask. Your friends and colleagues know it very well.

Lastly, and most importantly, people have a natural preference to stories. A dry recitation of facts will be less well understood than if it feels like part of a story, or narrative.

The #1 Skill: Learn to tell stories.