Who is a technical writer and how to become one

Hi, my name is Olga Gromiko. I work as a technical writer at R-Style Softlab and create documentation for banking software that helps users understand how services work. In this article, I will tell you in detail what a technical writer does, what skills help them in their work, and what prospects such specialists have.

What does a technical writer do?

A technical writer is a specialist who prepares documentation for software. Manuals provide users with answers to questions about how the product works, help them quickly navigate the settings, and become familiar with all the capabilities of the system. To collect the necessary information and describe the solution, a tech writer communicates with analysts, developers, testers, designers, and project managers.

Ideal technical documentation, first of all, should be understandable. To make it easier for the user to navigate the text, you need to think through the structure, logic of the description and navigation, use lists, diagrams and tables, add screenshots of the interface and illustrations.

How to get into the profession and find your first project

In order to work as a technical writer, it is desirable to have a technical education. But this is not a prerequisite. I graduated from the philological faculty and used to teach Russian language and literature at school.

I got into the IT sphere, you could say, by accident: I was offered to try myself as a technical writer at R-Style Softlab in 2019. The responsibilities seemed interesting to me, I passed the interview and got a job at DSEBO (Department of Electronic Banking Systems). My first project was a large product for RSHB for remote banking services for legal entities.

I admit that it was difficult to get used to it. In order to understand banking terms, documents and cryptographic protection, I had to read a lot and watch video tutorials. At the same time, I took courses from team leads-techies from other companies.

Some people believe that a specialist in this field must have a technical education. Otherwise, it will not be possible to competently talk about the operation of an IT product. In fact, education can be anything. The main thing is to have a desire to understand the intricacies of the profession.

What are the types of technical documentation?

A technical writer can develop different types of documents. It all depends on the company and the product. In one organization, a specialist may write administrator and user guides, in another – issue updates to the release, and in a third – do both. Most often, technical writers prepare the following types of documents:

• User manual. These instructions explain in simple terms how to use the product. They usually contain step-by-step instructions, screenshots of the system, and troubleshooting tips.

• Documentation for technical specialists. These documents describe system requirements, server setup, access rights distribution, and other details.

• API documentation. These guides describe how to use application programming interfaces (APIs), which are used to integrate different systems. An API guide should contain information about available functions, methods, parameters, data types, and code examples.

• Documentation for updates. When a new version of a product is released, all changes should be reflected in the manuals. They tell about new features, fixed bugs and technical limitations.

At R-Style Softlab, I write instructions for clients, system administrators, and bank employees (teller who serve clients in bank branches: issue cards and loans, help make transfers, and provide financial advice). At the same time, for each user, it is necessary to take into account the specifics of their work in the application.

Many tech writers have a rule: write in a way that a “hypothetical grandmother” can understand. Of course, not all IT products can be described in very simple language, but it is always possible to make it so that any person can open the document, follow the steps and get the result.

How to organize work on a project

Depending on how the project is structured (waterfall or agile), the technical writer creates documentation at the final stage or updates the manuals in parallel with the product development. Most often, the work of a technical writer is structured as follows.

Statement of the problem. A technical writer receives tasks from product managers or department heads. Usually, the technical task specifies the scope of the program, as well as the volume and type of technical documentation, assigns deadlines and responsible employees. I specify the task details in Jira: it is convenient to use the system, because in addition to the technical task, you can find additional documents and explanations for them there.

Collection and analysis of information. This step is one of the most difficult and time-consuming. To get all the necessary data, I use different sources:

• I study documentation from the bank and analysts. I read functional requirements, technical specifications, specifications, project architecture, descriptions of individual system components, explanatory notes. I also study the product's operation as a user, look at test stands.

• I ask questions to my colleagues. First of all, I go to analysts and collect information about the product: they set tasks for development, so they understand the product's operation well. If I need to clarify the nuances, I turn to testers: during testing, you can also understand how specific functions work. Sometimes I ask questions to developers to get more data about the details and logic of the systems.

Writing text. At this stage, everything depends on whether it is necessary to comply with GOSTs in technical documentation. If a technical writer prepares manuals or instructions for standards, they must comply with the requirements of GOST 19 “Unified System of Software Documentation” and GOST 34 “Information Technology”. Such documentation is usually required by state companies.

It is easier to write technical documentation without the requirement to comply with GOST: you do not need to comply with many standards. I work with exactly such texts. I use a Word template that was developed in the company before me. It already has a basic format and structure. Clients are also more accustomed to receiving and approving manuals in this form, but many technical writers use special software.

Checking documentation. Errors in manuals can have serious consequences. For example, if a technical writer incorrectly wrote installation commands in the banking software manual, the system administrator will have to spend a lot of time searching for the error.

To avoid such problems, the finished documentation needs to be double-checked. In some companies, this is done by testers, and in R-Style Softlab, they have organized cross-checking: technical writers look for errors and inconsistencies in each other's documentation.

We don't have any universal deadlines for preparing technical documentation. Everything depends on the scope of the task and the experience of the technical writer. On average, it takes about a month to write one manual.

