Breaking into technical writing is a lot tougher if you are not located in the USA or Europe. This is a nuance of this topic that is rarely spoken about. Perhaps, because in the past there weren’t a lot of people outside the USA and Europe seeking to make a career in this field.
So just before we move on to the actionable ways to break in, let us run through some plausible reasons why it is difficult for technical writers outside the USA and Europe to break into the field. I think this is equally significant, especially if you are not aware of them before now.
Then, it should be noted that these observations would be skewed towards African technical writers, especially those from Nigeria.
Reasons Why It Is Difficult to Break Into Technical Writing
Preference for Technical writers in the USA and Europe
Since last year when I came upon the technical writing field, I have come to know of a large number of people from diverse backgrounds, fields, and countries seeking to break into this fast-growing career field.
Often for most people seeking to break into the technical writing field, they would usually try to get a job either in the USA or Europe, thanks to the Work From Home (WFH) job culture.
This is because technical writing is still not a valued profession in some economies, which is true in Nigeria, the country I come from. Usually, the story is that it is tough getting a job in the USA or Europe.
I have tried several times to understand why it is tougher for technical writers outside Europe and USA to get a job in those two places, but I find it hard to place a finger on it.
Because one of the “beautiful things” people say about the WFH is that it brings more equality to the job market and that people can now compete globally for jobs based on merit only without any unfair advantage. But I would think this isn’t entirely true.
While most companies have begun making it a norm in their job descriptions to state their openness to the WFH, which would have made a convincing case for more job equality.
However, increasingly, it is coming to my notice that companies in these two places still have a strong preference for onsite workers—which explains in part why it is difficult for workers outside the USA and Europe to get a technical writing job in these two places.
Different application qualification yardstick
This hard-to-break-in reality for workers outside the USA and Europe is also very visible when you consider the skill demands of workers in the USA and Europe versus workers outside the USA and Europe.
It is common knowledge that most technical writers come from backgrounds that have nothing to do with software engineering, one of the most common being English. I know quite a number of people who are technical writers and have studied English in college/university—and yes, all these people are living in the USA or Europe.
Some of these people like Tom Johnson and Aaron Redshaw, didn’t know how to code—at least not expertly—when they landed their first job as technical writers.
Tom Johnson got his job far back in the days when writing was valued enough to get you a job as a technical writer without you understanding a single bit of the technical aspect—so I could excuse him from this.
On the other hand, we have technical writers who got their jobs recently but yet aren’t technically sound in programming. Most of them are located onsite—that is, in the USA or Europe.
It would appear to me then that a higher bar is placed for technical writers outside Europe and USA compared to workers living in these two places. If you don’t have good technical skills, it is unlikely that you will be given that technical writing job in the USA or Europe you just applied for.
On second thought, the reality might not be as bad as this. We can say that there are some advantages that will surely come with being present in the USA or Europe. One of which would include better networking opportunities that could play to your advantage in landing a technical writing job even with subpar qualifications.
Work Flexibility
Another salient but important point worth mentioning is that companies’ preference for onsite workers could also be due to reasons of work flexibility.
While some companies abide by WFH and allow it to their employees, they also want to be assured that they could ask them to report onsite for their job if the need for that arises in the future.
This would be easy if their employees are onsite (by this I mean, they are present in the USA or Europe). On the other hand, if their employees are outside these two places, then they have to worry about getting them over.
Which might include visa sponsorship and all of that. This could be too much trouble and cost or absolutely not feasible, depending on the company in question.
This fact further emphasizes what I have already spoken about before.
While all these make for a painful reality, there is still a solution, even though it would mean satisfying all the job requirements which would include programming skills requirement, and demonstrating a strong level of productivity (a company might be willing to sponsor your work visa if you’ve shown them you are worth the stress of doing so).
I see some job posts on some job sites that state this:
Hopefully, this will become a norm soon in practice.
So in this context, we would lay out some actions you can take to better position yourself to nail a technical writing job.
How to Break Into Technical Writing
Train as a software engineer
This should be obvious from what I have said so far.
You must train yourself as a software engineer. You need it to stand out.
I believe strongly in this because, in a situation where a lot of employers would rather have an onsite worker, they will make an exception and hire a remote worker when they are met with rare skills.
Technical writers usually work by pairing up with the engineering team. Technical writers are no experts, at least in programming. The engineers help the technical writers understand the software or sections of the software they want to create documentation for.
They also help them with code samples and snippets to add to tutorials, and reference guides in the documentation. The engineers would also be consulted by the technical writers during the editing phase of the documentation lifecycle when they need to go over the documentation to make edits and changes and ensure the communication material is as perfect as possible.
A technical writer that is sound in software engineering would need little of this hand-holding exercise.
Depending on his/her software engineering prowess, he would require little to no assistance from the engineering team in creating documentation since he can understand the software on his/her own with no assistance required.
This is a rare skill for a technical writer, and companies are always on the look for technical writers who can code very well. It means they would have to put in less work to get the new hire up and running to get tasks done. The reduced cost is something every company has a self-interest in.
If you can position yourself to them with that skill, then you will have a job.
Get hands-on with open source project
While training as a software engineer would help you strengthen your “technical” skills, contributing to open source projects would help you strengthen your technical writing skills.
This is your only way of getting real-world experience as a technical writer.
I can’t say this enough: employers today want new hires to hit the ground running —if not running faster. They are not ready to spend any money on training new hires.
In fact, I have seen employers seek to employ only those whose experience aligns with their current job activities. For instance, Expert Support:
Now, I know of the challenges of contributing to open-source projects. One of the most common is getting to contribute to complex projects.
When people talk about open source projects, most often they refer to public repositories of significant importance utilized by a large number of developers, which are usually complex large open source public repositories.
And they are correct because these are the projects that are worth contributing to since they are useful to a large number of people.
After all, a company that wants to hire you as a technical writer needs you to create documentation for the software they expect would be used by a large audience. So that’s a significant focus point there.
However, this doesn’t mean you should disregard small open-source public repositories that are of no use to anyone.
If you’ve never made open source contributions before, contributing to repositories of this nature could help you get started and comfortable with making contributions. Once you’ve achieved some level of comfort, you can begin attempting contributions to large complex projects.
The issue with making contributions to large complex projects is the difficulty in understanding key areas related to the contribution you want to make. I have heard some people say you don’t need to understand the codebase/software to make contributions, which is correct. But, you still need to understand some parts of the software to reasonably make contributions.
This need may mean reaching out to the maintainers and other contributors to the project, which might also pose a problem of its own. Most commonly being getting a response and getting someone to give you a walk-through on the project so you can get started making contributions.
What this barrier means for you is that you will have to give up on a lot of open source projects when you don’t get a response to your request for a walk-through, which happens very often.
In searching for an open-source project, I would advise you to join the Writethedocs slack channel.
There, technical writers interact and you might be able to come upon a message of someone requesting a technical writer needed to contribute to an open source project. Alternatively, you can drop a message stating your search for an open source project to make documentation contributions to.
Furthermore, join more slack channels related to programming and coding. Many open source project maintainers and contributors hang out there, and you can drop a message and someone will find it and might take you on their documentation team.
Build Your Portfolio
Next to open source projects, building a portfolio of technical documentation content is also a good way to showcase your skills as a technical writer.
In your portfolio, you want to maintain the technical content you intend to create when employed as a technical writer. Technical content deliverables that your portfolio should entail but are not limited to would include tutorials, how-tos, reference guides, getting started, and installation guides.
You do not necessarily need to have published technical content on your portfolio, but of course, getting your portfolio pieces published on sites such as Freecodecamp or dev.to is a plus. But primarily, your portfolio is meant to highlight what you can do.
You should build your portfolio alongside your training as a software engineer. Your programming knowledge will provide you with topics to write about. For instance, you could create tutorials and how-tos based on your practical knowledge and experience building software projects.
While there are several options out there for you to build a technical portfolio, Contentre is easy to use. With Contentre, you can build a technical portfolio without needing to build a portfolio website from scratch. Creating an account is free, and you can host all your portfolio pieces for free.
Update your CV/Resume
As you accumulate work experience via contributions to open source projects and through your training as a software engineer, you want to also ensure you update your resume/CV to make sure it reflects your achievements.
Make sure to highlight specific tasks you did in open source projects you contributed to alongside links to them.
Write…
- Created a website deploying guide for WOAQ (West Oakland Air Quality), an open source project under Open Oakland (a body under Code for America)
Instead of…
- Made contributions to open source project
It is more specific and useful for employers to assess your application.
Then, you want to make sure to list your most challenging and important achievements first. That’s a tip you want to keep in mind too.
So that’s it on how to break into technical writing for workers outside the USA and Europe. Breaking in is hard but with effort, headway can be made.
Keep up the good work!
Contentre helps technical writers stay organized and gain more clients. Grow your technical writing career in one place.
Now that you’re here, let me briefly recap the most important features Contentre can offer you:
- Organize your content in categories, topics, and tags
- Create and manage multiple clients
- Create and manage multiple personalized portfolios
- Get statistical analytics of your content revenue, top categories, and tags.
