Well, at last, you are not alone in all of these endless tasks. Congratulations. Now, let's see how to prepare for the new technical writer to join the team. In general, you would want to reduce the onboarding time and get a team member with the least effort. To do this, you can: Reuse as much information as possible. Document all your processes and regulations to show them to a new colleague. Telling this over and over again will take a lot of time. Create a process. This should work in the same way for all new technical writers. Preparations To begin with, you should prepare the Style guide. It will help the new writer to adapt as they learn the recommendations and can refer to them until this becomes automatic. Also, it is much easier to discuss the errors (errors are inevitable at this stage; new team member learns from them). It might be helpful to create a short test to make the newbie remember the guide. The second important thing is to give time. Never rush, even if the project deadline is close and you desperately need an additional pair of hands. Newbie is in a tough period – lots of new faces and names, even the role itself (in the case of junior professional) may be new. All this brings a lot of stress. Let the new colleague explore the product. The time for exploration depends on the product size and the newbie’s qualification – imagine how many days it would take from you if you saw the product for the first time and add a couple of extra days. Third idea: give “real world” tasks. To learn the terminology, style, and the docs, this task could be combined with the docs reviewing (for example, looking for errors in the existing docs or translating them). While doing this, the newbie will dive into the product and start building communications with colleagues. And the next one: teach. Help a lot. Answer all the questions, create meetings with colleagues, and review all texts at least during the first month. This will help the new colleague to be confident and start working as a team member. However, do not overdo this part – gradually withdraw from the processes to help the newbie build their working environment. Build for the Future If you plan to expand your technical writing group even more in the future, it is good to write an onboarding guide in the internal wiki. This onboarding guide should contain the following: First-time setup. The required software, VPNs, add-ons, credentials, access permissions, etc. How to get them installed and how to configure them to run. How to log in on a daily basis. Just what you do (or don’t do) to start your work. Work resources. This includes but is not limited to, internal portals, chats, API collections, Style guides, documentation archives, product versions and executables, etc. Everything that is needed for technical writing. Company resources. Helpful things for every employee – HR resources, team building, education resources, benefits, company structure, etc. How to find out whom to report and who can help write certain topics. How is performance tracked and what does the new team member need to do to be considered a normal or good employee. Task trackers and version control systems. All this should be enriched with links to the resources and kept up-to-date, as it is a great place to refer to and to reduce the time on explaining the same things over and over again. Summary To sum up: Make the Style guide and use it to teach the newbies. Provide enough time to let the newbie feel confident. Give real tasks with real products and docs. Answer all questions. Write the onboarding guide with all the required information to start and carry on the work. Well, at last, you are not alone in all of these endless tasks. Congratulations. Now, let's see how to prepare for the new technical writer to join the team. In general, you would want to reduce the onboarding time and get a team member with the least effort. To do this, you can: Reuse as much information as possible. Document all your processes and regulations to show them to a new colleague. Telling this over and over again will take a lot of time. Reuse as much information as possible. Document all your processes and regulations to show them to a new colleague. Telling this over and over again will take a lot of time. Create a process. This should work in the same way for all new technical writers. Create a process. This should work in the same way for all new technical writers. Preparations To begin with, you should prepare the Style guide. It will help the new writer to adapt as they learn the recommendations and can refer to them until this becomes automatic. Also, it is much easier to discuss the errors (errors are inevitable at this stage; new team member learns from them). It might be helpful to create a short test to make the newbie remember the guide. The second important thing is to give time. Never rush, even if the project deadline is close and you desperately need an additional pair of hands. Newbie is in a tough period – lots of new faces and names, even the role itself (in the case of junior professional) may be new. All this brings a lot of stress. Let the new colleague explore the product. The time for exploration depends on the product size and the newbie’s qualification – imagine how many days it would take from you if you saw the product for the first time and add a couple of extra days. Third idea: give “real world” tasks. To learn the terminology, style, and the docs, this task could be combined with the docs reviewing (for example, looking for errors in the existing docs or translating them). While doing this, the newbie will dive into the product and start building communications with colleagues. And the next one: teach. Help a lot. Answer all the questions, create meetings with colleagues, and review all texts at least during the first month. This will help the new colleague to be confident and start working as a team member. However, do not overdo this part – gradually withdraw from the processes to help the newbie build their working environment. Build for the Future If you plan to expand your technical writing group even more in the future, it is good to write an onboarding guide in the internal wiki. This onboarding guide should contain the following: First-time setup. The required software, VPNs, add-ons, credentials, access permissions, etc. How to get them installed and how to configure them to run. First-time setup. The required software, VPNs, add-ons, credentials, access permissions, etc. How to get them installed and how to configure them to run. How to log in on a daily basis. Just what you do (or don’t do) to start your work. How to log in on a daily basis. Just what you do (or don’t do) to start your work. Work resources. This includes but is not limited to, internal portals, chats, API collections, Style guides, documentation archives, product versions and executables, etc. Everything that is needed for technical writing. Work resources. This includes but is not limited to, internal portals, chats, API collections, Style guides, documentation archives, product versions and executables, etc. Everything that is needed for technical writing. Company resources. Helpful things for every employee – HR resources, team building, education resources, benefits, company structure, etc. How to find out whom to report and who can help write certain topics. Company resources. Helpful things for every employee – HR resources, team building, education resources, benefits, company structure, etc. How to find out whom to report and who can help write certain topics. How is performance tracked and what does the new team member need to do to be considered a normal or good employee. How is performance tracked and what does the new team member need to do to be considered a normal or good employee. Task trackers and version control systems. Task trackers and version control systems. All this should be enriched with links to the resources and kept up-to-date, as it is a great place to refer to and to reduce the time on explaining the same things over and over again. Summary To sum up: Make the Style guide and use it to teach the newbies. Make the Style guide and use it to teach the newbies. Provide enough time to let the newbie feel confident. Provide enough time to let the newbie feel confident. Give real tasks with real products and docs. Give real tasks with real products and docs. Answer all questions. Answer all questions. Write the onboarding guide with all the required information to start and carry on the work. Write the onboarding guide with all the required information to start and carry on the work.

Reviewing Documents Part 1: Why and What to Review

Writing Procedures Part 3: Enrichment and Best Practices

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

How to Onboard a New Technical Writer

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Mastering User-Centric Software Documentation

10x your growth by hiring potential leaders

10 Ways to Promote Wellness in the Workplace

10 Threats to an Open API Ecosystem

10 Non-Influencers redefining Influence. Opportunity: $1 Million USD Funding to fight COVID-19

Mastering User-Centric Software Documentation

10x your growth by hiring potential leaders

10 Ways to Promote Wellness in the Workplace

10 Threats to an Open API Ecosystem

10 Non-Influencers redefining Influence. Opportunity: $1 Million USD Funding to fight COVID-19

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps