Interview with Sarah Moir¶
Sarah is a technical writer who spent some time experimenting with product management before returning back to writing documentation. She has been a technical writer for 6 years and has written mainly for software security.
Key takeaways¶
- Understand how you define value in your work, and use that to help define your career choices.
- Leaving your comfort zone can help you realize what you enjoy doing and why you enjoy doing it.
What is the story of your technical writing career so far?
I started out with my first job being in general tech support. I did that for about a year at a university, and I was writing a lot of knowledge base articles and support documents along with doing my regular job. But I realized that talking to customers each and every day was not my ideal, so I found a position at the same company for a documentation support writer and interviewed for that. I had the knowledge base articles as my portfolio, but they also had me do a writing exercise. I ended up getting the position and worked there for about two and a half years, writing documentation, communication plans, really anything and everything that needed to be written down. I had the fortune of having a really excellent mentor and colleague. She taught me all sorts of things about user experience, communication plans, considering audiences.
Then after being there for about two and a half years, I decided to move to California and started looking at positions there. That ended up being like five different Indeed job search alerts with different words like copywriter, UX writer, tech writer, documentation writer, or any combination of those words. I came across a senior level position. I didn’t think I’d get it, but it was at a company that I’d heard of in security, which was what I had been writing for at the time. I applied for the role on a whim. I ended up getting a phone interview, then an onsite interview that they flew me out for, and that’s where I’ve been working ever since, at Splunk. Always apply to a position, even if you don’t think that it’s at the right level for you. It might work out anyway. Then after about two and a half years, I felt like I was a little bit too comfortable and decided to check out what product management was all about. I took a product management training course and left the documentation team. I spent 11 months doing products and program management. After 11 months, I made the decision to come back to documentation, ended up back doing security documentation again. And that’s where I am today.
Why did you decide to return to tech writing?
I went through a whole process of defining my career values. The biggest thing for me is that I realized that making the decisions and being the person that is responsible for having the answers was not necessarily who I wanted to be. I instead wanted to be a person that was collecting and disseminating information. So that really led me back into documentation, the realization and validation of what I really enjoy doing. And what I enjoy is sharing information with other people, not necessarily creating something new from scratch.
How did product management compare to tech writing?
There were some aspects that sort of felt familiar as far as knowing how to go off on my own and put together a plan to do something. Similarly, there was a lot of talking to many different people and trying to get them to care about what you’re doing. Those things felt pretty similar, but there was even more, sort of, political discussions or trying to get people to care about what you’re doing. That was a lot more up front, and there was a lot more of it in general. In a documentation role, If you can’t get everyone to agree with you, you can still largely do your job. But in product management, you just have to keep plugging away and trying to get everyone to come to some sort of consensus before you can start working on a project.
I think if I had gone into a more junior position with an active mentor, like my first tech writing role, it might have been a lot more fun. Instead I went over at the same level, and I ended up in a position where a lot of people expected me to know how to do things that I had no idea how to do. Similar to documentation at that company, I worked on a team. But that team dynamic for product management was such that no one talked about processes or their strategies for getting things done. It wasn’t the sort of environment where people collaborated on that sort of thing. It was a similar structure but a completely different vibe. That was a huge part of what drew me back to documentation and to my team specifically, being able to collaborate and have that hive mind that could provide perspective on ideas I was working on. That whole experience was a lesson on team dynamics being more important than I expected.
What advice do you have for aspiring technical writers looking to break into the field?
Evaluate how you find value. Where do you get value from work, whether it’s by producing tangible results or by having lots of discussions with people? What makes you feel productive when working? Have a good sense for that. But also keep track of what your side interests are. If you show up to work and the only thing you want to do all day is just write, you might end up pretty bored. So you should have some side projects or some sort of corollary interests that might support your tech writing, like data analysis or something else that you can use to keep yourself occupied. I try to pay attention to what’s being discussed in the industry, whether it’s by following Write the Docs, blogs, or Twitter. I’ll try to see what other people are doing that maybe I’m not doing and see if I can bring some of that back to my work.
Sarah goes by smoir on the Write the Docs Slack group. You can find her in the #analytics and #career-advice channels.
