Thursday, January 14, 2010

Three basic communication tips

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/three_basic_communication_tips.htm]

I am certainly no communication or "people" expert, which is probably why wiser people in my life have explicitly offered me three good rules for communicating with others. I think these rules apply in the corporate world as well, so it makes a good blog post (because I can't just blog about normal life-issues unless I can somehow apply it to software engineering).

Connect the dots - In software programming, we must explicitly spell every step. Sure you can refactor and abstract things out, or use third-party software to spare you from writing it - but somehow, every step must be flushed out in detail. This is great for a robust program, but it will drive real people insane (i.e. managers, business analysts, customers, and executives who write your paycheck). They'll just think you're being clueless, are inexperienced, or a smart aleck. When dealing with actual people, we need to be able to use our background knowledge of the situation to connect the dots.

Don't wait to be asked - It takes effort to ask for something, and people don't like exerting effort, so anytime you can "just know" and do the right thing (perhaps because you know the bigger picture of what they're trying to do), people are going to appreciate it.

  • For example, say you see a simple bug in the code. It's a safe change and the release isn't for a while. The savvy developer doesn't need to ask their manager "can I fix this bug" - they just do it (and maybe submit a ticket if their company's process requires that). Often just making the fix can be quicker than asking. (Of course common sense applies, don't go "fixing" mission-critical production code that's out of your scope).
  • It seems like only junior resources ask "What can I do to help?"- the senior ones already know.

Of course, it's reasonable to pro-actively notify a manager "I see A, B, and C. I know you're busy, so I'll assume I should start working on 'B' first because of reasons XYZ. Just let me know if you'd like to switch tasks". This lets your manager reply with a 1 word email like "great", and managers like being able to delegate entire tasks with 1-word emails.

"Connecting the dots" and "Don't wait to be asked" are related. Think of this as not needing to be micromanaged.

Translate what people say. There is a world of difference between someone's words and what they actually mean. Whether they've made a simple typo, using poor word choice, or they're struggling to articulate something - it's a big personal win if you can "see the forest through the trees" and know what they mean. You can do this by leveraging context, know where they're trying to go, and having familiarity with what it takes to get there.

  • Example: Missing words - A non-technical manager may say "we need to store this dropdown control in the database". They probably mean "..store the value of this dropdown control..."
  • Example: Wrong words - A non-technical manager says "We need a bigger machine". They probably mean "we need a better-performing machine"

Summary

You might say "but this isn't fair - I was doing my job to the 'T', I was technically correct" Ah, but life is not fair. You can be right, or you can be happy. And (as I find out the hard way) if you want to be happy with other people, you're eventually need to master many things, including these three.

 

No comments:

Post a Comment