Jim from Iowa writes:

I was doing some career research involving technical writing and stumbled upon your website.  I had a question about that sort of thing, and you seem like a good person to ask. To be frank, I have two main interests–writing and technology.  I love to read and write, but I also love engineering, working with computers, etc.  So, I guess at this point, one would say technical writing is the logical career choice.  Yeah … but I’m not sure if that would satisfy my tech cravings.  I realize you’ve mentioned things along this line in your previous posts.  But let me explain a little further ….

Let’s say I get schooling in engineering and, say, English.  Would I be able to be a technical writer who also had some extra privileges?  And by that I mean helping with the design process, helping with whatever problem is trying to be solved or whatever item is trying to be created, etc.  What do you think?
Thanks,
Jim

Thanks for submitting your question, Jim. I responded in a videocast below.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

I am so glad that I found your blog. I truly need an advice. Initially I got accepted as computer science and business major, however I did not see myself stimulated by it.

So I changed to International Relations and Development studies, something I always wanted to study.

But now, I am faced with few job prospects. Even though I left to work as a reporter in the UAE. I love writing. But it is quite a competitive, still market and I wanted to go back to Canada, one year in the UAE was way too much for me.

Now I want to pursue technical writing as a career. I am motivated, since I am a hybrid between science and arts, and it will enhance my pay.

But I want to be trained as a technical writer, I have about 4 computer science credits, I know rudimentary computer science concepts, though  C ++ is something I can vaguely recall.

I really need your advice on this.

Are there any internships for technical writing positions? What can I do? And what are the computer software programs I need to know?

And I am a fellow blogger as well.

My best regards

Jara, thanks for writing. It’s good that you have skills in both computers and writing. That combination  provides a great foundation for a career in technical writing. You don’t have to be a computer programmer to land a job as a technical writer, unless you plan to write documentation for programmers. However, any programming knowledge comes in handy.

To get training in technical writing, you have several options:

• Land an entry-level job in technical writing and learn the skills you need on the job.
• Earn a degree in technical writing somewhere
• Serve as an intern for a tech pubs department
• Create a portfolio of technical publications samples on your own

Any of these options can work well to move you forward into a career of technical writing. I took the first route: on-the-job-training. I’d been a writing instructor at a university, then a copywriter, and I wanted to move into technical writing. I landed a job as a technical writer at a financial company, and learned their style guide and methods. It was an excellent way to gain experience in technical writing.

Many companies want to hire candidates who already have experience in technical writing. It can seem like a Catch-22: you need experience in technical writing before you can get a job in technical writing; but the only way to get experience in technical writing is to have a job as a technical writer.

Actually, the Catch-22 situation is somewhat of a myth, one that many can’t see past. You most likely learned to write before you landed a job as a reporter. And how did you learn to write? Did the skills come only from on-the-job training? No. Most likely you wrote in your own spare time, developed writing skills, and then submitted some impressive writing samples to an employer, who hired you.

Technical writing can be the same way. If you want to learn technical writing, do technical writing. If you need a project, I recommend writing documentation for WordPress. (If you’re interested in that, I’ll give you more specific suggestions on areas that need better documentation.) Documenting WordPress may not interest you, but there are a hundred other applications you can write help for. Open source apps are the ripest.

As you tackle an actual project, you’ll be faced with stylistic questions. You’ll have to decide how to approach it, the language and format. I recommend that you open a sample how-to guide from some application you’re familiar with (even Microsoft Word), and try to imitate the style. Number the steps. Include screenshots where the steps are confusing. Chunk the material into tasks. See my post on the complexity of simplicity for some standard techniques.

You’ll also need a mentor, someone who can review your content and give you feedback. Here’s where the STC comes in. The Society for Technical Communication (STC) most likely has a chapter in your area. Go to the next local STC meeting or contact the local president. Ask for a mentor to provide feedback on your technical documentation.

In a thriving chapter, many people will be more than willing to volunteer. Take your mentor’s advice and shape your samples into professional-looking work. If you can produce several samples of help material for different projects, that alone may convince a hiring manager that you have experience in technical writing.

One thing I haven’t mentioned is tools. This is where it gets a bit controversial, but I’ll tell you what I use. I author almost everything in Madcap Flare. Using Flare, I generate both webhelp and a Word output, which becomes a printed PDF manual. I mainly use SnagIt to capture screenshots, although sometimes advanced tweaking requires me to use Photoshop. If I plan to make video tutorials, I use Camtasia Studio. Learning at least Flare and SnagIt will take you a long way.

