In the sprit of Halloween, the following is a "scary" excerpt from an article entitled "True IT Confessions" by Chad Dickerson, appearing in the September 29 edition of InfoWorld magazine, sent in by Toronto STC member Dorothy Birtalan:
"...the dirty little secrets of your IT department generally remain hidden from view - but, oh, they can be ugly…One problem is simple: documentation, which sometimes hides the ugliness from the IT department itself…most developers and systems administrators finish a project and quickly put it to bed, sometimes without any documentation. Many times, I have scanned a particular system's documentation during a crisis only to find that it had not been updated in several months (or even years). Small and undocumented changes can add up to large, undocumented messes…"
You can read the complete article here.
This quote reflects an unfortunate fact to be aware of during an interview: that documentation is often a neglected area within a company. During an interview, you should try to assess the state of the documentation department by asking questions such as:
In doing so, you will find that all companies fall somewhere into the "Documentation Relevance Spectrum", which can be represented as:
Importance of Documentation Process
<------------------------------------------------------->
(Less) (More)
At the far left edge of the spectrum, documentation is not considered very important, minimal resources and attention are given to it, and technical communicators are given little input, if any, into the development process.
At the other end, documentation is considered critical; full resources and attention are given to it, and technical communicators are given extensive input into the development process. They may even be asked to give feedback on product design and usability, review error messages, test the product and report bugs.
During an interview you need to determine where the company falls on this spectrum. Most will be somewhere in the middle, but you may find some closer to one end or the other. Obviously, most of us want to be at places nearer the "right" edge of the spectrum, but a few may not. Some people actually thrive in a high pressure environment and seek the challenge of improving existing processes.
However, even at companies where documentation is highly valued, never forget it is still one among many departments that must compete for limited resources and attention. Often technical communicators fall into the trap of viewing the work required to create a product as simply:
1. Documentation
2. Everything else
As a result, we often complain that we do not get the respect and attention we deserve. While there is some truth to this, it's important to see things from the perspective of the product manager or project team lead - this person may even be the one interviewing you! For them, documentation is one of many areas required to complete a project, so they will view the development process as:
In the next issue, I'll begin discussing some of the specific questions you may be asked, and the effective responses to them.
"...the dirty little secrets of your IT department generally remain hidden from view - but, oh, they can be ugly…One problem is simple: documentation, which sometimes hides the ugliness from the IT department itself…most developers and systems administrators finish a project and quickly put it to bed, sometimes without any documentation. Many times, I have scanned a particular system's documentation during a crisis only to find that it had not been updated in several months (or even years). Small and undocumented changes can add up to large, undocumented messes…"
You can read the complete article here.
This quote reflects an unfortunate fact to be aware of during an interview: that documentation is often a neglected area within a company. During an interview, you should try to assess the state of the documentation department by asking questions such as:
- How often do you update your documentation projects?
- Do you view documentation as part of the development process?
- Do you build review times into the development schedules?
- Will I have access to the product to be documented?
- Will I be included in product development and bug review meetings?
- Are reviewers held accountable to the accuracy of the documentation they review, and the dates by which the reviews must completed?
- Do you work well under pressure?
- How do you handle multiple projects?
- How do you ensure others review their drafts on time?
In doing so, you will find that all companies fall somewhere into the "Documentation Relevance Spectrum", which can be represented as:
Importance of Documentation Process
<------------------------------------------------------->
(Less) (More)
At the far left edge of the spectrum, documentation is not considered very important, minimal resources and attention are given to it, and technical communicators are given little input, if any, into the development process.
At the other end, documentation is considered critical; full resources and attention are given to it, and technical communicators are given extensive input into the development process. They may even be asked to give feedback on product design and usability, review error messages, test the product and report bugs.
During an interview you need to determine where the company falls on this spectrum. Most will be somewhere in the middle, but you may find some closer to one end or the other. Obviously, most of us want to be at places nearer the "right" edge of the spectrum, but a few may not. Some people actually thrive in a high pressure environment and seek the challenge of improving existing processes.
However, even at companies where documentation is highly valued, never forget it is still one among many departments that must compete for limited resources and attention. Often technical communicators fall into the trap of viewing the work required to create a product as simply:
1. Documentation
2. Everything else
As a result, we often complain that we do not get the respect and attention we deserve. While there is some truth to this, it's important to see things from the perspective of the product manager or project team lead - this person may even be the one interviewing you! For them, documentation is one of many areas required to complete a project, so they will view the development process as:
- Research
- Prototyping
- Business analysis
- Usability
- Development
- Documentation
- Quality assurance
- Performance testing
- Training
- Sales
- Support
- Customer relations
- Marketing
In the next issue, I'll begin discussing some of the specific questions you may be asked, and the effective responses to them.
