More than Writing Documents – Tell Your Story

software-development-life-cycle
The Software Development Cycle Involves Many Different Phases and Types of Expertise; Every Phase Requires Documentation (MRDs, Architecture Specs, UI Design, ATPs, Test Reports, etc.) – So Why Do Most Tech Writers Only Get Involved in Phase 6 – User Guides ?

 One of our observations is that technical writers who do really well in their organizations actually contribute to and become experts (or partial experts) in some areas beyond the scope of their core job definition as tech writer. This may be by getting involved in any of these areas: UI design, marketing writing, product definition, customer/staff training, QA, process engineering, etc.

At the next ITTT meeting we will discuss this phenomenon in depth.

In the meantime, in order to get our juices flowing, we are inviting each of you to write a paragraph or two about your experience.
hats
If you prefer a little structure you can use these questions as guidelines.
  1. When did you or do you go beyond the confines of the tech-writer role and wear another hat at your company?
  2. What hat is it?
  3. How did this come about?
  4. When/how often does this ocurr?
  5. How does this affect your work – from your perspective?
  6. How does this affect your colleagues’/managers’ perception of you?
  7. Do you think that overall this phenomenon (of TWs branching out) is good for the technical-writing field or not?

3 thoughts on “More than Writing Documents – Tell Your Story

  1. Do you think that overall this phenomenon (of TWs branching out) is good for the technical-writing field or not?
    Well, there certainly are a lot of “hats” we’ve taken on, and I get the impression that many of the key players are very appreciative of TW contributions to areas such as UI improvement and training. From that perspective it’s good, and I think those areas in particular are “synergistic” with our core responsibilities. The catch is the other question:.How does this affect your work? The simple answer is, it adds work while not reducing the documentation-specific workload. So it may actually affect our capacity to provide the quality documentation that we’re expected to produce in the required timeframe when we’re also doing other tasks that, over time, actually become integral to our jobs.
    While in general it’s a positive phenomenon and makes us more valuable, to make it workable and sustainable, these other “hats” need to be expressly defined and recognized, and the schedules/quality level of all the roles we fill need to be evaluated accordingly.

    Like

  2. During my first internship, at Kryon Systems, I started in QA, which my managers considered to be a good basis for technical writing. They felt that the best way for me to learn the system I would be documenting would be to test it out, and in the process I would report any bugs I discovered. These skills have served me well throughout my career.
    In my current position at Galor, I am on the product team. I help with UI design, product definition, and QA. These are all offshoots of my primary responsibility, which is to document the new system features which are released with each version update every 3-4 weeks. I have a symbiotic relation with most of the teams in my company. I study the new features as they are being designed and tested, and offer my feedback. This often results, in the product managers, software designers, and QA consulting me while they are writing the design specifications and testing out the new features. My feedback is valued, and my work colleagues and managers consider me to be a system expert. Overall, I think branching out is important. Technical writers gain valuable new perspectives, increase their knowledge of the product they document, and also influence its design, all of which allow them to demonstrate their added value to the company.

    Like

  3. A quick how-to to the eager writer:
    1. Go over the GUI, point at errors (typos, cumbersome text, etc.) and ask to review the GUI text during the development phase.
    2. Repeat step 1 for command-line interface and API
    3. Suggest to add a quick-start (or even a full scale how-to) wherever you find appropriate
    4. Repeat, and repeat and repeat

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s