Team building grammar lessons - summary

[Hope Cascio <hcascio -at- GTE -dot- NET>]

Thanks for all your help.  The summary, as promised, and my apologies
for the delay.
Hope Cascio

RESPONSES
Have done it before and think it doesn't help: 1
Never did it, don't have time, and don't think it'd help: 2
Would like to try it: 1
Do it now, and think it's great: 3

*****************

Snippets from those opposed:

Had one such experience, which mostly devolved into ego battles over who

was a more experienced editor. "I'm right. You're wrong." "Am not" "Are
so."
-D. Margulis

We call it "multiple deadlines"  ;-)  No, we don't do these exercises.
Then again we don't have the time to spare (consulting company).
-Bill Swallow

"Having been in a tech pubs department before on several occasions, I
can
safely say that we never did bother with grammar building exercises.  We

didn't have the time.  Further, if we couldn't write in the first place,

no amount of grammar building exercises would've helped, nor would we
have even been hired."
-George Mena

*****************

Opportunities and "how-to"s for those who'd like to try it:

"Promulgate a professional attitude, by which I mean the understanding
that style guide rules are arbitrary conventions and that we all
cooperate in following them in order to maintain consistency among our
assorted pieces of the overall department output.

"Following from this understanding, writers should be able to submerge
their personal preferences and conform to the boss's arbitrary decisions

on matters of style.

"Establish a mechanism for suggesting revisions and enhancements for the

style guide and for issuing periodic updates.

"Make the style guide as comprehensive as it needs to be (depends on the

scope of the despartment's tasks, how many writers, etc.). This may
involve detailed explanations of template use, boilerplate phrasing for
procedure writing, and more, in addition to the usual grammatical stuff.

"The final component is the editor-writer relationship. The
manager/editor needs to work one-on-one with some writers to convey
exactly where the writer's work deviates from acceptable style and to
suggest how to improve the work. If the writer still doesn't improve
after a few cycles of this kind of direct feedback, it's time to look
for a new writer.

"An optional additional mechanism is the "Winners & Sinners" strategy.
Collect examples of good and bad style and hand them around periodically

with your commentary. If possible, keep the bad examples anonymous."
-D. Margulis

In answer to your question - yes, emphatically yes.
I have a team of really junior writers here. One of my big challenges is
to
grow them as fast and as well as possible so they can take on more
responsibility sooner. The company is growing really fast - I have to
have
at least two 1-year-out-of-school writers ready to lead project teams by

the end of the year.

They are a very willing and very intelligent bunch, who have really
"stepped-up" to the challenges they have here. During one of our "what
do
you need from me so you can do your jobs better" conversations, they
suggested that we add an ongoing "formal training element" to our
workflow.
As always, I put the person who came up with the idea in charge of
figuring
out the logistics.

We run two two-hour sessions each month that run over lunch (so we only
lose 1 hour of productive time per session). I do one session, my staff
rotates the other one. Each session consists of a half hour
presentation,
followed by a workshop. All samples used in the workshop are in-progress

work. I give the presenter 10 hours to prep.

Topics include points of grammar, style, layout, information design,
documentation management, tool use, design and use of style guides,
printing methods, graphic design, graphics tools, editing, proofing,
analysis, analysis and analysis of technical information, research
skills,
interviewing skills, creativity exercises, how to run meetings, how to
run
worshops, instructional design, designing help, designing CBTs, project
planning, risk management, resourcing, interviewing job candidates,
verbal
communication, conflict resolution, tracking projects, costing projects,

reuse implementation, negotiation, technologies we use internally,
programming, leading edge technologies.. etc...

This is supplemental to very thorough feedback and in the course of
their
usual work.

Key benefits:
The obvious aquisition of professional knowledge
Team bonding - these workshops, after a bit of a rough start when we
didn't
know what we were doing yet - are really fun.
Extremely rapid professionalization of junior staff
Presenting skills!
Fame - things are going so well with the program that we have been
joined
by three software developpers and two people from corporate services,
starting about three months ago.
"Currentness" - this is forcing me to keep my skills very current. Can't

hurt!

Key problems/obstacles
Time and cost - which really are the same thing.
Fame and Politics (which is why I would ask you to NOT use my name if
you
post a summary to the list). - A lot of people have their noses out of
joint that they don't have access to this training. Another faction
thinks
that WAY too many resources are going into it. I think I was given a
task
to turn a bunch of kids into senior writers and project leaders in 18
months, so I think the critics should all close their mouths and let me
do
my job in peace.
Another criticism I hear a lot is that the topics aren't "directly
applicable" to the job at hand. My response is that to lead, you have to
be
able to make decisions, and to make good decisions, you have to be able
to
understand the whole picture in context.
Finally, we work in an environment with great planning - so we don't
have
those horrible crunch times when you have to cancel everything that
isn't
cranking doc. It helps.

Unfortunately, it doesn't look like we'll be able to continue beyond the

end of fiscal (October), which is too bad, although I'm still lobbying
hard.

FWIW - I'm really proud of what we've accomplished here, and how far my
team has come so fast. They've taken ownership of their work and their
own
futures in a way that totally exceeds my expectations every day. This
place
isn't perfect, but there are some definite up sides.
-Candace Bamber

Long time ago when I was a pubs mgr, our weekly dept meetings were
training sessions.  I did not waste anyone's time with oral status
reports!  Instead, I taught my software writers on how to write hardware

field service manuals, concepts of telecommunication, structured
documentation, database documentation, latest innovations in software
documentation, tool utilities (at the time we were migrating over to
UNIX with writers workbench, nroff, troff).  The writers that wanted to
present topics did so or started roundtable discussions.  Our workshops
became so popular, that we began offering lunch time brown bag workshops

for writing technical reports, word processing techniques, etc. to the
developers, secretaries, and engineers. If you contacted any of the
writers today (12 years ago this was) they'd still tell you those dept
meetings were the best they ever attended.
-Joy White

*****************

And a last note from one of the optimists:

"Where I work there are four of us within talking distance of each
other, and
we have casual discussions about grammar/copyediting/usage etc. as
the items come up. But since I've been here no formal exercises or
workshops. I think the idea is great - even the most experienced
writer/editor needs reminders occasionally, and also it would be a
good for reinforcing department styles."
-Kate Kane

 --
"Just because a network architecture has been designed to survive
 nuclear holocaust doesn't mean it is immune to WebTV or a bunch
 of sociopathic 12 year olds." -Lon Stowell, alt.folklore.science

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=