The Skills You Actually Need To Become A Technical Writer

You are about to find out why your Aunt Linda cannot do this job, even though she writes "very nice messages"

In line with The Inside Job’s mission to open the doors of the club (if you're new here, see Article 1, Section 1, last 2 paragraphs of this column), we'll be breaking down the skills you actually need to become a Technical Writer.

Day-to-day Of A Technical Writer

If you want to know what technical writers actually do, don't (only) look at the job description.

• Look at Monday morning at 9 a.m. 

• Their product meeting notes are so detailed they could document a decision by the engineering team that will confuse exactly 47,000 users by Friday. 

• Look at the moment they realise this has already happened and has been live for three months.

• Look at when they're on their fifth rewrite of step 6 because version four confused a user, who abandoned the product at 1:47 pm and told everyone on X that the app is useless.

• Also look at the afternoon they have to tell a colleague their “finished” six-hour work calls the same element "home screen”, "dashboard”, and "where everything is" across three files.

• And lastly (but definitely not leastly), look at when they realize a tiny engineering change just broke half their documentation and updating them will take longer than the change itself.

This is a Monday. On Tuesday you might do something completely different for a product you've never seen before.

The Skills You Actually Need (And Yes, We Have To Be Specific)

The role demands a genuinely unusual combination of skills, which is partly why it's so frequently misunderstood and why finding a good one is harder than most organisations expect.

The Must-haves

First: Writing ability is necessary and insufficient.

Many genuinely good writers are absolutely terrible technical writers. They think like poets when the job requires thinking like a translator. They reach for the elegant sentence when the reader just needs the clear one. Technical writing has an ascetic quality — its beauty lives entirely in precision, not flourish.

For people trained in creative writing, this requires unlearning core things you were praised for. For example, your secondary school English teacher told you to "show, don't tell." A technical writer tells. They say: "Click the Settings button in the top right corner." Not: "Navigate to the location where your preferences live, hidden away like a secret your app is keeping."

A sentence that's accurate, concise, and scannable is worth more than a sentence that makes your internal editor feel warm inside. If your editor is feeling warm about your technical writing, you've probably made a mistake. Your aunt Linda, who writes very nice messages, cannot do this job. Neither can you, actually, if you're waiting to feel inspired.

Second: The ability to simplify complexity without distorting it.

There are two ways to fail. 

The first: write something so dense that readers can't follow it and you create a confidence destroyer. Example, they get to step three, realise they have no idea what "configure the webhook parameters" means, then close the app. They tell their friend the product is hard. Their friend tells two people. Those two tell two other people, and so on and so forth. You've just cost your company users through documentation.

The second failure is sneakier. You simplify so aggressively you strip out information that matters, leaving readers with a confident misunderstanding. "Click the button" is clear, but if there are three buttons, they'll click the wrong one confidently and blame the product. That's worse.

Good technical writers find the impossible middle ground. They translate without lying. Think of it like translating English to Pidgin — you're preserving meaning while changing form. "I am going to the market" becomes "I dey go market." Same meaning, different shape. But if you translate it as "I dey market" (which is simpler), someone thinks you're already there. That's a different kind of wrong.

Third: Attention to detail and empathy for the reader.

These two travel together. Attention to detail catches when you called the same button "the dashboard" in one place and "the home screen" in another. Most people won't notice. Some will think they're different things and email support asking where the "home screen" is. You've wasted someone's time through imprecision.

Empathy is what makes you ask: does someone encountering this product for the first time actually understand this? You've been working with it for six months. They've been using it for thirty seconds. They know nothing. Your job is making them unconfused.

You write: "Go to settings and update your API key." You think this is simple. The reader thinks: What's settings? Is it a button? What's an API key? Why update it? Your one sentence created four confusions. Better: "Open Settings (top right corner). Find 'API Key' — the code letting your app talk to other services. Click 'Update,' paste your new code, save. Two minutes."

Fourth: Research skills.

You'll be handed products you've never seen and asked to produce documentation a subject-matter expert could approve. You need to interview engineers without revealing your confusion while asking specific enough questions that they actually answer properly.

In Nigeria, research means understanding actual infrastructure. Most people use 2G or 3G, not 4G. Data is expensive. Power cuts at 6 p.m. A tutorial assuming constant internet is useless here. You have to know this.

Fifth: Information architecture.

This separates good technical writers from ones people abandon. It's organising knowledge in the order readers need it, not the order it exists in reality. A beginner needs context. An experienced user needs search. Knowing when a numbered list beats a paragraph. Knowing a warning goes before a step, not after.

This is the difference between documentation people use and documentation people abandon.

A Strong Advantage aka “Nice-to-have” Skill

Sixth: Technical literacy

You don't need to be a developer to document software. Many excellent technical writers aren't. But you do need to understand enough to ask intelligent questions, to recognise when something doesn't make sense, and to follow a technical concept through to its implications.

The writer who can't read a diagram will struggle. The writer who doesn't know what an API is will struggle harder. The writer who thinks "authentication" and "authorisation" are the same thing will struggle the hardest, and will definitely create documentation that's subtly wrong in ways that matter.

Your aunt Linda still probably can't do it though. Sorry, Auntie.

Challenge Of The Week:

Your challenge, should you choose to accept it (and honestly you should), is this:

1. Look at a tool or app (it can be your favourite or a completely new one).

2. Create a technical document on how to use the tool or a specific feature in the tool. Use the skills listed here to guide you.

3. Compare your document with the existing document for that tool and see how well you did.
   

Now you have yourself a project you can add to your portfolio.