Today’s Role Model is Heather Stenson. Up until three ago, Heather was a librarian at an art school. Feeling burnt out and looking for her next step, she began to reflect. She enjoyed the more technical aspects of her librarian job and knew basic HTML and CSS, so she enrolled in a coding bootcamp. Upon graduation, she expected to look for a job as a developer, but a friend pointed her towards a technical writing role at Facebook. After researching the position, she realized that it was the perfect marriage of her library background and her newfound tech knowledge. Heather is currently a technical writer at Mapbox, a location data platform.
What’s your official title and how long have you been in this technical writer role?
I’m a technical writer at Mapbox, a location data platform, and I’ve been here for about 8 months. Before that I worked as a hybrid tech writer/content strategist at a startup called CodeFights (now CodeSignal), and before that I was a tech writer at Facebook.
What attracted you to this role?
Mapbox is still a pretty small company, but its tool and product offerings are really wide ranging. I don’t like to work on just one thing, so the fact that I’d get to work on documentation for a lot of different products was really appealing. And the documentation team is really small – there are only two of us – so I knew that I’d have the opportunity to have a big impact on the organization. Even though the docs team is very small, there’s a really strong culture of documentation here. Everyone pitches in to make sure that our documentation is useful and thorough. It also helped that everyone I came into contact with at the company was super friendly.
Walk me through a typical day in your role. What activities do you engage in? What types of meetings do you join? When’s lunch?
Mapbox has a lot of different offices spread out across the world – San Francisco, Washington DC, Minsk, Helsinki, Shanghai, Beijing, plus a lot of remote workers. Since we’re so distributed, we communicate a lot using Slack. We also use GitHub issues to coordinate a lot of work! So when I start my day, I check in on my Slack and GitHub notifications. I have keyword notifications set up so that I can always know when my coworkers are talking docs! I make a pretty detailed to-do list for each day so that I know what to focus on. Then I grab an almond milk latte and get to it.
I’m usually juggling several different projects, and if they have regular meetings/scrums I’ll join in on those so that I can keep track of what’s moving. If I’m just starting a big project, I try to have a meeting with the stakeholders (usually a combo of project managers and engineers) early on so that I can get a good sense of the project’s parameters.
I try to leave the office at least once a day to remind myself that there’s a whole world outside the office. At Mapbox, there’s a rich tradition of the“cookie walk” – folks taking some time in the afternoon to go grab a sweet treat – but sometimes it’ll be coffee instead.
What skills/technologies help you succeed?
At every technical writing job I’ve had, the one constant skill that I’ve needed was being able to write markdown, a formatting syntax that can be converted to HTML. It’s the formatting syntax used in wikis, and it’s also pretty standard in a lot of documentation frameworks. Beyond that, it’s also been helpful that I know HTML/CSS. This allows me to have more control over how the documents I write are formatted.
At Mapbox, we use GitHub for everything, so it’s been critical for me to know how to use git and GitHub, and to feel comfortable doing things in the command line. Knowing how to “read” code is also useful – I can look at a snippet of code and get a sense for what it does, even if I don’t know the language it’s written in.
What’s the most fun or creative part of your technical writer role?
Every new product that I write about means another new toy that I get to learn how to use! Before I can write an effective guide or tutorial, I need to use the tool or product so that I can unearth potential user pain points and guide them to a good outcome.
What are the biggest challenges you face in this role?
One of my biggest challenges is juggling lots of different projects at once. Docs never stop, so I usually have at least five projects that I can work on at any given time! It’s really important for me to be able to weigh something’s potential impact against the time required to complete the work, and prioritize accordingly.
What teams/individuals do you work with cross-functionally? Can you give an example of a time when you collaborated with another group/individual?
The documentation team at Mapbox works with nearly all of the product teams! When a new product is released, or a tool is updated, this means that we’ve got work to do. We typically collaborate with a combination of product managers and engineers when we’re working on documentation – they provide background, technical details, code examples, and just generally help guide the work we do. We also work really closely with the support team. Since they are constantly interacting with Mapbox users, they are able to identify ways in which we can improve our documentation.
What’s an area where you’re trying to grow in your technical writer role?
Right now, we are in the process of moving to a new documentation framework that uses React. While I don’t need to know React in order to use the system, I’ll need to know it in order to build my own components! If I think of a cool new UI component that I’d like to be able to use across various documents, I really want to be able to build it myself.
Aside from technical skills, what personality traits/characteristics make for an ideal candidate in your role?
Good technical writers are naturally curious people! They want to take things apart and see how they work, then share what they’ve learned with others. Being detail-oriented and organized are helpful as well.
What skills (tech/non-tech) have you improved as a result of working in this technical writer role?
I have a tendency to try to power through problems to find the questions myself. In some ways this is a good thing. But when the subject matter expert for the problem I’m working on is a mere Slack message away, a lot of times it doesn’t make sense for me to spend hours struggling with a question! So I’m getting better at timeboxing problems – if I don’t reach the answer myself in a reasonable amount of time, I reach out to someone who knows the answer.
In your role, what metrics define success?
As a team, we’re still working on defining what “success” for a piece of documentation is, and how we measure that. We’re exploring a lot of different ways to capture user feedback and user actions, and then turn that data into a way of measuring success. Anecdotally, though, we get a lot of feedback from different channels that people love our documentation and find it to be really helpful, so that’s a good way of knowing that we’re on the right track!
Want more of these interviews delivered directly to your inbox? Sign up for my monthly newsletter.