Tech writing FAQ

Check out this article for a step-by-step guide on how to start.

No. However, I’d say that you must like working with computers and new technologies.

If you are scared of computers and you aren’t interested in technology, you might find this job not suitable for you in the long run.

There are different career paths you can choose to advance your career after you become a tech writer. It all depends on how to see yourself in the future and what are your interests. That’s why I divided the answer to this question into two sections: a career that is related to tech writing and a general career in IT.

Tech writing career

• Senior: you can start your career as a junior or mid tech writer and then your goal could be to achieve seniority in tech writing. Senior tech writers might have different responsibilities in different companies, but generally, their tasks should go beyond standard documentation-related tasks.
• Leader / manager: you might become a leader of a team of tech writers.
• Architect: documentation architect is responsible for multiple tasks that also go beyond standard documentation tasks. He or she might be in charge of the overall documentation structure, documentation releases, maintaining consistency throughout documentation, CSS styles, and many more.
• API tech writer or developer-facing documentation writer – this path requires you to have far more technical knowledge related to programming languages. The documentation you will prepare in this job is targeted at the developers who use certain solutions in their code. This job requires you to be able to read and understand the code.

Career in IT

• Tester: to properly create documentation, every tech writer must also be a manual tester and similarly to testers, must have a user-centered approach to software. That’s why you may find it quite easy to switch from tech writing to testing.
• Agile coach or scrum master: it’s a possible career path for tech writers, though you must have certain soft skills to jump into it. For example, you should be communicative and assertive.
• Product owner or product manager: tech writers very often have huge knowledge about the product, which is a great starting point for a career in product management.
• Developer: I think it’s the most difficult path you may choose. The internet is full of stories about people who successfully became developers, but in reality, it might be far more difficult than it sounds. However, this career path may be quite natural for you if you are already able to read and understand the code because you write documentation for developers.

There is no easy answer to this question because the salaries differ across countries and companies. Multiple factors can influence how much you earn as a tech writer: your general experience, your experience in tech writing, or your other skills.

However, there are a couple of ways that can help you assess tech writers’ salaries in your country or on a given job level:

• Check out the websites like Payscale or Glassdoor.
• Look through job offers from multiple countries: often the salary is provided in the offer. Additionally, check job offers in many places: LinkedIn, internet websites with IT job offers (often there are separate websites for IT and it starts to be a common practice to provide salary levels there), Facebook groups.
• Ask on a Facebook group or a tech writer you know. It’s a very personal question, so treat it as a last resort, but you can always ask the person or people in a group to provide you with a general idea of what the salaries for this job look like.

Generally, remember that tech writers mostly work in IT and this industry is extremely lucrative nowadays. Though tech writers typically earn less than developers and testers, be aware of the fact that this is also a far less popular job. There are not many tech writers on the market and this can be a great point for salary negotiations.

In my opinion, it’s not necessary for one simple reason: apart from excellent English, the most important knowledge for a tech writer is the knowledge about the product he or she has to document. This is something you can learn only during on-the-job training.

Additionally, you can learn a lot from e-learning platforms, for example, Udemy, Coursera, or Treehouse. It’s very often more effective and cheaper. Stay tuned for a detailed article about online courses that can help you boost your tech writing skills.

Of course, a typical day can be different on various job levels, in different companies; it may depend on a product, a team structure, a release cycle, or whether your team operates in agile or scrum. However, here is an example of a typical day when you have to document something:

1. You take a documentation task from the backlog. First, you carefully read its title, description, comments, and attachments.
2. If there’s something unclear in the task, you reach out to the team or a PM/PO.
3. Once you fully understand the task and you are sure that it requires documentation, you open the software to play around with the new function. If you write documentation for a desktop or mobile app, it might be necessary to reinstall the software first.
4. You play around with the feature at the same time trying to put yourself in the user’s shoes. You also try to answer the following questions:
   • Does the user need to do anything before he or she can use the feature?
   • Is there a problem or an error the user might encounter?
   • Is there a part of UI that might be not very intuitive for the user?
   • What are all the steps the user needs to take to complete a task?
   • Are there some alternative steps the user can take?
   • Is there an alternative for this feature in general?
   • Can the user “break” something by using this feature?
   • Are there some additional steps the user can take to speed up the task?
5. If you have some additional questions or something is not working, you can reach out to your team again. If you have a lot of questions, write all of them down and ask them all at once.
6. Start documenting. Use the questions you asked yourself when you were playing around with the new functionality to describe important areas.
7. Ask your team to check your documentation from a technical perspective. You can also send it directly to your team’s tester as part of documentation testing.
8. Ask another tech writer for a language review.
9. Ask your PO or PM to accept your documentation.

It depends on your job experience, skills, and how much time you are willing to spend on preparing. However, if your English is very good, you can start participating in job interviews pretty quickly.

Going through the technical writing courses from Google, which I mention in the first FAQ, shouldn’t take you more than a week. If you want to go through an HTML course, this will take a couple of more days. Overall, I think that everyone is able to prepare for this job in around a month.

Every job has its ups and downs, advantages and drawbacks.

Being aware of the difficulties you might come across in a given job, can help you make a conscious decision about starting this career. Here is a list of some problems you may have when working as a tech writer:

• Communication problems with the team or PO/PM. To be able to document, you need to fully understand what needs to be documented and sometimes, good communication is essential to learn about everything that’s related to your documentation task.
• Becoming tired of the product you document. Some tech writers have to work only on one product or certain components of it. After some time, you might get tired and bored. If it happens, try to explore some other opportunities within your company – sometimes it can be enough if you change a team or the component you document.
• Lack of perspectives. Generally, for tech writers, there are plenty of opportunities to advance their careers. However, it all depends on a company and its approach towards tech writers.
• “It just doesn’t work” 🤦‍♀️ 🤦‍♂️. This might be quite a frequent problem when you are a tech writer. When working with software that is under development, a lot of things can go wrong. You should get used to the fact that not everything will be working perfectly as described in a Jira issue.
• Sometimes tech writers work for multiple teams and they have to document several different issues almost simultaneously. This can make you feel overloaded. Read this article to find out what to do when you feel overloaded.

Apart from standard questions (What are your plans? How do you see yourself in 5 years? etc.), you can get some assignments that will help the recruiter assess your writing skills. For example, your task may be to write instructions for a piece of an application or a website.

Additionally, you might be asked to review a piece of documentation – in this way, the recruiter will check your English level as well as your ability to check other people’s work. Be careful about spotting the mistakes that are not there or correcting the style too much – these are quite frequent mistakes during such assignments.

As with every other job, you might get bored after some time, especially if you work only with one product. However, the IT industry is generally very exciting, the products are changing really fast, so it’s unlikely that you will quickly get bored. However, if it happens, you can always try to change the team, the company, or even your role.