Rhetoric for Engineers
Most job openings for engineers require "good oral and written
communications skills."
And 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:
- We all think we communicate well. (Few of us really do.)
- We all think others communicate poorly. (Everyone else is just like us.)
- We think of speaking and writing as isolated acts: disconnected from one another and from everything else we do.
- 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?)
- We think of understanding one another as a luxury: something that violates the money and time constraints we all work under every day.
- 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.)
- 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 Ron's e-book
The e-book, Rhetoric
for Engineers, is designed to help you get through
what you need to persuade others to do. It's free -- but
you have to ask for it. I need to keep a list of those
who get it, so I can send an e-mail when a new version
is created. Contact me at
rongraham01@gmail.com
for a copy. It's a PDF, about 2M in size. There are no
sections of the book online at this time, but I will
post new ones as they are written, so you can look
online and suggest changes.
Rhetoric 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.
Summary of Basic Rhetoric
Facets of argument:
- Logos (words, logic, facts) -- How can I make the best argument possible using the data I have?
- Ethos (ethics, personality, delivery) -- How can I maximize my own credibility?
- Pathos (emotion, connection) -- How can I best relate my argument to the audience?
Normally a successful argument requires a warrant, consisting of
- claim
- reason
- grounds
If an audience accepts your warrant, this guarantees the
soundness of your argument in their eyes. For them to
accept the warrant will probably require backing -- evidence.
They may be engineers, after all.
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 Ramage, Bean and Johnson (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 your 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 attack 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 (e.g. God)
- 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)
The RBJ text describes five types of claims from which arguments are generated:
- 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).
Engineers Need Rhetoric
Some of the common 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.
Subscribing to RHETENGR-L
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.
Contents of the Book
A
[abstraction][abstracts][accuracy][acronyms][advocacy][anecdotes]
[anger management][assumptions][audience][axioms]
B
[blogging][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][media relations][meetings]
[memory][mentoring][mission statements][mistakes][motivation]
N/O
[naughty words][negotiation][netiquette][new employees][nomenclatures]
[note-taking][organization charts]
P
[paraphrasing][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][social networking][software manuals][spam][specifications]
[speech distractions][speeches][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
[warnings][Web design][Web reliability][Web usability][work orders]
[workplace distractions]
Dedication
This book is dedicated to my children, Robert and Elisabeth,
with all the love I can give and a strong desire to give them
something to be proud of.
References and Resources
- Ramage, Bean, and Johnson. Writing Arguments. Needham, MA: Viacom, 1998.
- Hult and Huckin. The New Century Handbook. Needham, MA: Allyn & Bacon, 1999.
- Korpela, J. "How All Human Communication Fails, Except by Accident." http://www.hut.fi/u/jkorpela/wiio.html
- Tufte, E., Visual Explanations. Graphics Press, 1997.
- Leighton, R. and R. Feynman. What Do You Care What Other People Think? Norton & Company, 2001.
- Vaughan, D. The Challenger Launch Decision. University of Chicago Press, 1997.
- Florman, S. The Existential Pleasures of Engineering. St. Martin's Press, 1996.
- Tannen, D. You Just Don't Understand: Women and Men in Conversation. Ballantine Books, 1991.
- Lutz, W. The New Doublespeak. Harper-Collins, 1997.
- Hickam, H. Rocket Boys. NYC: Doubleday, 1998.
- Mooney, J. and D. Cole. Learning Outside the Lines. NYC: Fireside Books, 2000.
- Kehoe, B. Zen and the Art of the Internet.
- Brooks, B., J. Pinson, and J. Wilson. Working with Words. NYC: St. Martin's Press, 1999.
- Williams, J. Style: Ten Lessons in Clarity and Grace. Addison-Wesley, 1999.
- McCloud, S. Understanding Comics. Northampton, MA: Kitchen Sink Press, 1993.
- Adams, S. The Dilbert Principle. New York: HarperBusiness, 1996.
