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 think a lot depends on what the managers are accustomed to seeing. If their experience includes TWs who stare dreamily off into space for long periods, but always seem to meet schedules, then that behavior becomes acceptable. If their experience is with "heads-down production writing," such as software documentation, instructional writing, or help files that follow a standard format and are developed from (relatively) explicit notes, then checking your personal email to "network" while you are working is a big no-no.
Similarly, if your position requires that you architect documentation solutions--rather than just writing to a plan--you are in a fundamentally different category of employee. You also may be able to get by with substantially more staring into the middle distance on company time while formulating those solutions.
For a large number of employed technical writers, such activities would be considered a luxury. For a large number of managers, such activity would be considered a failure to competently organize the work up front. That is, the concept of prying information out of reluctant, hostile SMEs so the TW can understand, simplify, and document that information for a non-technical audience is increasingly viewed as inefficient and wasteful.
In several dozen organizations I have dealt with in the past few years, TWs are considered glorified secretaries who are given a set of constraints regarding acceptable documentation, a set of templates, a style guide, and are otherwise expected to spend the majority of their time onsite pounding keys. They are given topic sheets or other explicit information, and transfer that information into documents or help files with explicit format. Like most production work, there is usually a specific minimum number of pages/topics/files required per hour, per day, or per week.
The confusion seems to arise when document designers or developers are lumped in with production writers. For example, I don't write documentation; I design the templates, formats, and style guides that TWs use to create the documentation. I stare into space a lot, and get paid for it. I also know personally three writers who have been fired in the past year alone for writing personal emails, or surfing to "non-business related sites" on company time.
In the good old days, when a competent programmer could expect a $100,000+ salary and sulk for days unless he or she could bring a pet (usually a very large, smelly dog) to work, anyone with even a modest level of technical expertise was pampered, overpaid, and coddled mercilessly to keep them available.
In those good old days, hostile SMEs were considered a fact of life, and TWs were expected to gain their information from unwilling experts with enough clout to have a hissy fit if asked to explain their arcane concepts, jargon, or code to others. That clout is mostly gone, and the current crop of SMEs seem to understand that cooperation and team functioning is a pathway to continued employment.
The point of all this is simple; if you are a technical writer with less than 10 years experience and a considerable amount of expertise, you would be well-advised to keep your head down and focus on productivity a bit more, rather than believing that socialization, writing personal emails, and surfing the Internet on company time is acceptable behavior. It may be for "senior writers" or designers, but if you have to ask if it is acceptable, you probably don't have enough skill or clout to pull it off.
tekwrytr http://www.tekwrytrs.com/ - Contract business analysis and solutions development in Visual Basic .NET, ASP .NET, SQL Server, and XML. Specializing in cost-effective rapid application development (RAD), prototyping, and service-oriented architecture (SOA) IT solutions for SMBs.
_________________________________________________________________
Time for vacation? WIN what you need- enter now! http://www.gowindowslive.com/summergiveaway/?ocid=tag_jlyhm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
