Archive for the ‘Software: Building it’ Category

Effective Communication for Engineers

Thursday, July 24th, 2008

[I originally posted this internally at Microsoft, but there was so much positive response that I've decided to also make it available externally.  I hope you find it similarly helpful.]

It’s not possible to lay out all the elements of great communication in one article — the topic’s too rich and I am no expert.  But poor communication has been such a blocker to the careers of many engineers I’ve managed and mentored that I’d like to try to outline some of the tips I give.  Great communication is something that I continue to strive for and struggle with, so please take these suggestions merely as tips from one traveler to another on our collective journey towards awesome communication.

For this article, I’ll focus on interactive forms of communication like meetings, conversations, and emails.  I won’t focus on formal, one-way forms of communication like presentations (or this blog!), which require special considerations.

General Tips

Successful communication requires that the other person internalize what you meant to share.  Too many people assume that communication happens as long as they use accurate words.  This is what leads to conversations where one side keeps saying the same thing.

Joe: “Why did you change this code?”
Timmy:  “Sammy was OOF yesterday.”
Joe:  “I know, but why did you modify this code?”
Timmy:  “I said Sammy was out.”
Joe:  “What does Sammy being out have to do with you changing the code?”
Timmy:  “Sammy’s auto-checkin script broke the build while he was out, so he didn’t fix the build break.  I had to change the code to fix the break.”

Communication hasn’t happened unless the other person has internalized what you meant to convey.  What actually counts as communication is the cumulative effect of your words, tone, and body-language on the other person’s behavior.  The literal, factual correctness of the words you speak are only part of the equation.  Most Americans understand this in the use of sarcasm:  “I just love it when the boss makes us stay on weekends while he parties in Vegas,” actually means you hate it.  (Incidentally, many cultures do not employ sarcasm, thereby underlining this point’s importance.)

I have little sympathy for people who exclusively blame the listener for failure in communication (“I’ve sent Joey at least 5 emails outlining how to fix the build.  He just doesn’t learn!”).  At least some of the fault for each failure in communication must by placed on the speaker/writer.  You’re effective once the cumulative effect of your words, tone, and body-language affect the other person’s behavior the way you intended.

Listening is (at least) half of effective communication.  Shouting matches happen when neither side understands this.  What does the other person want?  What’s important to them?  What is the other person trying to communicate back?  Why does the other person seem not to understand my point?  How can I say it in a way that they’ll understand?  Great communicators have a way of jumping quickly to the heart of the matter.  You may start by discussing something trivial but they quickly sense and raise underlying issues.  They understand you.  You feel a strong connection with them.  When you disagree with them, you continue to respect their point of view because you understand why they feel differently.  Part of what makes these communicators effective is that they listen.

I’m told that good basketball players don’t focus on their opponents’ upper body when guarding them — they watch their opponents’ feet.  Although it’s easy to feign intentions with the upper body, the feet continue to point the direction that the opponent will go.  So great players aren’t distracted by a bunch of upper-body misdirection.  They know where to look.

Great listening is similar.  The literal words that the other person uses are only part of the communication.  You need to watch the body language and listen to the tone.  You need to understand the person’s past experiences and their goals.  All of these go towards a more complete, accurate model of the other person, which then refines how you communicate with them.

Consider the audience.  We’ve all been in meetings where some developer loses the entire audience by using obscure terms and going into too much detail.  The best communicators understand why their audience wants to listen at all — why does the audience care? — and then targets what they say to address their audience’s interests and goals.  They build interest in what they’re about to say.  They don’t spend energy on what ultimately won’t be effectively heard.  They use words that have the right meanings to their audience.

Words matter.  Engineers often err in opposite directions in the choice of words.  Some engineers confuse precision with effectiveness when communicating.  They assume that the listener will receive their message effectively because the words they choose are literally correct and precise.  Other engineers hold the diametrically opposing view.  To them, the words they use don’t change the nature of the truth they’re describing.  It makes no difference to them whether a team is called the “Engineering Process Committee” or the “Engineering Best Practices Community.”

Words matter greatly in that each word causes a different response in a particular listener.  It’s counterproductive to use precise engineering terms with someone who doesn’t understand them.  But when speaking with someone who does understand those terms, it becomes critical to use them.  With such a person, it’d actually cause confusion not to use them.  So to get your point across, you must understand your listener’s model of what specific words mean and conform your communication to their words, not yours.  This is why a pedant’s frustration with “incorrect” word usage suggests a fundamental misunderstanding of what communication is all about.

Tips for Introverts (and their managers)

Considering the bulk of the engineering community is introverted, I’ve included a few communication tips that have been helpful to introverts like me.

Communication needs to be proactive (timely).  Not speaking is communicating. There’s a reason that the smug response, “Well, you never asked!” always engenders frustration.  Silence is communication, every bit as much as shouting.  When a report of mine doesn’t mention a specific feature, I assume that it’s going well.  It’s painful when the burden of successful collaboration relies entirely on your knowing which questions to ask.  It’s important to raise issues as they arise, to speak when necessary even if it’s uncomfortable.

On that note, fall back on the medium that’s easiest for you if needed.  Many people are nervous about speaking in public.  Consider sending your feedback prior to the meeting to the organizer, or noting your feedback using IE’s Discussion feature or Word’s comment bubbles.  Follow up face-to-face with the organizer afterwards.  Contribute actively to email discussions.  Just remember that these are fallbacks.  There will be occasions, e.g. time-critical meetings, where speaking up in a group in real time is essential.

Misunderstandings tend to fester and spiral.  Speaking up at the right times, when a more timid person might choose to remain silent, goes a long way towards reducing misunderstandings.  Almost every Jane Austen novel relies on its main characters not speaking when they should.  It’s a sure way to cause drama.

Address difficult issues openly.  I used to avoid difficult conversations.  Just the anticipation alone would keep me up at nights.  I’ve found over time that conversations are rarely as difficult as we might think, especially when approached openly.  Usually, the more difficult you think a conversation will be, the more tense and awkward it actually ends up being.  Your state of mind makes a huge difference.  Most people are quite approachable, even on difficult topics, as long as they see that you genuinely care about them.  By continually forcing myself to proactively address difficult issues openly, I’ve become far less anxious and far more confident when approaching tough conversations.

A note to managers:  leave “space” for your introverted employees.  Pause a bit longer before moving on to the next topic.  Actively solicit their point of view in 1-on-1′s.  Avoid forcibly “calling on them” in team meetings in order to “motivate participation.”  Provide alternative means to register their views (e.g. email, written comments, post-meeting 1-on-1′s).  It’s not helpful to only set a commitment that says, “Participate more actively in meetings.”  Introverts need to be coached with examples and practical tips.  Fundamental changes like this will take years of practice.  The goal shouldn’t be to change an introvert into an extrovert.  Instead, it’s to make both introverts and extroverts better communicators.

[This post is dedicated to Alec Ramsay, who, amongst many other things, taught me that Words Matter.  I first learned by his example the vast difference between speaking and communicating.]

NextStep Is Born

Tuesday, May 20th, 2008

I’ve started a Microsoft-internal blog called NextStep to augment the content on this blog.  NextStep will focus on engineering, teams, and careers at Microsoft, and will contain the types of company-specific details that aren’t relevant or available to the general public.

In cases where topics are interesting to both audiences, I will post the public version here and the internal version at NextStep.

NextStep will only cover topics related to software engineering, teams, and careers at Microsoft, so you won’t be able to read about, say, body heat there.

You’ve Got Three Hours

Tuesday, May 20th, 2008

Developers often complain that projects slip because managers flat-out override schedules by fiat, the sort of thing that happens on Star Trek all the time:

“Captain, I’ll need six hours to fix the warp drive!”
“You’ve got three.”

I’ve seen breakdown in Management’s interaction with the people producing the estimates for a variety of reasons.  But having been on both sides at Microsoft, it seems to me that root causes for the breakdown are often more subtle than at first appears;  more often than not, the breakdown is with both parties.

There is, of course, the manager who insists against all reality on his/her own ship date.  I seem to remember reading a blog about a Vista VP who had this problem, but I’ll need to dig up that blog entry (wait:  here it is).  I’m told the blogger almost got fired for that posting.  I hope he’s ok.

But I also often find that the developer/project-manager is simply putting too much schedule blame on the manager.  The core of the issue is often credibility:  is the presenter of the schedule credible?  Is there reason to believe the schedule?

Good points were already made below about practical things one can do to improve basal credibility, like documenting assumptions, going deep on unknowns, gathering supporting data, etc.  Those are helpful.

But in times when I, as the manager, have doubted schedules, it hasn’t been about this sort of credibility.  It’s been about other factors:

· How experienced is the developer presenting the schedule?
· How has he/she delivered in the past?
· How transparent is he/she?  How skeptical should I be?

You build credibility by demonstrating a series of repeated successes despite adversity.  You build credibility by being consistently right in your past judgments.  No college-hire is going to have this sort of credibility, at least in the beginning of his/her career.  You can give them the tactical tools and training, but they also need to give themselves time to hone their track records and reputations.

I once got a water heater moved by a plumber.  He estimated two days.  On the fourth day, when he finally finished, I asked him why the actual time was double the estimate.  He answered, full of conviction and without skipping a beat, “This happens every time.”

There are leads I’ve managed in the past who would make similar proclamations without even realizing it.  “I don’t feel comfortable committing to this schedule – in the past three sprints, we’ve always slipped a week beyond what we expected!”  There are other developers who I’d trust with a schedule without even needing to review it.

I think what often gets perceived as “my manager overrode my schedule” is actually the more subtle, “I’m not credible to my manager.”  As I often urge people, first look within.