What do technical writers do, exactly?
We’re sure that every technical writer has heard that question, or some variation of it, at least once in their career.
The people who ask that question usually presume that technical writers write all day.
And as you know, that’s not true.
Technical writing is a job with a wide variety of tasks, and every day can look different. There are, however, some fundamental tasks they perform regularly.
In this article, we’ll go through a day in the life of a technical writer.
Join us!
Starting the Day Productively
How you start your day can shape how the rest of it goes.
It’s not always easy to be on the top of the game from the first moment, but you can do certain things to ensure a productive beginning of the day.
There are different approaches to getting the day started.
For example, you can pick up some easier but still important tasks like handling email, company communication, going through the plan for the day, etc.
That’s how Phil Davis, a manager and technical writer with decades of experience, kicks off every morning.
On the other hand, Tom Johnson, a Senior Technical Writer at Google, has found that a different strategy works for him.
He adopted the 80-20 principle, or Pareto’s Law, which he read about in The 4-Hour Workweek, a book by Tim Ferriss.
Here’s Ferris explaining the principle:
Source: Web Hosting Reviews on YouTube
In short, the principle claims that 80% of the output comes from 20% of the input.
What does that mean for technical writers?
Johnson advises that you focus on the two critical tasks and get them out of the way in the morning—they are your 20% of the workload that amounts to 80% of the results.
In other words, starting the day by tackling the most important and time-consuming tasks instead of focusing on minor issues is challenging but improves productivity.
How you start your day is ultimately up to your preference. The key is to get started, be it just by replying to Slack messages or taking on the big task of the day.
Meeting With the Team
After productively starting the day, it’s time to check in with the rest of the team.
Team meetings are a good chance for technical writers to align their working schedules with other employees, go over pressing issues or simply go over what needs to be done that day.
For instance, in the video below, Amruta Ranade, Head of Docs at Airbyte, describes which meetings she attends as a technical writer, starting at the 2:34 mark.
Source: Amruta Ranade on YouTube
As she mentions, sometimes there are meetings with stakeholders, engineers, designers, and everyone else involved in the project, and sometimes the meetings are 1:1 with the manager or subject-matter expert (SME).
However, she also mentions that she has 30-minute breaks between meetings when she can’t do any productive work.
As Paul Graham, a computer scientist and author, explains, that’s because writers operate on the maker’s schedule instead of on the manager’s schedule.
In other words, writers need larger time blocks to focus and create. That’s why meetings can be detrimental to their productivity, however useful they might be.
A helpful strategy might be to adopt Scrum methods like daily stand-up meetings, where the attendees discuss what they accomplished yesterday, what they will do today, and what issues they’re facing.
Those meetings last 10-15 minutes, and although they are primarily intended for developers and software engineers, writers should also attend them, as Robert Spielman argues.
That way, writers can stay up to date with all the latest changes in the direction the project is going. Based on that, they can plan and adapt their writing.
Revising Technical Documentation
After the meetings, it’s a good idea to revise documentation from the day before.
Rarely, if ever, is a first draft of the technical document without faults.
Technical documentation often deals with complex concepts, and many elements can use polishing, be it the language or the accuracy of the writing.
Therefore, it’s helpful to self-edit what’s already written before the same document goes on peer review, which we’ll discuss in one of the following sections.
To help you with that process, you can consult a style guide that your company uses.
Or, if it doesn’t, use some of the most known ones, like the Google Developer Documentation Style Guide.
Style guides offer detailed recommendations on grammar, formatting, structure, language use, and other technical writing elements.
For instance, above, you can see one of Google’s recommendations regarding the use of jargon.
Another helpful thing to do while revising technical documentation is to put yourself in your audience’s shoes.
Who is the documentation you’re revising for?
Is it meant to be a user manual for the general public, or is it API documentation for software developers, like this one from Breadwinner below?
Adopting the same mindset as your audience can help you revise your writing, address any assumptions you might make about their knowledge, and, in short, mold your documentation to the readers it’s meant to be for.
Revising technical documentation can be a mentally challenging task. That’s why it’s good to recharge by taking a break. We’ll examine that in more detail in the following section.
Taking a Lunch Break
A lunch break is more than just a time window when you can eat—it’s a chance to step away from work, recharge your batteries and be more productive for the rest of the day.
For technical writers, that kind of break is important because of the complexity of their jobs.
Having a productive morning, attending meetings, and revising documentation are all tasks that require full attention and participation—especially if they opted for tackling the writing or researching before the break.
Richard Denniss from the Australia Institute explains that eating lunch at the desk isn’t a sign of an employee’s commitment. On the contrary, it’s detrimental to their work process.
A real, away-from-your-desk lunch break is beneficial to many factors that signify enjoyment in the workplace.
That’s what a survey by Tork indicates. The workers were asked about their job satisfaction, whether they felt valued, if they would take a chance to change jobs, etc.
Results across the board favored the employees who take a lunch break every day—they answered more positively to every question than employees who didn’t take lunch breaks, like the one about effectiveness and efficiency below.
So, what can you do during your lunch break?
Besides having a meal, you could take a few minutes to meditate.
Meditation has many benefits, like reducing stress and increasing attention span, which can help technical writers throughout the day.
If you don’t know where to start, YouTube is full of short meditations that can fit in a lunch break.
Source: Goodful on YouTube
If meditation isn’t your thing, you can take a walk, listen to music, or just socialize with your coworkers.
As long as it takes your mind off work, it’s good for your productivity throughout the day.
Doing Research
Research is an essential phase of a technical writer’s job.
Simply put, the technical documentation can’t be good if the writer hasn’t put effort into familiarizing themselves with the topic.
If you’re writing a technical document, you can do your research in various ways—by reading about the topic, using the product or the feature yourself, or talking to the experts.
The important part is realizing how crucial the research is so that situations like Kevin Chilton, an experienced technical writer, witnessed when the company he worked for hired a new writer.
Talking with subject matter experts (SMEs) is one of the research methods, and it’s one of the most effective ones.
Experts can provide valuable insight into a topic, feature, or product, answer your questions, and point out the crucial details—in short, they save you a lot of time and give you high-quality information, as the Reddit user below explains.
You can use interviewing SMEs as a starting point of your research or as a way to clarify and enrich the information you collected yourself.
For example, one technical writer from BETSOL, a data management and intelligent automation company, works on documentation for engineers and prefers to conduct research on his own.
“Before I start writing, I prefer independent research, finding the right pieces of information, and then fitting them together for the users.”
However you approach it, research is a crucial part of any technical writer’s day.
Without it, the next part of the day we’ll talk about would be a waste of time and effort—the part when you actually write.
Starting a New Document
Once you have done your research, it’s time to put that information together and write great technical documents.
This part of the technical writer’s day is about structuring information and starting to write.
In this phase, the important thing is to make a good outline and write a version of the document that you’ll revise the next day.
While doing that, you should remind yourself every so often that the document needs to be useful for the audience—that’s its purpose. Here’s how technical writer Tom DuPuis puts it:
To start a new document more efficiently, you can use mind maps to organize your ideas and information.
There are many software solutions available for that. For example, SimpleMind is a tool for creating mind maps that you can try for free. It is also easy to use.
Starting a new document is much easier when you have your information laid out in front of you and logically organized.
After that, you can make an overall structure of your document. That means making a hierarchy of information with headings, subheadings, lists, and so on.
For example, take a look at the page from the Arlo HD Security Camera System User Manual below.
As you can see, the information is structured in a numbered list under a subheading, which is a part of a larger section.
The structure is what holds your document together, but it isn’t set in stone—you can tweak it when you revise your document.
And when you’re done writing the document, you should submit it for peer review.
Conducting Peer Review
Technical writers convey a lot of information in their documentation, and despite their best efforts, self-editing and good writing skills sometimes aren’t enough for a great text.
However, you can devote a part of the day to organizing peer review.
During peer review, other writers, experts, and managers can read your document and provide their feedback. The purpose is to work as a team so that the final product is the best it can be.
For instance, below is a part of an example of peer review from David McMurrey.
As you can see, he comments on the positives in the document, as labels for the screen captures.
Also, his critiques are constructive and point out specific problems, as well as offer possible solutions.
That’s an excellent way to make peer reviews effective, whether you do them by email like in the example above, or like technical writer Simon Dew does it:
For that kind of peer review, you should use a software solution that allows team members to collaborate on the same document whenever they find it convenient.
Archbee is a tool that has features specifically designed to simplify collaboration.
For instance, your peers can highlight parts of the text, leave comments, mention other teammates, and engage them in the review process.
You can also share the document with specific people who will review it by controlling the access to documentation.
It’s a great tool to connect your whole team in the peer review process.
And when they’re finished, it’s time to proceed to the final part of technical writer’s day—finishing up.
Finishing for the Day
As the workday comes to an end, a technical writer should find themselves in a situation where most of the tasks are finished, and all it remains is to handle some less demanding work.
What those are depends on the workflow throughout the day.
For example, if you tackled the most difficult tasks at the start of the day, as we mentioned in the first section, you might be left only with emails and messages to check at the end of the day.
However, you can also use this time to plan for the next day.
That’s something Amruta Ranade does every day. She calls her approach the Getting Things Done (GTD) strategy.
That strategy involves writing down every idea throughout the day so the mind can be free to be in the present moment.
At the end of the day, she reviews her notes and determines what she should do tomorrow, what ideas need more development, etc.
In other words, she organizes her daily thoughts and ideas and makes them part of her plan for the next day.
You can watch more about the GTD strategy in the video below.
Source: Productivity Game on YouTube
Also, for similar reasons as for taking the lunch break, you should leave work at work whenever that’s possible.
For instance, Ember Stevens from LaunchDarkly recommends muting your Slack notifications after working hours.
Finishing the day as organized as you were for the rest of it ensures that you’ll start the next one as rested and as productive as possible.
Conclusion
And with that, a day in the life of a technical writer ends.
Although every day is at least slightly different from the next, technical writers need to employ many different skills in every one of them.
Not many jobs have days in which you have to collaborate with your team, attend meetings, revise and edit your writing, research complex topics, plan your tasks, or work on your documentation—and those are the basics.
On the other hand, that’s what makes this job so interesting! We hope that this one day we’ve guided you through did it justice.
