TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Ladies and gentlemen, I... er... From:"Steven J. Owens" <puff -at- netcom -dot- com> To:markl -at- gilian -dot- com Date:Mon, 20 Dec 1999 15:21:15 -0800 (PST)
Mark L. Levinson writes:
> The boss wants me to speak to the employees for half
> an hour or so. He's not sure he has a subject to
> recommend, but he wants me to speak, evidently in
> order to broaden their understanding.
Hm, lacking any of context, I'll assume that your audience is
mostly programmers and your purpose is to give them a better
understanding of what it is you do and how that contributes to the
company.
I'd suggest you start with a few choice qoutes from Frederick
P. Brooks' _The Mythical Man-Month_, specifically documentation
chapter and the chapter on the importance of communication
(essentially there's a passage where he say the project leader will
often assume something is common knowledge when it is not; writing
things down creates a sort shared memory). Brooks is a classic in the
field so this should go some way towards establishing your validity.
Then try one of the exercises people have mentioned - I suggest a
very brief one, like the tie. I like that one because you are indeed
likely to be able to find somebody who has never tied a tie and has no
idea how it works or what the parts are. The one my first english
professor in college used was putting on a jacket. But you have to
have somebody prepped to be the dummy for this one, otherwise they're
likely to unthinkingly use knowledge, like what a lapel is, etc.
Just for kicks, once somebody has worked through a "normal" tie,
get another sucker from the audience to give directions, then once
he's faced away from you, pull a bow tie out of your pocket and watch
the audience laugh. You may not want to go all the way through this
exercise :-). If somebody in particular has pulled the
last-minute-change routine once too often, try to set them up as the
mark for this, particularly if it's a well known issue.
An excellent gimmick I remember hearing in 1995 was when a
techwriter speaker at some conference had big cue cards with unlikely
images to get people thinking. One example was a drawing of a cow's
udder, to convey the idea that a writer (and a programmer!) is like a
cow placidly chewing its cud out in the field, it may seem like it's
not doing anything, when in fact it's doing something essential to its
job of producing milk. Just so, a writer or progammer must spend some
time in any project gathering information and assimilating it.
Once you get past this point, I think the best thing you can do
is focus on understanding your audience and learning to questioning
your assumptions. You can't convey a sense of the skill of actually
writing, but you can get them to start thinking about the idea that
maybe the rest of the world doesn't know what they know, doesn't think
the way they think, and that they can't rely on their assumptions.
One thing I find very useful in public speaking situations is to
turn it around and start interviewing the audience. This makes me
feel much more at home, breaks the tension, gets the audience
involved, and generally makes for a more interesting presentation.
Make sure you make your questions real, and use two or three on each
person you single out. Ask for volunteers but also make sure you
actively spread the questions around. Treat it like an SME interview,
have an agenda and a series of questions, have a point to drive at.
What exactly that point should be is another question, but you
know your company. Maybe you should try to determine what are the key
assumptions that everybody has about the company? Maybe run a little
exercise where you pretend you're writing a "welcome to our company"
guide and you're interviewing everybody there for both the answers and
the questions.