If you are a technical writer...

[quark]

I'd love pointers on how to break into the industry. Although I have written professionally for many years, my experience is in a different industry and I am thinking about taking professional certification courses to learn the specifics of technical writing.

 

Is an STC (Society for Technical Communication) membership necessary for increased chance of job offers? Should I be already very well versed in various product software etc before I begin?

 

Thanks in advance for your suggestions/ advice!

[Melinda in VT]

I don't think an STC membership is necessary, although it certainly wouldn't hurt.

 

I would say one thing you definitely need is a couple of good technical writing samples. My technical writing background is all in the software industry, and if you are interested in that area, I'd suggest getting involved with an open source project and offering to contribute to the documentation. Everyone I talk to seems to agree that OpenOffice could really use some help. :D

 

As for tools, it's going to vary. I would say becoming comfortable with DITA and at least one DITA editor would be the most useful, but I'm curious to hear what others say. It's been 14 years since I looked for a job, and the positions I've interviewed others for in recent years have been new college hires or internal hires (so, already familiar with our tools).

 

Good luck!

[3 ladybugs]

My hubby is in medical communications (technical writing).

 

Figuring out what kind of technical writing you would want to do is the first step. The associations help, but your ability to pass their tests (every agency has them) promptly and accurately is more important.

 

I have never heard of the organization you mentioned, but honestly I am not in that field. I know hubby has a certificate from American Medical Writers Association or something like that. However he also has his PhD in a related field too.

[kbutton]

I don't think an STC membership is necessary, although it certainly wouldn't hurt.

 

I would say one thing you definitely need is a couple of good technical writing samples. My technical writing background is all in the software industry, and if you are interested in that area, I'd suggest getting involved with an open source project and offering to contribute to the documentation. Everyone I talk to seems to agree that OpenOffice could really use some help. :D

 

As for tools, it's going to vary. I would say becoming comfortable with DITA and at least one DITA editor would be the most useful, but I'm curious to hear what others say. It's been 14 years since I looked for a job, and the positions I've interviewed others for in recent years have been new college hires or internal hires (so, already familiar with our tools).

 

Good luck!

 

I agree.

 

Some of your approach will vary if you want to work for one company vs. freelance. If you want to freelance, I think you'd want to use STC or another organization as a place to network in the beginning.

 

If you don't need to quit a full-time job in order to do it, consider working up some samples and pitching yourself as an intern. Don't worry about a prestigious internship, but do try to find one where the person you work for would help you network and give you real jobs to do (not filing all day). It should be a paid internship.

 

These jobs and roles vary with the size of a company (or variety in their product line) and how standardized they make their documentation. Some tech writers are in their own universe behind the scenes, but some are the full documentation shop by themselves (they actively plan out projects, pitch their delivery method to the product folks, work with vendors, potentially write marketing material). Some work on interdepartmental teams where they offer feedback to the developers or work closely with them for source material. If you work someplace that develops point and click help, that is very different from a place where the writers develop all documentation (potentially about a non-software product or about a process) and then do stand-up training (sometimes around the country or around the world at client sites). It's also different from a job where the documentation is for an end-user that is in a highly technical job rather than a home software user. 

 

I worked in a couple of different companies. The job that I liked the most was in a company whose customers did technical work (database administration and such). We had a tech writing department, but each writer worked on a product team as well. Our writing department made major decisions about the types of documentation we produced, and we educated each other about new tools and departmental procedures, style guides, and things like that. On the product team, we received or solicited information from the developers, QA, and tech support areas, and then they reviewed our documentation.

 

In that kind of environment, I prefer to work with people who can think through a process and break it into pieces, not only to explain it to another person but also to work steadily toward a complete project purposefully and systematically (the opposite of a last-minute paper due at the end of a semester). They can usually identify trouble spots as they appear and correct course because of this. Being able to persuade someone that something needs to be done differently or a specific way using factual information is a handy skill. It helps to be able to establish efficient ways to do things since it's possible that you'll be handling incredibly large amounts of information or many separate files/pages. That information might be flowing in and then back out of your realm of responsibility throughout a project. You'll have to be able to track changes in the decision process if you work on a team--sometimes the "why" of a decision comes back around, and if people don't take that into account, they can spend a lot of time rehashing things that don't need to be negotiated yet again (though some places have project managers for this). I think it's also important to be able to pass information back and forth with another writer without the material you produce being disjointed because more than one person handled it. It's always good to be able to give and received feedback constructively and actively; I don't mean having a thick skin (though that can help), but to be able to ask the right questions and to recognize when you are getting the right answers. It's easy to ask questions, get answers, and document something that doesn't actually work that way, lol! (And boy, it's fun when you've inherited a project where that happened, and you have to clean it up.) Knowing how much to do without doing too much is important when deadlines come around. Excellent troubleshooting skills and the ability to think out of the box are helpful.

 

I think these skills are not necessarily things you'll be asked in a job interview, but they should be. They do transfer from other fields, and if you have the ability to do these things, you should try to showcase that somehow. The samples and the ability to use a tool are what you need to know to get the "technical writer" badge, and you don't want to neglect them, but the other skills are what will people will remember if you need to move from one project to another or one job to another (IME). If you want to get into something specialized, like grant writing, you should concentrate your classes and self-education in those directions. 

 

I haven't worked for hire in a while, but it's not uncommon for people to find their way into tech writing from other fields. You are in good company in that regard.

[kbutton]

My hubby is in medical communications (technical writing).

 

Figuring out what kind of technical writing you would want to do is the first step. The associations help, but your ability to pass their tests (every agency has them) promptly and accurately is more important.

 

I have never heard of the organization you mentioned, but honestly I am not in that field. I know hubby has a certificate from American Medical Writers Association or something like that. However he also has his PhD in a related field too.

 

I think medical and scientific fields usually require a degree in that field above and beyond the technical writing aspect. Perhaps the tests were developed to give people outside the field the ability to move into it, but from what I've seen, a degree in a related area seems necessary. 

[kbutton]

Oh, when you make samples, take notes for yourself so that you remember later what you chose to do and why you chose to present things that way. Write down what tools you used, what challenges you faced, and what you learned from the process. There is nothing more annoying than to look at a sample out of context, ask the writer questions about it, and find out that they can't remember or tell you anything they did. I had that happen when I was interviewing my replacement once (quit to stay home with the kids), and I was terribly unimpressed.

[quark]

Thanks so much for your replies. Sorry it took me a while to get back to you!