Most of us think we communicate well. No doubt we can prove we've got "good oral and written communications skills," if only we know (a) how we're supposed to demonstrate it and (b) how the people advertising the job are supposed to measure it.

Well, we don't get to know that in advance. So we'll ship out our resumes and cover letters , maybe even include samples of our work when it's appropriate. We might even get called into interviews. But we'll never know for certain what it was they were looking for, or how they knew when they found it.

That's because anyone can communicate effectively if they know what to say and have enough time to prepare to say it. And that's why the want ads are mostly useless. The interviewers can never be sure they've gotten the right people on the basis of one interview, or even two.

Interviews are just one demonstration of the difficulties we techies have in communicating with others. Even with each other. We work under mistaken premises:

1. We all think we communicate well. (Few of us really do.)
2. We all think others communicate poorly. (Everyone else is just like us.)
3. We think of speaking and writing as isolated acts: disconnected from one another and from everything else we do.
4. Still, most of us really want to understand, and to be understood. (Few of us want to have to work for that understanding; we'd rather just throw that job "over the wall" to someone else. That's what the "tech writers" are for, right?)
5. We think of understanding one another as a luxury: something that violates the money and time constraints we all work under every day.
6. We think that once we've mastered some discipline area, we've become the experts our jobs require. (But mastery over a subject area isn't the same thing as effective communication of that subject. Some very smart people are never recognized for their greatness because they can't explain the consequences of their actions to others. And some dummies get promoted because they can talk themselves up.)
7. We think that if one person (e.g. the boss) understands what we've done, that everyone does. (Not only is this a mistake in and of itself, but we have to look at that one person's understanding: did it show itself in nods of agreement only? Hmmm?)

Welcome to Rhetoric: the art of persuasion. Sure, it's primarily through speaking and writing that we persuade others -- but the key to persuasion is to abandon all those mistaken premises above, and recognize that everything we do is interconnected. To study "tech writing" isn't enough for us -- that reinforces writing as an isolated act, and cuts us off from tools that could be vital to our persuasiveness:

• the way we collect, organize, and interpret data
• the way we design new products
• the way we make decisions
• the way we inform (or warn!) the public

On Using This Book

So Rhetoric is a new discipline for you. That's OK. This isn't a discipline you can master just by reading a book anyway. And this book isn't a narrative. It won't do you much good if you read it cover-to-cover. It'll help you more as a desktop reference.

It's organized by subjects, and in alphabetical order, rather than by some classification of gradual learning. That's because you may already know some of this stuff, and may need to concentrate on the rest.

It contains the combined knowledge and experience of hundreds of engineers and specialists in certain areas of persuasion. You may not always agree with what you read here, but Rhetoric isn't an exact science. What's recorded here has worked for myself and some others, but often you'll see multiple points of view on the same subjects, and you'll have to decide for yourself which point of view best fits your particular needs.

So now you say, "Great. I thought this book was supposed to help me communicate better. But he's saying I shouldn't read it, that I might not always go along with what it says, and that it might not help me." Calm down. It will help you. Even when you disagree with what I've recorded here, formulating your disagreement will help you. Even if you can't benefit from reading cover-to-cover, the individual subjects will take you places you may not have considered before. Considering something new will also help you.

You want to know what you can do right now to become more persuasive in your technological world. I have included tips under several sections that tell you What You Can Do. I have included "Two-Minute-Drills" designed to help you practice answering a question with technical content quickly.

But if there's one thing you can do -- right now -- it would be to always seek to be understood. Make "being understood" the most important part of your job description. And go from there.

Ramage and Bean, Writing Arguments is a commonly-used intro textbook. Needham, MA: Viacom, 1998.
Hult and Huckin, The New Century Handbook, contains loads of examples in nearly all non-technical areas of rhetoric. Needham, MA: Allyn & Bacon, 1999.
Korpela, J. "How All Human Communication Fails, Except by Accident." http://www.hut.fi/u/jkorpela/wiio.html
TCNJ Rhetoric Program

Summary of Ramage, Bean, and Johnson, Writing Arguments. Needham, MA: Viacom, 1998.

Facets of argument:

• Logos – How can I make the best argument possible using the data I have?
• Ethos – How can I maximize my own credibility ?
• Pathos – How can I best relate my argument to the audience ?

Normally a successful argument requires [claim/reason/grounds]. If an audience accepts a warrant (a principle that, if held, guarantees the soundness of an argument), [backing] or [warrant/backing] may be enough.

An enthymeme is an incomplete logical structure that depends for its success on an unstated warrant. Aristotle believed that the best arguers could develop enthymemes for arguments with strong warrants – basically, that the best arguers would know their audiences and how to best reach them with an argument.

Sources of evidence cited in RBJ include personal experience (e.g. memory and observation) and data collected from surveys, interviews, etc. The engineer has these to draw from when dealing with people as sources; but when dealing with systems, engineers can look at these sources of evidence of system functionality:

• Analysis
• Demonstration
• Inspection
• Similarity
• Test

Logical fallacies

In Logos -

