Technical Communication focuses on developing and delivering clear, concise messages. These skills become second nature for many of us, but sometimes these skills lead to actions that cause us to be pigeon-holed and hinder our ability to expand our role and future.
A common complaint I hear from technical communicators is the lack of respect they receive from other teams and professions. As technical communicators, we need to work to improve our image and reputation. We have many valuable skills to contribute that can improve the bottom line for our products and services. Unfortunately, some of us get stuck on the words during a discussion rather than focusing on the overall message and goal.
For example, a few weeks ago I monitored a discussion on a listserv about estimating projects. Several listserv members shared their ideas and metrics that worked well for them. Some of these ideas involved a unit of work called a page. A few other listserv members objected to that term because they deliver only online content, so the word page didn’t seem to apply to them. In this case, rather than listening to the overall method and then adjusting it for their specific processes and deliverables, they threw out the ideas as invalid. This lost opportunity illustrated to me why we are sometimes viewed with a lack of respect. We were stuck on a word.
I have also viewed our tendency to focus on the words during discussions with subject matter experts (SMEs). We can get stuck on the terms that SMEs use rather than focusing on the big picture and learning the overall concepts. In other cases, some of us focus on the terms, interrupt and correct the SMEs, or even ask them to be consistent during these discussions. The first rule of technical communication is to know your audience and focus on what’s important to that audience. Using consistent terminology and phrasing is important to us and our deliverables, but rarely is it important to our SMEs, especially during internal discussions.
We have great skills to help our organizations and products by creating, shaping, and delivering their messages. We should demonstrate these abilities and focus on meeting the business requirements and contributing to the success of our projects. With this expanded vision and focus, you may be surprised by the opportunities that come your way. I have seen information development teams become integral parts of their organizations in which they are viewed as equal partners with development and quality assurance teams. We hold our own future in our hands. The actions of each of us affect the reputations of technical communicators across the industry and around the world.
I couldn’t agree more with this, Paul. In my previous experience, I have found that by taking a step back and really just listening to what the developer was trying to tell me, versus editing him in my mind (or aloud as some of my collegues might do!), I not only hit the nail on the head later with the content I was developing, but I also earned the developer’s respect. He/she remembered my name the next time they were working on something that needed documentation, or thought to include me in valuable planning sessions that helped me understand the product even more. It was a win-win for me!
We can dot our “i’s” and cross our “t’s” back at our desks to our heart’s content, but let’s try to get to the core of what we are–good communicators. Sometimes to do what we do best, that means holding our tongue and just listening.
I hear you, Paul.
For the past several months, I have been consciously trying to (and largely succeeding) in listening to what the dev-team was trying to say instead of only focussing on their words. Whenever they used a word I thought I could misinterpret, I asked them. (“You said the system is very robust. Do you mean to say it can export the data from any DTD or any schema and reformat the text?”) They (the dev-team) usually took that as a sign of profound interest on my part – and explained things a bit more 🙂
And, I too have noticed the tendency among writers to focus on words rather than meaning. A few weeks back, during a session on developing quality documents, the presenter said something to the effect that things should be consistent, showed two slides – a Before and an After – and pointed out that the Before slide had one list with all links and another where nothing was linked, and the After had al bullets in both lists linked. The audience leapt at the presenter – saying “Putting inline links in documents is not good practice at all!” The people who argued their heads off during the session were the writers who had, evidently, focussed on the word “link”. The point they lost was – the presenter was _not_ talking about links but about consistency. The After slide could have well been two lists with everything _un_linked.
At the heart of _any_ communication is a willingness to listen. Words, IMHO, are merely tools to communicate, not the communication per se.