A Typical Day for a Technical Writer
This blog series will focus on what it means to be a technical writer in a world driven by technology. What does a technical writer do, why is technical writing important, and most importantly, how can you break into the technical writing field?
Whenever I tell someone that I’m a technical writer, there is always one question that immediately follows: “What does a technical writer do?”
The easiest answer is to tell them that I write documentation — manuals, how-to guides, etc. However, any tech writer would be able to tell you that our job includes a lot more than just documentation. We have to communicate with people across multiple departments, write for a variety of audiences, and many of us have to understand programming or code at the same level as software developers.
It can be difficult to pinpoint exactly what a technical writer does, because it varies from company to company. One technical writer might work exclusively with developers while another may never see a line of code. Some tech writers work remotely, while others work in an office.
In the past few days, I spoke with a few technical writers about what a typical work day looks like for them. There are similarities that can help you not only understand what a technical writer does, but can help you decide if you want to venture into the field…
Melinda, Senior Technical Writer
“I start my day right at 9, usually skimming email and responding to Slack messages while grazing on breakfast. Our team has either five or six writers, depending on product demands, and one product manager (PM). We write customer-facing documentation for a handful of software products and components. At 9:20, I run a “standup” meeting… on Zoom, where no one is standing. In this meeting, we let each other know what we intend to work on that day. I’m in a team leadership role, so I often have another meeting or two after standup to discuss Docs department issues and priorities, team allocations, or editorial style. Around 11, I get to dive into writing.
The PM curates and prioritizes our backlog so that writers can always start working on the next story in the list. Sometimes we’ll need to reach out to a subject matter expert (SME) for more information, but we try to make sure stories at least have enough information to get started. Our backlog has a mix of self-generated work and requests from engineering teams. We host our source docs on GitHub and we get contributions from engineers and PMs who help maintain and improve the technical accuracy of our docs.
We’re lucky that in many cases engineers contribute pull requests when they work on a new feature. The self-generated stories range in scope from “fix this typo” to “reorganize this entire page.” Once a week, our team meets to assign point values to each story so that whoever picks it up has a sense of what they’re in for.”
Phil Davis, Manager, Technical Writing
“A typical day: I’m a lone writer, which has its pros and cons. Pro: Anything and everything related to documentation, I’m your guy. Con: Anything and everything related to documentation, I’m the ONLY guy. I start early (5am) to catch our offices in NYC and London and the tail end of Bangalore. I work through emails, Slack, and Twitter to warm up my brain and to groom my to-do list for the day. If we have a patch release, I run and record an all-stakeholders meeting as a final synch-up and last chance to ask questions before we go to production. Then I work through my to-do list: writing docs, distributing drafts for review, posting final docs, pinging folks via email and face-to-face with questions about priorities, scheduling, and the content itself.
Throughout the day I’ll attend short stand-up meetings with different groups for tactical information about features and releases. I’m heavily dependent on our Program Manager. She coordinates all the teams and schedules. Every day I make time for documentation planning and infrastructure. All of my doc production is automated with Python scripts, so I spend a lot of time and energy on extending and maintaining those scripts.
I also maintain the internal doc distribution site. I’m in the middle of replacing it with a static site generator so I’m spending a lot of time and having a lot of fun with Linux, Ruby, and Jekyll. Because of my early start, I’m usually able to knock off around 2pm to beat the traffic. Luckily, evening work and meetings are rare for me, so I can get some time with the family and be rested and ready for the next day.”
Ioana Stanescu, Team Lead & Senior Technical Writer
“Most of the time, my day starts in JIRA, where we have the team dashboard that organizes most of my work (namely: defect fixes that need release notes and new features that need documentation). The rest of the day is spent actually writing this stuff… but this description makes the process sound way less chaotic than it really is!
In between bouts of writing, I research what the new features actually *mean*, field dozens of questions from coworkers on Skype, answer emails, assign tasks, do technical support and generally put out any fires that may start. Surprisingly, I don’t have a lot of meetings nowadays — just a weekly team catch-up point and the occasional demo.”
Simon Dew, Technical Writer
“I work in a global company which makes a NoSQL database platform. I’m part of a distributed team of seven technical writers. There are four of us in various locations in the U.K., one in India, and two in Silicon Valley. We keep in touch via Slack, email, and video calls.
Each writer is responsible for documenting two or three areas of the product. I’m documenting the Query and Analytics services. The users of these features are database managers and developers, so I have to pitch my writing at a technical level, making sure it’s thorough, accurate, and clear.
We work using a Docs Like Code methodology. I’ll make a new branch of the documentation and write up my changes. (We use the AsciiDoc file format.) When I’m satisfied that it’s complete, I’ll make a pull request, and ask one of the developers or the project owner for review. The reviews usually come back on my next work day.
By now, it’s morning in California. I’ll have a couple of meetings via video call. There’s a conference call with the query service development team, so we can keep track of the project’s progress. I have a one-to-one meeting with the head of Technical Writing, to discuss my personal and professional development. There are also regular calls with the technical writing team to discuss style and tone, tooling, and best practice. The whole technical writing team get together for an off-site session, somewhere in the world, a couple of times a year — I’m looking forward to the next one.”
Thank you to all the technical writers above who let me know what they do on a day to day basis!