If you know the specific job you want, you can inquire about their toolset. Maybe they’re die-hard RoboHelp users. If so, learn RoboHelp. Maybe they do everything in Microsoft Word. Fine, master styles and templates in Word. Perhaps they’ve moved to DITA. In that case, get to know an XML editor and the DITA Open Toolkit. Or maybe it’s a Framemaker shop. So dig into that.

Some employers require you to know their tool before they’ll consider you. Realize that “knowing” a tool has gradations of interpretation. With some tools, I can say that I “know” them, although I only know them as a novice. With other tools, I’m an expert. There are gradations of ability for every tool, so even if you only figure out Flare enough to create a basic online help file, you can still say that you “know Flare.”

It’s a bit ridiculous for an employer to expect each candidate to have an expert level of knowledge in every tool (e.g., AuthorIt, RoboHelp, Doc to Help, Flare, DITA, Framemaker, Word, Captivate, Camtasia, Photoshop, Dreamweaver, and others). It’s more important that you’re able to learn the tools the company wants you to use. You’d think this characteristic would be a given, but many technical writers get unnerved if forced to learn a new tool.

Readers, if you have advice to add, please do so in the comments below.

For more information on technical writing careers, see this post by John Hewitt on the Technical Writing FAQ.

The work keeps piling up -- who can do it all?

Sebastian asks,

I have been searching the web for information about how to divide workload among writers as the the workload–and the department itself!–grow. I am thrilled to find your blog! I am a new writer in a Health Information Systems doc group. We write for 120 products, maintain 600+ documents (several output formats). Do you know of any effective strategies/tools/medications?

What kind of documents do you produce?

We produce online help, how-to guides, quick reference guides, manager’s guides (procedural content), introductory guides (conceptual content), release notes, configuration guides, known product issues, tutorials….

Do you do translation too?

Translation/localization of deliverables seems to be evolving here. There is an international department who have a couple of writers . . . What happens might be translation but is not certifiable localization.

Any other factors that caused the increased workload?

I think what broke our system was an acquisition that increased department size by about 50%. Our lead writers had been coordinating work across product families, but the definitions of product families have gotten a little too fluid, and the workload has gotten so huge that we can only do part of what’s needed, so there’s now a backlog and it’s growing, and we’ in the midst of this move to AuthorIt, which adds work in itself…. We’d like to know what really big teams do to keep everything coordinated.

Our 50% increase did include some writers, and I know that part of the chaos comes from trying to train people on new products at the same time they’re trying to meet deadlines. But I think if I could condense the problem to a single category, it would be about coordination and communication–knowing what’s going on across that broad range of products, having the workload allocated so that the deadlines are distributed reasonably, that sort of thing.

Did the 50% size growth include an addition of new writers?

I guess I envision that other groups have tools of some kind that automate this kind of tracking, or they have some information-exchange routine, or a set of job assignments that somehow pull all the information together and keep the workload balanced.

I’m using an online project management system for tracking how hours are spent, spreadsheets for trying to balance workload (don’t even ask–corporate decisions prevent us from using a single tool for both types of tracking), lead writers for keeping up on product family information, and all kinds of meetings–methods that worked when there were 12 of us but that don’t seem to work now that there are 18.

Dear Sebastian,

Thanks for writing. I’ll share my thoughts and others can build on them in the comments if they have anything to add.

Get Professional AuthorIt Training. About AuthorIt, one thing I recommend is that you get someone to come in a provide training on it. It can take months before you feel comfortable with a robust product like AuthorIt. When I was in Florida, a colleague at another company was moving to AuthorIt (from RoboHelp). She hired Char James-Tanny (helpstuff.com) to come out and provide 3 days of training. It worked pretty well. I would recommend that training for your company too, unless you already have AuthorIt gurus.

Set Up AuthorIt Templates. I also recommend seting up AuthorIt templates and styles for the entire team to use, or even pay the trainer to come in and set them up. This can reduce the learning curve.

Insert Writers Early On in Software Development. As far as distributing the workload, inserting the writers into the software development process early is always best. That way they can stay in the loop through the entire process and be better aware of changes and other information that affect documentation. It’s the last minute emergency documentation needs that stress writers out. Or being expected to write documentation without complete information and access to the product and SMEs.

