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.
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.
Although my experience was different than Patty's (my team came to consensus), we share the same conclusions. In my experience, we created a style guide and process guide through this method:
Note: The technical writing team was divided into groups of 3-10 people each reporting up to a team leader. There were at that time four team leads, plus one manager.
- the team met and came up with the outline for the guide
- a first draft was created by an individual
- each team lead met with his or her team to get feedback and ideas for adding, changing, deleting from the guide
- filtering up through the team leads, we as team leaders voted on standards, coming to a consensus on which standards to use
- this process was repeated at least once
- the final draft was revised by the team leads at least once after the first and second big "editing" sessions per team
Finally all of the teams used the standard "out in the field". I found with my team that exceptions constantly cropped up, but it was based on need. For instance, we didn't have a lot of online standards in the first draft. My team became the team to adapt and pilot changes to the standards when we had reasonable reasons for exceptions.
The reason I as a lead did not want to arbitrate final style decisions WITHOUT input is that I am only one person. I like the synergy of a team working together to create a style. The reason I took the responsibility to make the final decision in cases of lack of consensus was practicality. We have to get our work done. For the most part, the team, although passionate about their opinions and details, would buy into a decision they had a part of. Most seemed to understand the importance of compromise and following the agreed upon styles. Of course, I had also interviewed and picked the people on my team so that ability to compromise was part of my hiring decision. So I guess I stacked the deck in my favor.
Finally, once the piloted new standard came into being, it did have to be passed through the team leads and the manager to be officially adopted. In the case of the team leads, the manager had final decision-making authority.
The point is, teamwork can work. However, someone does have to be designated as the final decision maker. And the team must be built and nurtured carefully. By nurtured I mean they need to know what the goal is and what their part in the decision is. If most technical writers know the goal will require compromise, they can compromise on these details. The ones that can't need to be in one-person shops (in my not-so-humble opinion).
Peace like a river,
Enhance, optimize and automate your FrameMaker-to-PDF workflow with TimeSavers:
Define all PDF features in your source FrameMaker files ONCE, distill MANY.
Bookmark Controller, Link Controller, UnBloat & more : http://www.microtype.com
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
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.