What does a tech writer actually do?

If you're thinking about becoming a technical writer, you probably expect the job to be about writing. After all, the job title has "writer" in it, right? And it is, partly. You need to write well, and you'll do plenty of it. But most of the job happens before you write anything, and that's the part people don't tell you about.

A while back I wrote about why companies should hire a tech writer. This post is for the other side of the table: you, wondering what you'd actually spend your days doing. I'll go through the main parts of the job here.

You'll never stop learning

To do well as a technical writer, you need to be willing to keep learning, and comfortable with it. Sooner or later you'll be asked to document something you know nothing about, so you'll have to study: the product, its features, the technology underneath it. For example, I knew a bit about networking, but when I took ownership of the enterprise networking products at my last company, I had to learn fast and pick up a lot of esoteric concepts that weren't in my vocabulary.

You'll also have to learn who knows what. Product managers can tell you why a feature exists and engineers how it works, but it's often support who knows where customers actually get stuck. You don't need to figure it all out by yourself, and you shouldn't try. If you're the only writer in the company, those people are your best source, so lean on them.

Know who you're writing for

The other thing to learn is who your readers are. That decides how you write and which words you can use without explaining them. Someone who has never written code will get lost if you talk about variables without saying what one is. If your instructions are dense and your readers have no idea what you're talking about, your documentation isn't doing its job.

However, I'd argue clarity matters even when you're writing for an experienced, tech-savvy audience. That can take many forms, but a good start is briefly explaining concepts, even the ones that feel obvious to you.

Once you've researched your audience, turn what you found into personas: short profiles of the typical people reading your docs, what they're trying to do, and what they already know. With those in front of you, it's much easier to decide what each page needs and what language to use.

Follow the user journey

It's really useful (I'd argue it's required) to know how your customers use the product. It shows you what the documentation needs to look like and what will actually help someone succeed, whether that's installing, configuring or using the product.

A user journey is the path someone takes through your product: installing it, setting it up, then using it day to day. If you know that path, you know what the reader needs and when, and that tells you how to structure your docs. It makes no sense to explain advanced features before you've walked your reader through the basic setup, right?

The journey also starts before installation, and carries on after it. Someone still deciding whether to buy might read your docs to check the product does what they need. A happy customer might send a colleague the page that solved their problem. Knowing where each kind of reader comes in helps you build a mental map of where each piece of information should live.

Get a style guide

A style guide makes your documentation read like one voice instead of many people writing in different styles. It also settles the small questions, like what to call the product or whether to spell out an acronym the first time it appears (spoiler alert: you should). Without one, every page feels a little different, and customers may come away thinking the product lacks polish.

If you don't have a style guide, create one. You don't have to start from scratch: there are plenty of public ones to borrow from or adopt outright, like Google's developer documentation style guide or the Microsoft Writing Style Guide. Before you pick one, though, decide on your voice. Are your pages serious and businesslike, or more relaxed and friendly? The answer depends on who you're writing for, which takes you back to your personas.

Wrapping up

If you came to technical writing expecting a job about writing, all of this might sound like a lot.

If there's one thing I think you should take from this post, it's this: learn from the people who are actually the experts. Your job is not to know everything. Your job is to translate jargon into something customers can lean on to be successful at installing, setting up and using a product.

So talk to those experts, and don't be afraid to ask questions, even the ones that seem obvious. Act like you're the first user. Every question you get answered is one your reader won't have to ask.

The writing comes last, and how good it is depends on everything you did before it.