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.
Keith Cronin wrote the following, in response to a post by Tom Murell:
"Tom, I'm all about teamwork. Part of teamwork is each member doing what
they're supposed to do. IMO, if EVERYTHING is a group decision, efficiency
suffers, bigtime. Think about it: When a deadline is announced, do you
launch a "team-building exercise" so that everybody can "share their
feelings" about the deadline? Or do you say "It's due in two weeks - we
better get a move on"? Most businesses are not democracies - we have
bosses who tell us what to do. I'm suggesting that you appoint a Style
Boss. You want democracy? Then VOTE on who that person will be."
Here's my two cents, and apologies for coming late to the party: I'm on digest.
I just did the whole style battle. lt took me a full year. Here's what I learned. Style Committees do not work. As soon as the Committee researches and surveys users on preferences, determines one, and announces it, people, who prior to this had no opinion either way, suddenly detest the new standard and more debate results. Unfortunately, those people were typically managers and higher-ups, who I simply couldn't tell to like it or lump it.
Next, we tried inviting the nay-sayers to meetings, to get their opinons up front. They never showed. We tried newsletters, surveys, email and phone messages. Barely a dent.
We then tried to do it all ourselves. And we did, because I finally got so frustrated, I directed everyone to spend ten minutes each pitching their favorite style, standard or font choice, and I would pick one and move on. We had some intense battles over the merits of Courier New over Andale Mono to represent computer code. I chose Andale for no other reason than our user docs (a different team) use that font and I wanted consistency.
I went to my boss and told him I will not inventory any course written using a non-approved standard. That's precisely what happened when we released the new Guide; the folks who didn't like or didn't agree with my choices simply refused to use them. Once a few courses were late, that stopped.
Tech writers in general share a few basic traits: perfectionism tendencies, patience, and a deep passion for the words they create. These are all good things. However, in a team environment like ours, those strengths have been known to flip sides and become detriments. Non-writers on our teams have actually admitted they see no difference between Arial and Times Roman and cannot comprehend why we obsess over it. They think we're being anal-retentive, when it was actually a corporate mandate that all publications use the former font for headings and titles. Non-writers do not see why we make a big deal about bolding a new term in one module, then italicizing a new term in a subsequent module. They don't always appreciate that consistency is akin to quality. Font choices, as you know, are only one small part of an overal Style Guide. I thought the team was going to walk out on strike when we removed the terminal punctuation from our bulleted list of learning objectives. [Do NOT reply with your impressions of that decision. Trust me that I had valid reasons for it. It's done, it's made, live with it!]
I finally realized and accepted these points of views, understanding that they believe we are intentionally making them miss their deadlines. I then tossed the whole democratic approach out the window and simply directed teams to use the styles I thought made the most sense. In some cases, we had to follow corporate directives. In other cases, we went with an industry-accepted standard, like the Microsoft Manual of Style. In still other cases, I admit my choices were completely aribitrary, just so we could get back to developing courses.
[/End Rant]
I hope this helps you. When you really stop to consider it, no one will die because we chose Andale over Courier. It's not the big deal passionate tech writers here believe it to be. You need someone to determine which standard to adopt and that person requires the clout to enforce its use.
Patty Blount
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Experience RoboHelp X3! This new RoboHelp release combines single sourcing,
print-quality documentation, conditional text and much more, into the most
monumental release of RoboHelp ever! http://www.ehelp.com/techwr-l
FrameMaker-to-PDF TimeSavers Assistants let you enhance & automate navigation
in PDF doc sets (chapter tabs, next/prev chapter/pg, bookmarks, popup menus);
create interactive PDF forms, rollover popups; presentations: http://www.microtype.com
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
