 |
Home > Detail: Did You Hear What I Said?
| A StickyMinds.com Original |
|  | |
Did You Hear What I Said?
By Karl E. Wiegers
   
Summary: Software projects are complex endeavors that rely on clear communication for success. If communication methods are mismatched or leave too many gaps, your project could suffer, and you could be highly frustrated. In this column, Karl Wiegers details potential problems to be mindful of, and strategies to use, when communicating about a project. | | |
|
|
 |
I once facilitated a project retrospective for an Internet development team that included several software developers and some visual-design and human-factors experts. One of the visual designers complained that she never knew the status of the software side of the project.
“What do you mean?” asked the lead software developer. “I sent you emails all the time with status updates.”
“Those emails didn’t do much for me,” replied the visual designer. “I figured you’d walk over and talk to me if anything important came up. I felt like you had excluded me from the loop.”
Obviously the software lead and the visual designer had very different communication styles and expectations. Problems arose because both parties communicated in the way that was most comfortable and natural for them, without regard to whether that met the needs of their counterpart. As a result, important information was not exchanged and feelings were hurt.
Mismatched Styles
Communication gaps often arise simply because people have different preferences for how they communicate and how they interact with others. For example, a talkative extravert who cheerfully broadcasts information to an introverted counterpart might wonder why his colleague just sits quietly without responding. “Is she bored, asleep, distracted, or mocking me?” the extravert might wonder.
In fact, the introvert might simply be absorbing the information and processing it before making a response. The extravert might well charge ahead with additional input, without giving the introvert time to collect her thoughts and formulate a reply. The introvert feels trampled and ignored, while the extravert feels like he’s talking to a wall.
Some people are oriented toward details, while others want only the big picture. It’s easy to overwhelm a manager with the rationale for decisions you’ve made, when all he really wants to know is the status of the project at this moment. When the manager waves off the detail and impatiently waits for you to get to the point, your reaction could be, “He hasn’t heard a word I’ve said” or “He must think I’m an idiot.” A request for testing status could elicit a response of “Lookin’ good, right on track” from someone who thinks in terms of generalities. But perhaps the inquirer really wanted to know exactly what percentage of the test case has been executed and what fraction passed.
Communication involves both sending and receiving, but too often we emphasize the transmission. Software projects create a variety of documents that bridge a communication gulf between one part of the team and others. Such documents include requirements specifications, project plans, quality assurance plans, and test procedures. Although the purpose of those documents is to convey information that lets other people do their jobs, we usually write them from the point of view of the author, not the document’s receiver. Consequently, the document’s receiver might say, “Once again, this thing is badly organized, lacks information I need, and includes a bunch of stuff I don’t care about.” Consider developing templates for such important “bridging documents” collaboratively, with both the producers and the consumers sitting down together to discuss the structure, content, depth, and style.
Close the Loop
Unless we understand our own communication style preferences and discuss communication expectations with our colleagues, we can expect many frustrating conversations. For example, when I’m having a one-on-one conversation about something important, I like to receive confirmation that I’ve been heard and understood. A former Significant Other and I once agreed that when she said “I hear you,” that meant that she understood what I said. She didn’t necessarily agree with me, but the message had (apparently!) been received. Until we agreed on this convention, I would often repeat myself in an attempt to generate some reaction other than her just looking at me, which only annoyed her.
To improve your communication effectiveness, be sensitive to the communication styles of the people with whom you interact. Discuss how much detail is appropriate in status reports or meeting summaries. Agree on which communications should be written, which are suitable for email, and which need to be handled face-to-face. Read the body language of people with whom you speak, to detect when someone is thinking (a furrowed brow or distant gaze) or getting ready to speak (an audible intake of breath).
Consider taking a listening skills class, which teaches ways to hear what people say more effectively and to provide feedback that indicates the message is coming through. If a discussion led to a decision or commitment, summarize the agreement to ensure that all participants share the same understanding. Sometimes a written summary of the key points reveals that not all participants really agreed on the discussion’s outcome. Recognize that communication style preferences reflect personality differences, and learn to communicate effectively with people whose natural style might be very different from yours. Remember that they’re also wondering why you’re talking to them in such a strange way.
About the Author
Karl Wiegers is Principal Consultant with Process Impact in Portland, Oregon. Karl is the author of Software Requirements, Creating a Software Engineering Culture, and the just-published Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002). You can reach Karl at http://www.processimpact.com.
Back to Top
StickyMinds.com Weekly Column From 12/3/01
|
