Re: **Defining Tech Comm**

[Michael Keene <MKEENE -at- UTKVX -dot- UTK -dot- EDU>]

On Tue, 15 Nov 1994 Jefrson -at- OSUUNX -dot- UCC -dot- OKSTATE -dot- EDU wrote:

> Technical communicators' goals should be to encode a message
> and send it through a channel to a receiver, causing the
> receiver to act on the message in a way that proves that
> the message made it through the system  <snip>

I think that's way too simple.  The last consulting I did was to write a
report explaining the innovation process for a large chemical
manufacturing company.  The "message" didn't exist until I created
it--those people did not know what that process was (although they had
scraps of paper about it) until I showed them a draft.  The channel did
not exist until we all sat down around a table and created it, and during
the year after I finished the report the channel kept changing.  And the
effect changed both during and after I completed my task, both in ways I
could plan for and in totally unexpected ways.  The desired "act on the
message" was always undefined, and although it finally did not include
"change the corporate culture" to nearly the extent some of us (me) had
kind of hoped for, it did help the client get a nice national
recognition--also something completely unexpected.  So not only are there
all kinds of (linear) feedback loops and (nonlinear) field effects that
your description doesn't hint at, there is also the issue of "the message
doesn't exist until those words hit the page and the page hits a reader
and the reader responds."  Which is to say, once again, at least in
lowercase letters, creativity plays no small part in technical communication.

Mike Keene
mkeene -at- utkvx -dot- utk -dot- edu