What Does a Technical Writer Do? A Day in the Life

“So what does a technical writer...do...exactly?” It’s a question I’ve heard from friends, family, and strangers many times over the course of my writing career. The confusion is understandable. The answer feels like it should be obvious—it’s writing! That’s technical! It’s right there in the name! But the details remain stubbornly fuzzy to most. 

In reality, most of us regularly interact with the work of technical writers over the course of our day-to-day lives. Technical writers create instructions on how to put together your new bed frame, work your coffee maker, and program Alexa to automatically crank up the polka music at 9 p.m. when you want guests to leave your dinner party. Technical writers take complicated concepts, break them down into their essential parts, and present them to the reader in a way that’s easy to understand, whether they are spatial (“connect headboard A to bed leg B”) or conceptual (“Select your favorite Polka band from the list and click schedule”).

At LaunchDarkly, the technical writing I do helps our customers understand and use our feature flagging software. My team and I keep our product documentation up to date, write about new features, create best practices guides, and oversee our API documentation. We work closely with engineers, designers, developers, technical support, and user experience experts to translate complicated technical concepts into a format that our customers can use and understand.

Here’s what a typical day looks like for me:

9 a.m.

Unsurprisingly, the first things I check for the day are Slack and email. I don’t use email for workflow management as much as I have in past positions, as most of our work is done in Slack, our ticketing system Clubhouse, and, these days, Zoom. But, old habits die hard and I still use email to get a sense of what’s on my plate for the day. 

First, I look at an editing request that came in last night (LaunchDarkly is an international company with employees all over the globe, so I never know what time zone my colleagues may be working from). As product experts, our engineers and developers write first-draft documentation, outlining all of the technical specifications and how-tos for upcoming feature releases. It’s my team’s job to take these rough outlines and mold them into a final product through editing and polishing. 

To do this, I open our Gatsby-hosted documentation site, our internal software staging site, and read the first draft side-by-side with the new feature itself. I look for things like:

• Do the step-by-step instructions make sense? Can I follow them exactly and achieve the stated goal?
• Is the structure of the content logical? Do I need to add screenshots or links to other sections of our documentation or external resources to help with explanations?
• Is the language clear, concise, and easy to understand, including for non-native English speakers? Are there any idioms or colloquialisms that might be confusing to readers outside of the US?

After consulting with the submitting engineer and asking clarifying questions, I submit my edits using our version control software, GitHub, and assign a final review to our technical writer manager. When the new feature is released to customers in a week or so, our updated documentation will be released simultaneously for a seamless user experience—a win for the day and it’s only 11:30!

11:30 a.m.

Next, a customer suggested an edit to our existing documentation via GitHub. Customers are our best reviewers, and we love receiving their feedback and suggestions. I take their edits, do any needed sprucing up, and publish the changes. I also send them a thank you message for taking the time to share their thoughts. We really do have the best customers.

12:30 p.m.

Lunchtime! I’m a remote employee, so the canteen (my fridge) is just a short walk away from my office. Today: leftover takeout from one of Portland, Oregon’s famous food carts (a fried chicken sandwich from Jojo’s on Powell Boulevard—check them out when you’re in town!). 

1 p.m. 

After lunch, I meet with the user experience (UX) team to talk about upcoming changes to our user interface (UI). The documentation and UX/UI teams work closely together to ensure the language used in the UI is clear, accessible, and follows our style guidelines. We talk about word choice for buttons and labels, how to shorten blocks of text to just the need-to-know information, and where to link out to the documentation from within the product for more details. 

2 p.m.

I check Slack, which tells me that I have been added as a reviewer on an urgent pull request in GitHub. We try to avoid last-minute changes as much as possible, but in this case, an external website we link to has gone down, meaning our users are seeing a 404 error when they click on it. Not the best user experience. My colleague has found a suitable alternative to point users toward, so I double-check that the new link works, and approve the change. 

As a best practice, all of our technical writers submit their changes for review from someone else on the team, even if it’s just a small change or typo correction. You never know what someone else might catch that you didn’t, and if something goes a little wrong...well, it’s nice to be able to spread the responsibility around. :)

3  p.m.

It’s time for “Documentation Office Hours,” one of my favorite parts of the week. Once per week, our team hosts open office hours for anyone in the company to drop into. Folks pop in (virtually) to talk about docs changes they'd like to see, questions about how we plan to talk about new features, or just to say hi. 

4 p.m.

This time, it’s my turn to visit our support team’s office hours. Our amazing support team works directly with customers every day and is the best source of information for what customers are struggling with, where our documentation could be expanded, and to answer my own questions about how a particular feature works. Plus, they’re just fun to hang out with.

4:45 p.m.

Yikes! I look at the time and realize I have a few more reviews to take care of before the end of the day. I wrap up any outstanding edits, check in with my manager to see if there’s anything she’d like me to work on first thing tomorrow, and roughly plan out my to-do list for the following day.

5:30 p.m.

Quittin’ time! I close my laptop for the evening, and Slack automatically mutes notifications at 6 p.m. One of the many things I love about working for LaunchDarkly is that they recognize the hard work we put in during the day, and in turn respect evenings and weekends as our own time. It’s one of the reasons I love working here and makes me excited to log back in in the morning.

If you're interested in joining the LaunchDarkly team, check out our current openings.