Small companies ask writers to handle an incredible range of tasks, requiring writers to dynamically manage their work load. This paper reviews scheduling guidelines and tips for survival and success.
Priorities Balancing Act The List and the Schedule Using the Schedule Abandoning the Schedule Updating the Schedule Tips on Non-writing Projects Diversity References A technical writer in a small company may have a job
that's not part of the job's description. In fact, the writer may not have a job
description at all! A small company or branch office, which is defined here as a
firm or branch with fewer than 150 employees, may require the writer to handle a
range of tasks that may include any of those listed in the following table. Note
that these tasks may be peculiar to high-tech companies, which is the corporate
environment I'm most familiar with. The grouping of any of these tasks could be re-arranged,
but note that writing technical documentation isn't even mentioned on this list,
although it is theoretically the writer's top priority. The professional literature in our field supports claims
that we are asked to do a lot more than writing as part of our jobs. For
example, the articles in the 2/94 issue of Technical Communication (1), review a
range of subjects writers may be requested to understand: · "Publication Production: An Annotated Bibliography" · "Index in Computer Documentation" · "An Approach to Competitive Assessment" · "Worth a Thousand Words: Choosing and Using
Illustrations for Technical Communication" The German counterpart of STC, tekom, supports the
argument that our work can encompass a wide diversity of responsibilities.
Tekom has drawn up a professional vocation description, sent to the STC
by Claus Noack, tekom president (2). In the German description, a "technical
author" is listed as having many of the functions listed in this paper,
including "layout design and release for publication... production and control,
distribution, storage and overall planning." How can we handle so many responsibilities and still do
our job well? In choosing to work for a small company or office, you may
be choosing the diversity such an environment offers over a more controlled
environment where you'll be asked to work in a more concentrated manner on fewer
tasks. This diversity and opportunity can be exhilarating, but it can also be
overwhelming. To survive, you need to be flexible and know when to say "enough."
Part of any writer's job is to manage one's work load; this becomes even more
important in a smaller firm. To determine when to say enough, you'll need to: · understand your manager's priorities, your priorities,
and your professional interests · track projects and requests for your time. You must work with your manager (whether your manager is a
writer or a software engineer or a marketing vice president) so that you
understand your manager's perception of corporate priorities and your
responsibilities. You must also keep track of incoming requests for your
professional help. One of the advantages of a small company is that you know who
does what; however, that means that your colleagues know what you do, and will
come to you directly for help. I have been asked to do everything from writing
functional specifications to teaching a class on networking technologies (I
turned down the latter request-I know my limits!). I learned to keep a list of
every single task requested of me, even if it was just jotting down the request
on my white board. You must also always keep your eyes on your primary
responsibility. In my current position, I am in charge of documentation for a
complex technical software product; because of this, I have to keep a close eye
on my relationship with the technical and support staff, because they are key to
excellent documentation. Without a good working relationship with the technical
staff, my books won't be good. In other positions, my primary responsibilities
have involved a marketing role; in still other companies, I've had to work
closely with project managers rather than directly with engineering staff. Because you have the opportunity to handle a variety of
tasks that need to be done in a small company, you may want to take
responsibility for some projects that allow you to gain new professional skills.
If so, make this clear to your manager, and find time for it when you can. For
example, along with writing manuals, you may want a better understanding of how
a business works, how marketing departments are run or marketing materials are
written, or how to create hypertext documents. Make sure you have some
assignments occasionally that help you learn new things that you are interested
in. This is important to you, as a professional, and to the company, which
requires a staff with diverse talents. If you don't stay excited about your
work, your work suffers. If your work suffers, the company and your colleagues
suffer, and sometimes very directly, depending on the size of the company. So far, this paper has reviewed three elements you must
balance: · assigned projects and incoming requests for your
help · focus on your primary responsibilities, negotiated
between you and your manager · projects that interest you and allow you to take
advantage of the diversity of a small office This is quite a bit. To handle this, you must be flexible,
but disciplined about your primary responsibilities. You have to be willing to
fight the fire of the day is, to find out what needs to be done, and then to get
somebody to tell you where this fire fits into your list of priorities. Keeping track of requests for your time, project status,
and all of your various assignments requires you to stay organized, even if you
can take the time to stay organized only once in a while-once a week, or between
chapters or projects. To start, make a list of the tasks you are responsible
for, or asked to do, and perhaps some information about the task, including who
asked you to complete it or why it is important. Next, to keep from getting overwhelmed, you must create a
"ball park" schedule for the work. Although this can be irritating, in that it
keeps you from doing "real" work, (such as completing one of the tasks on your
"to do list") a schedule can keep you on track and very productive. Creating and
maintaining this schedule is part of the discipline required of you in working
in a small company. The following table lists some scheduling guidelines.
These are gleaned from my own experience, professional literature in the field
of technical communication, and work by Jonathon Price and Henry Korman (3).
In addition, when you are putting together the schedule,
consider the number of hours per week you will spend on documentation projects;
often, if you will be working on the project full time, you'll need to allow
only about 35 hours per week for this work, with the rest of the time set aside
for meetings, downtime, illness, vacation, etc. Estimate the size of your documentation, guessing on the
high end to provide a cushion against unknowns. Use documentation of competitive
products (if you can find any) to help you guess at the length of your book or
project. You may want to consider familiarizing yourself with a few
scheduling tools. In spite of my reluctance to learn and use these tools, they
are very helpful in getting the point across to management or colleagues that
there is too much work to do in too little time. In addition, schedules can help
you make arguments for more time, capital equipment, software tools, and
additional help to get the job done Next, arm yourself with your schedule, your list of tasks
and priorities, and an estimate of the number of projects and other requests for
your time, and your understanding of your own priorities and that of your
manager. You're ready to induce some level of control into an otherwise
potentially chaotic environment. Use the schedule to manage your work load. When someone
asks for something and you have a higher priority, you can add it to the list
and review where the item falls within the current list of priorities and
schedule. Remember, the schedule is a constantly changing document, not
something fixed in stone. You may occasionally need to completely abandon your
schedule or plans-for example, you may need to abandon the schedule if the
engineering team makes a major change in a product at the last minute, or you
receive an ad hoc assignment that you must complete to satisfy a major client.
You'll need to adjust the schedule when you complete these
requests, but remember, it's reasonable to expect fast and furious change in a
small company, and part of your job is to be flexible and accommodating. When your list grows longer (it never seems to grow
shorter), and the requirements for existing projects change, update your
schedule-as time allows. If you are galloping along, trying to produce hundreds
of pages of new copy, you will probably wait until the current project is
completely out of your hands before you update the schedule. Depending on the
size of the company, getting the book out of your hands can mean anything from
simply handing off a disk to tracking the whole publication process. But always find time to update the schedule, so that you
won't be buried by expectations lurking behind someone's seemingly off-hand
request. Although many articles and publications have reviewed
these subjects in some detail, following are a few tips on surviving some of the
unexpected job responsibilities that perhaps shouldn't be so unexpected: · Tracking defects: investigate the tools your company has
for tracking defects. For example, at some companies the software defect
tracking tool includes documentation defects; at other firms, the engineering
change process addresses major documentation problems; in still others the
documentation group (which in some cases may be just you!) may require a
separate tool. Make sure your suggestion fits in with your company's set of
tools. If you are the only writer, you may want to keep the tool very simple,
such as an e-mail folder with one message per error, with specific notation
about defect status. · Assessing the competition's documentation: review any
available competitive product and its documentation. If you don't have the
competition's documentation, ask someone in the marketing department for it.
Even if you only have time to review the competition's books briefly, take it.
This helps make sure your books cover the basics, and helps you design books
that can meet or beat the competition. In a small company, every employee must
keep an eye on the competition. · User testing documentation: test your documentation, in
a "real-world" environment, whenever possible. If you can't complete testing
before a release, make sure the document is reviewed by someone familiar with
the customer and who is technically informed. Find time to complete user testing
at some point, no matter how informally, so that you can incorporate revisions
resulting from the user test in upcoming editions of the document. Especially if
you are coming from a larger corporation with more resources, remember to be
flexible with available resources at a small company, doing what you can when
you can, rather than in the ways you're used to. · Selecting software tools: spend a little time figuring
out what you need before investigating what's available. For example, if you
will be creating materials that you will share with value-added resellers (VARs)
and original equipment manufacturers (OEMs), make sure that the tool you chose
is compatible with their requirements. Software selection is a treacherous area,
and most of us don't have time to do it as well as we'd like. You'll need to
make the best decision you can in the time you have, then go with it. · Working with a graphic illustrator: plan your document
to include as many illustrations as necessary to support the text. Develop the
concept the illustration is to convey and perhaps create a diagram showing the
illustrator what you want. Work closely with the illustrator, taking time to
make clear the style of image you would like. Review initial draft images,
carefully proof final images, and agree on a final format (digital, paper copy,
etc.). Invest a little time as you go so that you'll get what you want. When you
user-test your book, make sure you consider whether the user found the
illustrations helpful, or if they can be improved. · Working with the printers: set aside more time that you
think you'll ever need, and devote it to the publication process. Do not
overlook the importance of this inevitable step in the documentation process, or
risk diminishing the value of your writing effort through poorly produced final
documents. You must take time in the beginning to determine schedules and make
sure the printer has the correct fonts. You'll need to continue to track the
process through blue-lines a final review to make sure your documentation is of
satisfactory quality. Part of the reason working in a small company is exciting
is because of the diversity of responsibilities. You also need to exercise
caution in accepting responsibility, and in tracking the work you accept. By
paying the price of discipline, you'll get the payoff: a variety of interesting
work that you can complete in the time available; a continuing challenge; an
exposure to a range of corporate involvement impossible in a larger company; and
the pleasure of getting the job, which probably isn't in your job description,
done right. (1) Lasecke, Joyce. 1992. "Cost Estimating with Confidence,"
INTERCOM March: 3-4. (2) "Publication Production: An Annotated Bibliography,"
"Index in Computer Documentation," "An Approach to Competitive Assessment,"
"Worth a Thousand Words: Choosing and Using Illustrations for Technical
Communication," Technical Communication 41, First Quarter, 1994. (3) Price, Jonathon, and Henry Korman. 1993. How to
Communicate Technical Information. Redwood City, CA: The Benjamin/Cummings
Publishing Company, Inc. (4) tekom, Gesellschaft fur technicsche Kommunikation e.V.
April 1989; reprinted 1991. "Job Description: Technical Author." Technical
Communication 38, Third Quarter: 356-357. Elizabeth Walker (Smith) has worked as a technical writer for both start-ups and Fortune 500 companies, with a preference for smaller
firms. She has worked as project lead, publications department manager, senior
writer, and marketing writer, and reported to software engineers, documentation
managers, marketing managers and a marketing vice president. She has given
papers at two previous international STC conferences, and has published in
professional literature on topics in technical communication and other
fields. Elizabeth Walker, formerly Elizabeth W. Smith
Copyright © 1997, Society for Technical Communication where the content is
identical to the 44th Annual Conference Proceedings. All other content is the
property of the author.
Too Much to Do
Priorities
Balancing Act
The List and the Schedule
Using the Schedule
Abandoning the Schedule
Updating the Schedule
Tips on Non-writing Projects
Diversity
References
Spectra
Logic Corporation
1700 North 55th Street
Boulder CO 80301
USA
bethw@spectralogic.com