A day in the life of a technical writer (during Covid-19)

This essentially sums up what I do day-to-day, stare at engineering drawings


Wake up.

Yes, I know, this is really late to wake up, but I am a bit of a night owl and I like to stay up late. Therefore, I get up late.

Lucky for me, my job doesn’t usually require that I get up early. However, there are the odd times when I need to get up for an early meeting or to drive to the office, but that is rare these days.

Once I’m out of bed, I turn on my work PC, connect to VPN, and start sifting through emails on Outlook and messages on Webex. Typically, I have about 10 emails waiting for me and 5 messages to respond to.

Of the 10 emails, 6 often have nothing to do with me and can be immediately sent to the trash. The remaining 4 need to be actioned. They might require a simple response or a full project plan.

Of the 5 messages on Webex, these are typically questions I can answer immediately. The questions will often sound like:

  • Where can I find this document on SharePoint?
  • What template should I use for this document?
  • How do I get access to this secure folder?
  • What is the status of this project?
  • Where can I find information on this tool?
A man's hand holding a pen over a paper document


Prioritize work.

After I finish responding to all the questions, I take a closer look at my work items. Even though my title is Technical Writer, my responsibilities are much more diverse than that. This is because I am a permanent employee, and I am involved in many projects and have held many roles.

If I had to categorize my work, I would say I spend:

  • 50% of my time doing technical writing
  • 30% of my time doing administration
  • 10% of my time coordinating projects
  • 10% of my time analyzing data

As you can see, my role is actually a mixture of roles; which is something I enjoy because it means a lot of diverse work. But, at the end of the day, I spend most of my time creating or reviewing technical documentation — hence the title Technical Writer.

Next, I review the requirements and due dates of each task to prioritize my work. Understanding the requirements is often straightforward. The due date, however, can be more of a mystery. If the individual requesting the work did not provide a due date, I need to get in touch with them to get it.

Once I have all the information, I am able to determine what I have to work on first and what can wait. I might also have other active projects from the day before that I have to consider.


High-priority items.

Generally by 11:00am, I'm able to get started on the highest priority items. These are typically requests to review technical documents that are due to be sent to the customer by end-of-day.

I am the only technical writer on a team of 20+ engineers, and it is mandated by our supervisor that all documents must be reviewed by me before being sent to the customer. This ensures a consistent look and feel for all of our documents.

It is common that my colleagues will forget that their documents need to be reviewed and will either send them without my stamp of approval or will send them to me with a message that reads, “Urgent. Due to the customer by end-of-day.” Needless to say, these are the documents I work on first.

When I review documentation, these are some of the questions I ask:

  • Was the correct template used and is the formatting consistent?
  • Are there any spelling, grammar, or punctuation errors?
  • Is the wording easy to understand and appropriate for the customer?
  • Are images and tables properly formatted, and was a caption included?
  • Are in-text references correctly linked to images, tables, and appendices?
  • Are technical terms and acronyms properly defined?
A Zoom meeting displayed on a laptop screen


Team meeting.

Every day at 11:30am there is an audio-only team meeting. I attend it most of the time, but it rarely has anything to do with me. If I am busy with something, I will either dial in and have it play as background noise, or not attend.

The only instances where it is essential I attend is when I have something to ask, present or relay to the whole team. Though, even then, I could use the team Webex channel.



I work until about 2:00pm, and then I get lunch. I don’t normally have breakfast because I wake up late, so lunch is when I have my breakfast-type foods.

I generally eat the same thing every day:

  • Oatmeal with cinnamon, milk, and an apple or banana.
  • An egg white omelette with ham and green onions.
  • A half cup orange juice, half cup water, and a scoop of Subi.
  • Either a cup of breakfast tea, green tea, or a London Fog.

I’ll usually read a book or watch something on YouTube as I eat.

A person looking at a computer screen while the sun sets outside the window


Back to work.

If I had to schedule a meeting with someone, generally they would occur after I have my lunch. The meetings could be about anything, but here are some examples from the last couple of days:

  • Meeting with the boss to discuss the creation of a new procedural document.
  • Meeting with a new employee to onboard and answer any questions they have.
  • Meeting with a colleague to capture their input for a technical document.
  • Meeting with a vendor to discuss my concerns with their submissions.
  • Meeting with a colleague to delegate data entry and administration work.
  • Meeting with the project management team to discuss responsibilities.

When I’m not in meetings, work continues as usual. I’ll continue reviewing documents, continue answering emails, and continue answering messages. I’ve also spent a lot of time recently designing and adding content to an internal Confluence space.

Confluence is essentially a content management system (CMS), but purpose-built for team or informational purposes. The space I’ve been working on includes:

  • Pictures and bios of our team members (important during Covid-19).
  • Onboarding information and steps for new employees.
  • Information about the tools and software we use.
  • Procedures and processes for how to do something.
  • Writing and styling guidelines for technical documents.
  • A skills matrix illustrating areas and level of expertise.

The skills matrix has been my favourite project of late. It visualizes all the skills our team members have and their level of proficiency with each. This is an important tool for two reasons:

  1. So we know which team members to contact when we have questions.
  2. So we know who on the team needs training or mentoring, and in which areas.

Again, this generally isn’t something a technical writer would do. But when time permits, these informational projects are work items I enjoy, and I think they are valuable to our team.

A teddy bear looking at a laptop screen in a dark room


Shutting down.

Assuming I finished everything I needed to do, I typically shut down by 6:00pm. Then I have supper, do a workout, read a book, and work on other projects — such as this website or my research summaries.

And that sums up a day in the life of a technical writer! Hopefully, that was useful for anyone considering becoming a technical writer. I’ll just mention one last time that, even though I have the title of Technical Writer, a lot of the work I do is actually a mixture of roles. The typical day of someone who works strictly as a technical writer might look different.