Do you need a technical background to be a technical writer? No, but in certain parts of the industry it can help. And just to confuse matters, being an expert in a subject can actually make your documentation worse.
In this post, I'll look at the pros and cons of having a technical background. I'll also explain how you can create effective content without being a tech expert.
Links to each section:
It's different for copywriters
Laying my cards on the table ...
I think it's only fair to point out that I don't have a technical background myself. I wasn't one of those kids who was into programming computers or messing about with electronics kits. Far from it. But I've managed to do well in the technical writing profession both as an employee and as a freelancer. And although I have a degree in technical communication, the course was more about information design than anything 'technical'.
Pros of a technical background
Imagine you run a technical company, let's say you produce software that monitors weather conditions and it is used in several different industries. You need documentation for your end-users, so you're going to hire a technical writer.By some minor miracle, you find a technical writer who has excellent knowledge of all the industries you work with. She also has lots of experience with software and can code a bit too. Â What a find!This technical writer (let's call her Sue), is going to be able to:
Write accurate content without having to disturb your software developers
Write about using the software in the different industries without disturbing your customer-facing staff
Write content for experts with ease
Document code for developers
Produce content quickly.
Sounds good, right?The problem is that Sue is a work of fiction. You're unlikely to find someone who is an expert in all of those areas. What's more likely is that you will find someone who has strong technical expertise in software or in one specific industry. So they will be able to pick up parts of what you do very quickly, but it's likely that they will still need to research other areas and ask your team for answers.And there's another problem too ... the curse of knowledge.
The curse of knowledge
look at the wiki page), but it's the idea that the more you know about a subject, the further away you are from the novice's perspective.Now I'm going to ask you a question.If you had primary school kids and had a choice of them being taught maths by a school teacher or a maths professor, who would you choose?A software developer asked me that question and he was surprised when I chose the school teacher. His thinking was the maths professor would be far more knowledgeable and therefore able to give my imaginary kids a better education. My thinking is that the maths professor is used to teaching a more advanced-level student, so is likely to pitch the learning at the wrong level for the children. That's where you can get a breakdown in the learning experience.Have a think about it. Have you ever read technical information that goes above your head? Or spoken to an expert who answers in jargon that leaves you flummoxed? That is a problem that occurs more often when it is written by experts for people who are novices. It's caused by the curse of knowledge - they make assumptions and miss out important context because to them, it is obvious.Is it possible to get experts who are immune to the curse of knowledge? Yes, absolutely. But having the ability to think like an expert while also being able to think like a novice is rare. And you are asking for technical writing expertise as well!In the argument about tech backgrounds v generalists, you'll often see: "How can you explain something if you're not an expert in it?" It's a valid point. To explain a technical product or any sort of complex information to someone else, you really do need to understand it in-depth yourself. But here's the thing. That doesn't mean you need to understand every part of a product inside-out before you start writing. The best technical writing tends to be task-focused (or user-centred) and breaks down the information into topics. Each topic typically explains either:
how to achieve one specific goal
a single concept.
So the technical writer only needs to be an expert on that specific topic. Not all topics at once. And the only need to be an expert at the time that they write it.I'll give you an example. Some years ago, I was asked to write a manual for a pelvic muscle stimulation device that was aimed at women. It helped treat problems such as muscle weakness after childbirth, prolapsed bladders, incontinence, etc. Clearly, I wasn't an expert in any of these conditions, but I was still able to produce good, useful content. Because I knew what condition the end-user had, knew what they wanted to achieve, and so all I had to find out was how to use the device for each condition. I didn't need to know about every condition at once, I could just focus on one, document it and move on to the next. The same approach works for more complex products too (I've used the same approach to industrial and financial software).
Have you ever read technical information that goes above your head? Or spoken to an expert who answers in jargon that leaves you flummoxed? That jargon-riddled info is a problem that occurs more often when it is written by experts for people who are novices. It's caused by 'the curse of knowledge'
I won't bore the arse off you going into detail about the curse of knowledge (just look at the wiki page), but it's the idea that the more you know about a subject, the further away you are from the novice's perspective.
Now I'm going to ask you a question.
If you had primary school kids and had a choice of them being taught maths by a school teacher or a maths professor, who would you choose?
A software developer asked me that question and he was surprised when I chose the school teacher. His thinking was the maths professor would be far more knowledgeable and therefore able to give my imaginary kids a better education. My thinking is that the maths professor is used to teaching a more advanced-level student, so is likely to pitch the learning at the wrong level for the children. That's where you can get a breakdown in the learning experience.
Have a think about it. Have you ever read technical information that goes above your head? Or spoken to an expert who answers in jargon that leaves you scratching your head? That is a problem that occurs more often when it is written by experts for people who are novices. It's caused by the curse of knowledge - they make assumptions and miss out important context because to them, it is obvious.
Pros of not having a technical background
The most important benefit of hiring someone who doesn't have a technical background is that they bring 'fresh eyes' to a project. They need to learn from the start, and so are closer to a new user's perspective.A technical writer with no technical background will:
Be closer to a novice end-user's viewpoint, so can pitch the content at the right level
Map the learning process more accurately, as they experience it themselves
Not make the assumptions that an expert might
Be more likely to use simple, every day explanations rather than jargon
Make your content easier for non-expert users to understand.
Don't underestimate the value of fresh eyes. Think of your technical writer as an in-house surrogate customer. They will look at your product like a customer would and will experience the same frustrations and ask the same questions. Â A good technical writer will also suggest how to avoid these issues and that can go beyond documentation - they may have ideas on changes to the whole user experience, from workflows to microcopy.
But fresh eyes come at a cost
Having a technical writer learn about your product and industry from scratch can improve your documentation. But it could take longer to produce and will require your experts to spend some time answering questions and providing demonstrations.Of course, the flip-side is that if you don't pitch your content at the right level, your experts will end up answering the same questions over and over again to different customers.
How can you write without being an expert?
"How can you explain something if you're not an expert in it?" It's a valid point. To explain a technical product or any sort of complex information to someone else, you really do need to understand it in-depth yourself.But here's the thing. That doesn't mean you need to understand every part of a product inside-out before you start writing. The best technical writing tends to be task-focused (or user-centred) and breaks down the information into topics. Each topic typically explains either:
how to achieve one specific goal
a single concept.
So the technical writer only needs to be an expert on that specific topic. Not all topics at once. And they only need to be an expert at the time that they write it.I'll give you an example.Some years ago, I was asked to write a manual for a pelvic muscle stimulation device that was aimed at women. It helped treat problems such as muscle weakness after childbirth, prolapsed bladders, incontinence, etc. Clearly, I wasn't an expert in any of these conditions, but I was still able to produce good, useful content. Because I knew what condition the end-user had, knew what they wanted to achieve, and so all I had to find out was how to use the device for each condition. I didn't need to know about every condition at once, I could just focus on one, document it and move on to the next.The same approach works for more complex products too (I've used the same approach to industrial and financial software).
Is there a happy medium?
Yes, I think so. What you really need from a technical writer is expertise in technical communication and an ability to learn new things quickly. They need to be able to:
Discover who your customers are, what they need, and how they communicate.
Get information with minimal disruption. This means knowing what questions to ask and being organised and efficient when interviewing.
Focus on the user's goals, not the product features
Pick up technology quickly without getting flustered. You need them to have a curious mind and an interest in how things work.
Make your content easier for non-expert users to understand.
Use modern technical writing tools to minimise the cost of updating your content.
Go beyond describing what's in front of them.Good technical writers don't just describe what's there, we try to influence it for a better user experience too. Take it from me, it's not easy to explain how a confusing and badly designed interface works. It's much better all round to improve the interface.
From working in different companies, I'd say that most technical writers who have tech writing experience and some form of tech comm training do a good job. Â So to hit that sweet spot of the middle ground, it might be a good idea to look for a tech writer who has worked on a similar type of product, but not necessarily in the same industry/sector.
The exception to the rule
There's always a 'yeah, but ...' isn't there? In this case, it's when you are writing for an expert audience. With expert audiences, it helps if the writer has at least some level of expertise to begin with. For example, if you're writing API documentation it really does help to be able to write code. You are writing for an audience that codes, so you need to pitch the content at the right level for them.Another specialist audience that springs to mind is electricians. They have very specific technical knowledge and writing for them without a similar background is tough. I know, I've had to do it.I suppose I've stumbled across a golden rule, there - try to find technical writers who have a level of understanding that's at, or just below, the level of your audience.
It's a little different for copywriters
While we're on the subject of being an expert, I'd like to point out that it is not the same with copywriters. That's because for a copywriter to create effective sales copy, they need to consider the needs of the reader, the benefits of the product, and also where the product fits into the marketplace. Â A copywriter needs to do more industry research.A technical writer doesn't have to convince anyone to buy anything. They need to support them with using what they have already bought/decided to use. How it compares to other similar products is of little concern.
Over to you ...
What do you think? If you've been looking for tech writers with a specific technical background, have I made you reconsider? If you're a writer in another discipline, has this opened your eyes to what is actually needed/expected from a technical writer? I'd like to know, so please add your comments.
(I expect there will be some 'you can't be a technical writer without a technical background' ones ... this argument has been going on a long time!).
Shout out to @bossproofreader for inspiring this post and giving comments before I rewrote it!
Craig Wright is an experienced technical writer based in Chesterfield, UK. Â He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