• Begging the question (restating a claim in different words)
• No-win situations (no response can be received completely positively
• Zero-sum games (only two choices appear possible)
• Precedence is cause (X came before Y so X causes Y)
• Slippery slope (we have to continue once we start)
• Broad brush (a large generalization based on insufficient evidence)
• Faulty analogy (X = Y because X ~ Y)
• Non-sequitur (a claim doesn’t follow from the grounds)

In Ethos -

• Appeal to false authority (e.g. Joe DiMaggio as an expert on coffee makers)
• Ad hominem (an attach on an arguer rather than on the argument)
• Strawman (oversimplification for ridicule purposes; easier to burn an effigy than a person)

In Pathos -

• Stirring symbols (wrapping yourself in the flag)
• Invoking the unexaminable
• Irrational premises (e.g. we can do X because (a) everyone does; (b) we’ve always done it before; (c) lots of people like it when we do)
• "The devil we know" (as opposed to "the devil we don’t know")
• Red herring (appealing to an irrelevant issue)

• Definition : X is/is not a Y
• Causal : X causes/does not cause Y
• Resemblance: X is/is not like Y
• Evaluation : X is/is not a good Y
• Proposal : We should/should not do X

Various methods of developing claims in each of these categories are laid out in the RBJ text – but from the engineer’s perspective, development comes primarily from the five means listed above (analysis, demonstration, inspection, similarity, testing).

Some of the top Rhetorical questions faced by engineers:

• Who’s the right person for the job?
• Does the project justify continued support?
• Is the idea ready for a prototype ? Is the product ready for market?
• Is the (component/system/methodology/project/company – pick one) failing?
• Which methodology is better?
• Will this decision improve the quality of product or service?
• Are we doing the right thing?

Notice how the answers to each of these questions (when they exist) fall neatly into the types of arguments listed above.

Technical writing texts traditionally assume that the reader has the information necessary to give some answer to these questions. In that case, the teaching of Rhetoric is all about the presentation. The engineer, however, is faced with decisions that go beyond the presentation, all the way to the nature of the question(s) asked:

• Am I asking the right question(s)?
• If I’m not, do I need someone to help me figure out the right question(s)?
• If I am, am I asking it of the right person(s)?
• Does the answer call for action?
• If it does, do we have time to take the action?
• If it doesn’t, in what other ways is this important?
• Do I have all the data?
• If I don’t, do I have enough of the right data?
• If I do, do I have too much data?

Once these questions are answered, then the engineer will (if there’s time) consider the presentation. That’s another problem with the profession: sometimes the engineer will give so much consideration to gathering data, and considering the questions themselves, that there’s little time to do justice to the presentation of the data.

Here I’ve collected material from the Rhetoric for Engineers mailing list, as well as from work and classroom experience. The purpose of the mailing list is to discuss Rhetoric as it impacts the work of the engineer.

To Subscribe to the Rhetoric for Engineers mailing list, send an e-mail to

listproc@tcnj.edu

and in the body of the e-mail, write

SUBSCRIBE RHETENGR-L <your e-mail address> <your name>

minus the brackets <>. Once you subscribe, there are a couple of simple rules of courtesy:

• If subscribers ever want to respond to me (or to any other individual on the list) directly, don't do it by clicking on "Reply." That would send your response to the whole list. In general, you should make sure what you write is of interest to all subscribers first.
• Subscribers will follow Usenet rules of courtesy, or will be quietly removed. If you have any doubt regarding what constitutes " netiquette ," refer to newsgroup news.announce.newusers, or at least look at (The Engineer's Companion) for the standards of behavior expected within the sci.engr newsgroups.

A

[abstraction] [abstracts] [accuracy] [acronyms] [advocacy] [anecdotes] [anger management] [assumptions] [audience] [axioms]

B

[bottlenecks] [brainstorming] [bullshit] [business etiquette] [business plans]

C

[CAD] [CGI] [CSS] [cause and effect] [chart readability] [chat rooms] [citing sources] [claims] [conclusions] [conflict] [context] [contracting] [conversation] [cover letters] [creativity] [credibility] [criticism] [customer service]

D

[disabilities] [diversity] [document management] [doublespeak]

E

[e-commerce] [e-mail] [engineering judgment] [enumeration] [equality] [equations] [ethics] [experiment design]

F/G

[FAQs] [failures] [fallacies] [flame wars] [FrontPage] [gender-neutrality] [grandmothering] [graphic design]

H

[HTML] [hand calculations] [hand sketching] [human error] [human factors] [humor]

I

[idioms] [imperatives] [independent verification] [innovation] [instant messaging] [instructions] [intellectual property] [internationals] [interviews] [investors]

J/K/L

[jargon] [Java] [JavaScript] [knowledge management] [licensing agreements]

M

[machine translation] [mailing lists] [management] [manufacturing plans] [marketing brochures] [marketing plans] [measurement] [meetings] [mentoring] [mission statements] [mistakes] [motivation]

N/O

[naughty words] [negotiation] [new employees] [netiquette] [nomenclatures] [note-taking] [organization charts]

P

[performance appraisals] [person] [perspective] [plagiarism] [PowerPoint] [precision] [press releases] [privacy] [progress reports] [project management] [proofreading] [proposals] [prototyping]

Q/R

[quality] [quality assurance] [regression plots] [requirements] [resumes] [reverse engineering] [risk] [role-playing]

S

[SPC] [sanity checks] [self-esteem] [service calls] [shop methods] [simplicity] [simulation] [software manuals] [spam] [specifications] [speeches] [speech distractions] [spellcheckers] [spreadsheets] [start-ups] [statistics] [storyboarding] [summaries] [surveys] [systems engineering]

T

[table readability] [teams] [tense] [timelines] [time management] [trade shows] [truth] ["two-minute-drills"]

U/V

[unit correctness] [Usenet] [vendors] [videoconferencing] [viewgraphs] [visual cues] [voice] [voice mail] [voice recognition]

W