I used to say, as a joke, that the difference between Technical Communication and Communication, was that in Technical Communication you have to tell the truth. It was of course an exaggeration for comical effect. But was it though? The more I thought about it, the more it made sense.
I'm not saying that you need to lie when you communicate, what I mean is that the notion of being accurate is a defining trait in Technical Communication, whereas it is a circumstantial characteristic in Communication. In fact, by that characteristic alone, you can tell one from the other. Let me explain.
One disclaimer first. I my head, for this post like all the others, Technical Communication and Technical Writing is the same thing. If I use sometimes one and sometimes the other, it is just me being distracted, I don’t mean any significant difference. I’ve seen and practiced Technical Writing in so many ways that today I can’t see any instance where calling it Technical communication enlarges the practice. I do so in this post because it is more elegant when I put it beside “Communication”. I’ve asked a few colleagues about that, they couldn’t help me separate the two. If you see a clear difference between Tech Writing and Tech Comm, please help me out and give a description in the comments.
When we first compare Technical Communication with Communication, we see "Technical" as the difference. Technical Communication would be Communication of technical things, making it a sub-set of the other. However, contrary to popular belief, Technical Communication is not used to transfer only technical knowledge: it applies to any knowledge that the audience needs in specific situations. And the audience need is not always technical. Besides, if a Technical Communicator and a Communicator transmit the same thing, they will follow different rules when they do so.
To understand the difference between them, we need to get down to the very purpose of each one: why do we communicate, and why do we communicate “technically”. In Communication, we send a message to a recipient in order to obtain an effect on the recipient's behavior or opinion. We do not want this impact to be random, we want it to go in a direction that is better for us. We are taking the initiative of the message and we want to make an impact, whether or not we feel the need to say it’s for “their own good”.
In Technical Communication, we want to help someone do something or make decisions by putting knowledge at their disposal. We are helping the audience to gain control over their activity, over their tools, over their own decisions. We are helping them gain better autonomy. We don’t want all of our audience to use all of the knowledge we are providing. Rather, we make it accessible, to be used if and when they think they need it.
I think that difference is one we can use. Communication: influence the recipient in a specific direction. Technical Communication: provide the knowledge so the audience can better choose their own path.
Knowing that difference of purpose between Communication and Technical Communication helps us understand the role of accuracy in telling one from the other.
If you want to help someone with knowledge, there is no way you can achieve it with inaccurate information. It is not just the quality of the help, and the fact that an audience cannot have control over their activity based on false data. There is also the trust issue. For someone to rely on the knowledge you provide, that person must be sure that what you provide is always exact. And finally, the content we provide is the official reference, therefore we are responsible for any damage or failure caused by the application of inaccurate knowledge, instructions for example. “What does the documentation say about this?” is supposed to be the ultimate answer to any question.
In fact, accuracy is so important to Technical Communication that if there is a difference between what a tool’s documentation says and the way the tool behaves, it must be the tool that is wrong.
For these reasons, if our audience discovers that the knowledge we provide contains mistakes, their attitude towards everything else we provide and towards all that we represent (our employer, our team, the tool we document, etc.) changes. Our audience will search for another source, possibly another product, and will not come back unless we work very hard for it. And there is no such thing as “almost accurate”.
Communication, now, requires whatever it takes for the intended effect to happen. Sometimes, inaccuracies in the message end up in a fail or, even worse, in a backlash. That is usually when we are confronted with inaccuracies: when we witness the backlash. Most of the other cases are not noticed or considered non important. We are aware that in some situations, being accurate is not a necessity when we send a message. The characteristics of an impactful communication actually depend on the situation: the audience, the topic, the timing, any aspect of the context. And a good communication is either impactful or nonexistent.
Of course, sometimes the accuracy of a message may be critical in a given communication. For example, your recipient may be known for verifying all aspect of the message and react to inaccuracies in a way that is detrimental to the objective. Or the topic can be dangerous if misrepresented. Or any other reason. The point is, accuracy may or may not be relevant in Communication, when it is always essential to Technical Communication. It is a direct consequence of diverging purposes.
Taking or giving
I see another major consequence. It may seem far-fetched, but hear me out. I mean read me out. This is the place where I can boldly go where no one has gone before, anyway. I believe that when we engage in Communication, we take, we push, we are the ones who initiate the attempt at making an impact, to cause a change, in the direction that we decide. On the other hand, when we engage in Technical Communication, we give, because we provide the audience with independence and autonomy, including from ourselves, and they can decide not to take it just as well. I think that as human beings we are very sensitive to that basic difference of perspective, we feel it intuitively.
As Technical Writers, we usually work for Businesses. The purpose of a Business is to make money. For that reason, there is an effort to translate everything that happens in and around the business in terms of money: money that comes in and money that comes out. If you are an experienced Technical Writer, I am sure you have noticed the systematic tendency, in businesses, to consider documentation as an activity that will only cost money. Marketing, on the other hand, is usually seen as a way to get more money. Or lose less money in situations of damage control. Intuitively we associate situations where we don’t try to make an impact and instead put the most accurate info at the disposal of the audience, with giving out. As giving things is generally frowned upon in businesses, because it drags them away from their purpose, Communications and Technical Communication don't receive the same type of love from a business.
I have seen in all the companies I worked for that even when the documentation position is attached to development or engineering or R&D, it is managed and monitored differently: it had the status of a Cost Center when the rest of the development activities had the status of Profit Center.
My point here is to show how far the difference between Communication and Technical Communication extends. I think promoting our objective to help an audience do something because it is a business choice may help with that association with a Cost Center, but that is a discussion for later. Still, feel free to comment on this.
Why care about the difference?
I believe that if you mix up Communication and Technical Communication, you need to maintain a clear indication of which is which.
As Technical Writers, for example, we frequently rub shoulders with at least two main sources of Communication: Marketing and Sales. Mostly Marketing. The marketing professionals' mission is to influence their audience. Marketing needs to cause a change in the audience's mind, and we have to admit that it would be pretty hard to cause a change by providing dry 100% accurate knowledge Technical Writing style. Marketers have to work an angle, at the very least, and they have to add something that a Technical Writer should avoid at all cost: subjective appreciation. For example: "This tool will fit greatly among all your other tools". This is not accurate. A more accurate version could be: "We are confident that, in most cases, this tool will fit among your other tools in a way that you will find agreeable". The first version will push for a change in our opinion towards making the tool more desirable. The second version is true whatever your opinion is, and doesn't need to cause any change. Also no one would read that second statement unless they have to, which is a persistent trait of Technical Communication. The Technical Writer knows that Communication is essential to business success, and is able to see a mixed environment for what it is: One part Communication and the other part Technical Communication.
Why should we know or mind the difference between Communication and Technical Communication? First because they have separate purposes. When we do something, we need to know what we are aiming for, so we can check our progress and change course if needed. Communication is driven by the impact you want to achieve, and Technical Communication is driven by what the audience wants to achieve. This is critical to know when you'll have to answer the question: Are my efforts successful?
Second because doing one or the other requires a different set of skills. One can't be good at everything and the world is full of people that are good at one and not so good at the other. The professionals that are good at both are rare (I don’t think I am one of them).
So, when Communication and Technical Communication coexist, we need to be the most attentive to what we want to do. There could be an interesting discussion about journalism here, but I better stay focused and provide an example involving Technical Writing instead.
Creating a white paper
Generally speaking, a white paper is an in-depth report on a given topic that is often signed by a known expert in the field. It is essentially a tool that helps making decisions, for the readers, and a Marketing tool, for the authors. In the context of Technical Communication, it would develop and discuss a topic more extensively than what should be allowed in the main documentation system. Many Technical Writing teams never created a white paper, because it is seldom necessary, but sometimes the need arises. One such need is dealing with a methodology dispute.
I was going to describe the whole setting including a 6 steps procedure on how to manage a Methodology White Paper project, but I realized that it was going to double the length of this post. That would be cruel, so I’m keeping that procedure for another day (tell me in the comments if you would like to read that).
In the software industry, you may have to document a complex professional tool that could be used in a number of ways. If the tool is made to support specific actions, and allows multiple procedures to carry out that action, then different colleagues who have interactions with the user may have different opinions on what the best procedure would be. Depending on the influence and determination each of these collaborators have, this may lead to internal chaos and extensive but undetected waste of resource.
One way to not only cope with but also use this chaos to your advantage is to work on a methodology white paper. First a choice must be made, that will involve a number of stakeholders in the organization. Then a paper can be created that promotes one methodology tagged as "corporate". It provides the necessary space to expose reasons and details. Marketing needs to be among the essential stakeholders, and must take part in the original methodology choice, primarily because white papers are partly Technical Communication and partly Communication, and Marketing has the authority to handle that second part. They also make sure the impactful part of the document is consistent with the rest of the organization's communication. Besides, they know the rules of using a white paper as a branding tool. The other reason to make Marketing participate is to give the document other stakes than a never-ending engineering dispute that has everyone exhausted already. On the other hand, the Technical Communication part must be perfectly accurate, precise, and consistent with the rest of the documentation, and could even connect with training material or tutorials, and that is the Technical Writer's responsibility. When writing it, everyone needs to know where there is Communication and where there is Technical Communication, so you don’t get unimpactful incentives and dramatized descriptions.
Methodology white papers are a typical situation where knowing how Communication and Technical Communication are different is essential to making the right business choices. It is good to know how to promote your product and at the same time help the users be in control.
The oath
So, to me, the main difference between Technical Communication and Communication is that only the former needs to be accurate at all times, and that characteristic alone suffices to separate the two. This matches my observations so well that if we wanted to list the defining traits of Technical Writing, I could put forth “accuracy” alone, and ignore “precision”, “technical content”, “completeness”, etc.
When I think of the importance of accuracy to Technical Communication, it reminds me of a central principle of medicine: “Primum non nocere”. This Latin quote can be translated to “above all, do not do harm”[1]. Even though it is not present in Hippocrates’ oath, it is taught to medicine students as a basic principle to go by and some of them make it a guiding rule throughout their career.
We should have our own. From now on, whenever I technically communicate, I will live by “Primum non bulshitere[2]”. It can be translated to “above all, do not write that which is not true.” Furthermore, we need to create an oath in which this principle stands in prominence.
Figure 1: Hanged in my office
Are you ready to swear?
[1] In a larger text from Hippocrates we can find a larger quote that says: “dealing with illnesses, have two things in mind: do good, or at least do not harm.” The version used today is a simplified, modern version that was not found ‘as is’ in Hippocrates’ works.
[2] The Latin word “bulshitere” does not exist anywhere.
No comments:
Post a Comment
What do you think?