Deliver Only What Users Want. You can also survey your users to ensure you’re actually delivering the help content they want. If they only want online help and a short quick reference guide, you might do away with the long printed manual. (See this post for more info.) Of course, if you set up the AuthorIt templates and styles right, single sourcing to print shouldn’t be too arduous.

Provide a Style Guide. Having a simple style guide helps avoid the guesswork of technical writing. When writers know what style is expected, they don’t have to spend time making stylistic decisions. (But don’t go overboard with a 200 page style guide. Keep it short and sweet.)

Lighten the Editorial Process. If you have a tedious editorial process, I’d recommend getting rid of it. At one company I worked, we had an editor that required multiple submissions, requiring at least 3 weeks total for reviews and edits. It slowed the process up a bit (although granted, the quality increased). Short peer edits are more practical in my opinion.

Have the Manager Meet with Each Team Member Weekly. A good manager can help allocate resources well, and make sure each writer has an appropriate amount of work — but only if the manager is in tune with each of his or her team members. One time I had a manager who met with each of us for 30 min. to an hour a week. The outward purpose was to get a report on how we were coming along with our projects. But it transformed into much more than this, as we wandered into tangents and talked about other things. I found this one hour with my manager each week to be the best thing a manager has ever, ever, ever done. Honestly, it built rapport. It let the manager know exactly what the workload was for each of us. It allowed us to communicate any problems we were having, either with access or with reluctant SMEs. No tracking software can replace face-to-face communication.

Market Your Department. If you need more resources, you should let upper management know. If they don’t want to pay for more tech writing resources, then push back on the deliverables, the timeline, or the scope. How are you marketing your dept. to your organization? Consider getting together the key senior leaders for a dog and pony show about the benefits of good documentation.

Publish in a Place You Can Update On-the-Fly. Are you publishing your help on a server separate from the application? When you have control to continue modifying the help once the product is launched, it removes a lot of the burden of a deadline. In my situation, I give the developers a link to the help. The link points to a Flare file that I have hosted on a SharePoint site. It works well because I don’t have to stay up the entire night before a release creating video tutorials. In fact, by release time, I just have to have the basic help content out there. I can continue adding to it after the release date.

Another Perspective: Take Your Time

I don’t know quite how to say this, but good documentation takes time. Rather than always trying to do everything faster, better, with fewer resources in less time and with double the quality, etc., consider that a slower, more labor-of-love-type approach isn’t necessarily a bad thing.

I’m not recommending that you join the Slow Movement, but there’s something to be said for taking your time with a project you’re heart is in.

One of my favorite movies is Brother Sun, Sister Moon. It’s by Franco Zeffirelli and from the hippy-era, and definitely dated and corny, but it gets me every time. Here’s the song I like most.

And a round version.

The key line is this:

If you want your dream to be, take your time go slowly. Do few things but do them well — heart-felt work is holy.

I’m engaged in a lot of activities, and sometimes I see my life getting stretched thinner and thinner. In addition to being a father of 3 young girls, a husband of a voracious blogger, young men’s president in my branch, I also post regularly on my blog, publish a podcast, coordinate a social news site, and occasionally I teach courses on WordPress and do freelance web copy/design. I also love to play basketball, go on Saturday outings with my family, and read nonfiction tech content. This past week, I said to myself, Tom, focus on what you really want, and simplify your life, because you’re not doing any of these activities particularly well.

I think the same can be said for documentation. Focus on what really matters — the application that’s going out to 20,000 users, or the one designed for the highest-paying customers, or the application that generates the most calls to the support center. Give that your highest priority by doing it first. Then work on the less important tasks. (It’s the Stephen Covey big-rocks-small-rocks principle.)

The other stuff will get written eventually. The world won’t stop. This is the one comfort to being a tech writer: while your work is valuable and incredibly important, no one is going to delay the product launch if you aren’t ready.

Dear Mr. Tom Johnson,

I am a Post Graduate in English. Recently I am working in a leading public house as writer. How can I become a successful TECHNICAL WRITER?

Please reply me as soon as possible.

K.

Dear K,

The best thing you can do to develop your skills and ability with technical writing is to actually do some technical writing. Find an open source project, such as WordPress.org or Pligg, and write some documentation for it. Most open source projects have poor documentation, so they provide excellent opportunities.

When you finish your user guide or online help, ask someone on a technical writing listserv (like TECHWR-L) to review it. Someone will probably give you excellent feedback. Make a few updates, polish it up, and use it as the technical writing sample in your portfolio. Nothing gets you more familiar with technical writing than actually doing technical writing.

Tom