Technical Writing World
The social network for technical communicators
What should a Technical Writer training programme incude?
Hello,
It's been a while but I'm back with another question.
I've been delegated the task of helping the HR dept setup/ revamp the Training Programme for Technical writers joining my company.
I'd like to know what you think should be part of the programme. I work for a documentation company where 70% of the staff are Technical writers. Each Tech Writer comes with different levels and areas of expertise.
We've been thinking of creating four different programmes that will vary depending on the level of expertise.This will be part of the induction programme so would not be more than 15 days to 1 month.
Would love to hear your ideas.
Replies to This Discussion
-
Permalink Reply by Milan Davidović on -
Are you doing a needs analysis in your organization?
-
Permalink Reply by Melissa Dhillon on -
Hi Milan,
We haven't started with a need analysis yet though I think the HR did conduct a gap analysis some time ago.
What was the process of the TW training programme in your organization? Were there any bits that stuck that you felt were helpful when you began working?
-
Permalink Reply by Milan Davidović on
-
Nothing focused on what we might think of as "standard" technical writing skills; everything is to do with the business and regulatory requirements.
-
Permalink Reply by Mark Baker on -
The one thing that every new tech writer needs to learn, because it is completely counter to everything they have been taught, is that while the job of an ordinary writer is to capture and hold the reader's attention (and thus their success is measured by how long the reader keeps reading), the job of a tech writer is to answer the reader's question and get them back to work as soon as possible (and thus their success is measured by how short a time the reader keeps reading).
If you can get that idea into their heads in less than a month, you will be doing well. I suggest (with utter seriousness) that you start by showing them videos of races and focus on the work of the pit crews. Tell them, that's your job: service the reader as fast as possible and get them back in the race.
-
Permalink Reply by Melissa Dhillon on
-
Hi Mark,
Thank you for your response. As always you've provided me with a fresh insight on things.
I'm not sure how things work in other parts of the world but in India there is no formal training for a Technical Writer. In fact most Tech Writers I know come from an engineering or programming background. Most of the time we take in graduates who have no idea what Tech Writing is. Why I'm talking about this is because most writers here are not taught anything. They have no expectation from the job because they don't know what it involves. For most It's just a 'Technical' job that allows them to enter a domain that they may be interested in. Or it's something they take up till they get something better.
Taking on newbies works for us because we teach them immediately to give correct concise information to the reader. They get to learn the right way of doing things as opposed to how its theoretically supposed to be done.
Are there any training programmes that you found interesting or helpful?
-
Permalink Reply by Chris Heath on -
I agree with Mark.
Mitigating user downtime is what it's all about.
Readers should be able to find the information they are looking for with minimal page turns or mouse clicks. When the relevant information has been found, it should tell readers exactly what they need to know, in order to resolve the problems they have.
In a nutshell, it's up to us as technical writers to do all the hard work, so that the readers of our documents have an easy time resolving the issues they face. This way, they can get back to being productive in the shortest possible time.
Great analogy Mark! I never thought of a document as being the equivalent of a pit crew.
-
Permalink Reply by Chris Heath on
-
Hi Melissa
I don't know if you develop a publications style guide for each project, but if you do, you can provide your more experienced new writers with the style guide and some of the project's documents, as well as access to the system, e.g. test environment.
Getting new writers to review both the documents and style guide, along with the system that is being documented, is a useful way of getting a writer up to speed with all aspects of the job in a relatively short period time — with only minimal impact on your time.
When working through this review process, the new writers:
- should write down all their questions (about the system, documentation and writing standards), most of which they will answer for themselves along the way.
- edit the documents against the style guide, and suggest corrections/changes to the documents, and
- suggest and make agreed updates to the style guide.
This takes the pressure off you and places the learning experience firmly in the hands of the new writers. It also gets the new writers up to speed with existing standards and the system they will be working on. Sometimes, their suggestions result in improved standards. The wonderful thing is that you end up with a team who work collaboratively to resolve style issues and to maintain standards across the board, as well being able to peer review / edit each others work in a non-threatening manner.
As mentioned earlier, this works well with writers who have some writing experience. I'm not sure how well it would work with people who have no writing experience. I have employed this process a number of times when hiring technical writers (one was actually a journalist; not a technical writer), and it hasn't failed me yet
© 2012 Created by Arnold Burian.