Coordination of documentation. Once the manual is ready, it needs to be sent to the customer so that he can review the document and make edits. Here, too, it varies: some accept the documentation immediately, while others force you to go through several iterations of edits.

Updating documentation. When the next version of a product is released, the technical documentation needs to be adjusted: new functions need to be described, irrelevant ones need to be removed, and sometimes the entire section needs to be rewritten for easier reading.

What skills are needed for the job

If you're considering a job as a technical writer, test your skills.

• Literacy. A tech writer must understand style, grammar, spelling and punctuation. A literate text is, first of all, respect for the reader. In addition, a clear and unambiguous text is easier to understand.

• Logical thinking and text structuring. Logic in the text is responsible for cause-and-effect relationships. A clear structure and simple sentences help to read diagonally and quickly find the necessary section or description in the document. I always break the text into blocks, use subheadings, tables and lists.

• Communication skills. A technical writer should be able to ask questions and get specific answers from colleagues. A well-asked question is half the battle. Don’t be afraid to ask again if you don’t get an answer right away. Remember that colleagues may be busy with other tasks and miss your letter in their inbox.

To make it easier to get the information I need, I often send possible answers along with the question and number them. That way, the other person can simply send a number to the chat without being distracted from their work tasks.

It is also necessary to briefly describe the steps already taken or specific conditions so that the colleague does not waste time explaining individual points.

If I don't understand the issue the first time, I turn to my colleagues again. They always help me out – they explain in other words, give clear examples, demonstrate the screen and show how the app works.

• Perseverance. Preparing technical documentation takes a lot of time and requires attention. It is necessary to collect and study information, process it and write the document. If a person has difficulty concentrating and is easily distracted, it will be difficult for him.

• Stress resistance. Be prepared for edits. Comments are a work process, so don't take them personally. I remember when I was just starting out, a colleague would leave a lot of comments on my texts. On the fifth round, I wanted to give up, but edits pay off: over time, I started writing better.

• Desire to learn and develop. In this profession, you have to work with different products. Each has its own specifics and features, and the documentation will also differ in volume and content. Technologies are constantly evolving, so you often have to get acquainted with new topics and delve into details.

Many technical writers now use neural networks in their work. I also often ask questions in Chat GPT about the work of related systems, so as not to waste extra time on their detailed study, or ask for clarification of the meaning of this or that term. But we are preparing documentation for people, so the manuals must be written in a living language – and AI cannot do that yet.

Where to grow in the profession

Good technical writers are always worth their weight in gold, because quickly and efficiently written documentation helps develop and sell a product. But the tech writer position can also be a good start for another IT profile:

• Analyst. A technical writer can move into the analytics field: such a specialist has skills that will help him get into the work faster, for example, collecting, structuring and combining information. In addition, the analyst needs to communicate directly with the customer, draw up functional requirements and set tasks for developers.

• Tester. A technical writer also has the necessary skills to work in this direction. When a specialist prepares documentation, he goes through the entire process step by step and acquires, perhaps, the main skill of a tester – finding bugs in the implementation.

It is also possible to move to positions related to product development and project management, but it will be more difficult. A tech writer understands the specifics of project management and may even be familiar with the basics of programming languages, but these professional areas have a lot of specifics and often require deep knowledge.

As of July 2024, there are not many vacancies for a technical writer on the market – for example, there are only about 1,000 of them on the HeadHunter portal. For comparison, the search query “developer” returns a list of 61,000 offers.

The low demand for technical writers can be attributed to the fact that in many companies technical documentation is written by other specialists, such as analysts, testers, developers. Sometimes employers think that there is no point in opening another position on staff. I believe that each employee should do their own thing. If one employee performs the duties of two different specialists, they may make a mistake and fail to cope with the task.

Requirements for candidates vary: for example, technical education, experience with Linux systems and markup languages. At R-Style Softlab, we often hire specialists without experience. The most important thing for us is the desire to learn and understand the material, communicate with people and ask questions. We interview candidates in several stages.

Literacy test. The candidate is asked to correct errors (spelling and punctuation) in a technical text. Due to the fact that most words are unfamiliar to the applicant, this stage demonstrates general erudition, the ability to understand the structure of a sentence, and navigate an unfamiliar area of ​​knowledge.

Testing the ability to work with lists and text structure. At this stage, the applicant must read the text, analyze the information and logically correctly arrange individual parts of the text. Structuring data in the form of lists of different levels is welcomed.

Creative test task. Next, the candidate is asked to describe in his own words a screenshot of a section of a real system. This task shows both the applicant's level of literacy, the logic of presentation, and the manner of constructing sentences.

Logic test. We suggest taking a test. If the candidate made a few mistakes, we give him a chance to correct them independently. If the person was able to give the correct answers, we count the passing of this stage.

After starting work, an individual training plan is developed for the applicant. The approximate period is three months, but it can be shortened depending on the employee's success. During the probationary period, colleagues explain in detail the specifics of the project on which the employee is being trained, help to understand the requirements for texts, and also introduce the corporate style.

After the probationary period, the employee is not left alone with tasks and problems; colleagues continue to check the documentation for some time. This way, the employee can worry less about mistakes and calmly immerse themselves in the profession.