Craig Haiss from HelpScribe published an article yesterday where 11 of the top tech comm bloggers were asked to provide advice to newbie technical writers. I was out of town last week and missed his message, so I missed my opportunity to contribute, so I decided to do it here.
My advice to new technical writers falls into the following three general categories:
- Tools and Technology
- Skill Development
Tools and Technology
The broader your exposure to technology and the broader your experience using tools of the trade, the better your chances are at getting hired (and being productive once you get hired.)
If you want to learn a tool you don’t know, download a trial version and go through the getting started documentation to figure out how the tools works and what it can do. Use some dummy content to create a sample project (which you can re-use from tool to tool). Then when you are looking for a job, you have real-world experience to show when a specific tool is required. Most tools have an active user base that participate in some type of community. Find that community for the tool you want to learn, and ask questions and learn as much you can about the tool. A lot of what you will learn will be transferable, even if you don’t end up using that specific tool. (For example, if you are learning about topic-based help authoring, you will be able to use that skill in several different help authoring tools. If you learn about content reuse tools in a specific HAT, chances are there will be a similar concept in a different tool, even if it is named or accessed in a different way.
A big part of a software technical writer’s job is working with technology to discover how it works and to document that for some user base. If you are uncomfortable taking a new technology out for a test drive, then tech writing might not be a good fit for you.
As in many job fields, it’s all about who you know. After my first job out of college, every other job offer has come about directly or indirectly through networking contacts I’ve had. There are lots of ways to develop your network. Start a blog and start commenting on other’s blogs with a link back to your site. Get a twitter account and tweet relevant information using standard tech comm hash tags (like #techcomm, for one example). That will help other people see your name, see your site, and possibly develop an online friendship or professional relationship with people.
I met Tom Johnson (from I’d Rather be Writing and Tech Writer Voices podcast) through our blogs. When he got ready to move to the state I live in, we wrote back and forth about issues related to that. Later, Tom had me meet him in person and we recorded a podcast regarding MadCap Flare V4. A year or so later, Tom had an opening in his organization and invited me to apply for the position, which I did. Now Tom and I are co-workers, and I had a career-advancing move that started because of an online connection I made a couple of years before.
Use the social networking tools available today to begin a network and to expand that network. If you are able to join STC, join a chapter and attend chapter meetings. Participate in STC SIG discussion groups. Gradually you’ll build a name for yourself and people will start to respect your areas of expertise.
This tip is related to the first one, but in this section I want to specifically talk about honing your writing skills, as opposed to the technology skills we talked about earlier.
You are (or are trying to be) a professional writer. You have a responsibility to yourself, your [future] employer, and to the profession to be a good technical communicator. You hone your writing skill by [wait for it…] WRITING. That is probably one reason why Tom Johnson (over on the HelpScribe post referenced at the beginning of this post) recommended starting a blog. On my team of five writers, at least three of them do creative writing on the side, for fun. Whatever form works for you, write. Then write again. Then write some more.
Go back to work later and look at it with a critical eye. Send your work to others you respect and ask for advice and critical analysis. D0n’t be offended when people hash up your work and want to make lots of changes to it. It’s not personal. It is work, and like you, the people you are working with are trying to help collaborate to make the best possible product.
Let me give you an example. Recently I had the opportunity to write an advertising spot script to promote a new tool that was going to be released to 30,000 customers world-wide. I wrote the first draft of the script. Over the course of several days, we met in a committee and much of what I wrote was debated and changed. If I were to focus on what everybody changed, I’d probably be pretty disappointed with the result. After all, I’m the professional writer, and “they” didn’t leave my work untouched. But that’s not how I look at it. I see the final script, and what I see is the overarching structure that I created. The original vision that I had heavily influenced the direction of the entire project, and the final product is as good as it is because I got to take part in developing it. The changes that people suggested, by-and-large, were good suggestions. They made the script stronger and tighter. I’m glad we got to work on it as a committee, because it helped me improve my writing, and it helped our customer get the best product that we could produce as a team.
If you are looking to get started in technical communication, let me welcome you to the group. We’re glad to have you. I hope that as you hone your technical and writing skills, and as you network with people in the field you will find that tech comm can be a very satisfying career. Getting started may seem daunting, but you can rely on your network to help you through, because the community wants to see you–and by extension the field of tech comm–be successful.