By: Jules Millward
STC Carolina President Arthur Berger graduated from the MSTC program in 2017 and now works at a startup as a technical writer, having previously worked for large companies like IBM and RedHat. He started out as a freshly graduated English major and worked as a proposal writer for a small government Defense contracting company for several years before considering graduate school. During this time he was able to explore different roles in a business — including documentation, HR operations and recruitment, and management — and ultimately discover his preference for engaging with subject matter experts to develop documentation.
Arthur joined the MSTC program to diversify his skillset and gain a better understanding of the field of technical communication. While part of the MSTC program, Arthur gained experience by completing the Digital Humanities Certificate, instructing as a Graduate Teaching Assistant, and interning as a proposal writer at Red Hat.
“My internship exposed me to a lot of different things and gave me a taste of the tech world. It really solidified that I liked, and could do well in, that kind of environment, which was a concern of mine. There are all different types of technical writing, and some are more abstract like software — and I’m not a coder or anything like that — but my internship at Red Hat definitely convinced me that there is a place for me in tech comm.”
Arthur earned a job at IBM upon graduation, and he worked there for five years before switching the startup company where he currently works. In the Q&A below, Arthur graciously shares with us some of the wisdom he’s gained over the years working as a technical writer in the cloud computing software development arena.
This interview has been edited for length and clarity by Jules Millward, the 2021-22 TCA Secretary.
Q: What MSTC courses have you found to be most applicable in your technical writing experience?
A: Many of the MSTC courses are applicable to what I do in the workplace, especially the Advanced Writing & Editing and the Usability Studies classes. For example, in Usability Studies, you’re actually learning to build personas and test users of a product, which was useful for what I did at IBM. When I first started there, they didn’t necessarily have a billion things for me to do yet, so it’s a good project to kind of shift your starting assumptions or get a baseline, like if you’re rolling out a totally new version of something and you want to see if it’s actually meeting user needs.
I would have loved to have done more usability stuff more regularly in my roles — it’s not something that I’m required to do, but it’s super helpful and nice to have in your back pocket as it’s not something everyone can do, and even in tech writing most people aren’t trained for usability. So that was kind of nice and affirming that the MSTC program is almost ahead in some ways than some other buzzy programs, like systems designs. Even the more abstract courses, like Online Information Design or Verbal Data Analysis, still exposed me to different ways of approaching a problem. For example, a content problem and thinking about how can I actually collect information to help solve this, and how can I order and structure the information to achieve certain objectives. So I think that those broad brushstroke takeaways are nice to have from the variety of courses within the MSTC program.
Q: What does a typical workday look like for you?
A: The first thing that I do is write out my main tasks for the day in my physical planner — even though I have a Google Calendar and Slack will ping me when meetings are about to start — I like getting a visual picture of where my chunks of time are going. This helps keep me on task too, in terms of prioritizing tasks and being realistic about what will get done that day. Then checking emails or slack messages, maybe customer tickets, etc. to see if anything new popped up or if anything needs to kind of take priority over what I’m currently doing. This initial planning and triage is important because, especially at a startup, priorities can shift quickly.
In terms of doing the work, most of what I do is straight documentation and research. So I develop reference docs, which involves a lot of checking things, finding answers, and figuring out where that information best fits in a document. I might generate research questions for development leads, develop an outline after our discussion, figure out how to best present that information, and then start writing. I am a proponent of writing from scratch, but I will say that the amount of time that you’ll spend reviewing might take you back at first. But reviewing is another big part of what I do everyday — I can’t think of the last time there was a day where I didn’t have some sort of peer review process going on.
Another area that I spend a lot of time on is developing diagrams for the documentation. Docs in general are being pushed to be more interactive and more visually appealing, and there’s a focus on reducing the amount of content. I found that having diagrams and showing them to people is a great way to find out what they actually know and think about something. Diagrams are great because they’re very visual and they can help you move around, and assess understanding. So I would say that’s primarily what I do day to day, besides just kind of attending meetings and just kind of listening in on different things, and maybe asking some questions here and there.
Q: What technology/software have you used in your technical writing jobs?
A: Adobe Illustrator, Adobe Photoshop, GitHub, Atom, Zoom, Slack, Google Drive, Microsoft Office, Slab, Draw.io, Excalidraw, Node.js, GoLang, rest API, Markdown, Hugo, Html, CSS
Q: What is your favorite aspect of what you do as a technical communicator?
A: I think one of the most rewarding things at the startup, is the immediacy of feedback whether it’s from customers or coworkers. Seeing the energy and how happy people are when they realize that you care, that someone is actually working on a problem that they have, and that they’re making changes based on the feedback is super rewarding. Realizing that what you do is making a big difference in somebody’s day – for example if someone needs an answer for something and they can’t find it and are getting frustrated, being able to provide that answer is great.
I think here’s this trend to make things as “sexy” as possible, kind of like the Apple brands of the world, but they also might have left behind a lot of people. So there are these complicated technologies that have a high barrier of entry, and it’s hard for people to figure out what these new concepts mean and how it impacts their work and their lives — It’s incredibly rewarding to realize that you’re helping to demystify this stuff and make it useful for them.
Q: What are some current challenges you face as a technical communicator?
A: Working with software development can be challenging, especially with code ownership, changes, and formatting issues. So I might research a topic that involves reading the code comments or looking at a code itself and trying to figure out the best way to automate or update it. And throughout this, there’s definitely an element of taking a step back and thinking “okay, after I do this task is there any way to make it better or make it more manageable down the road?”
I’m still trying to learn how to do that better because it’s definitely not a writer’s task because we don’t know how to develop software. But I think that, in my mind, I consider that content operations, and I think that’s going to be an interesting, growing aspect of tech comm in the upcoming years because I think more of us are getting more comfortable with technology and we’re trying to say, “Hey we could actually develop some things ourselves to solve tech writer problems”, because one thing about working at a startup is that these tools I’m using were developed for developers, not with writers in mind. So a future move in tech comm might be learning how to develop for the writer. You know there’s always something else to learn with technology, and it can be confusing and it’s not something that you personally do in your day to day job. A common mantra is “you are not your users”, but there’s still the challenge of how do you gain enough familiarity with it to get by and to do what you need to do.
Q: What is your biggest piece of advice for MSTC students preparing to enter the tech comm industry?
A: Don’t assume that just because you don’t know something that you’re not good at what you’re doing or that you can’t do something. I know, people talk about having imposter syndrome, especially if you come from an English background. But if you’re thinking “I don’t know if I can do this” remember that literally billions of people can’t do this either so you’re going to learn as you go. Be open to learning, and reach out to others if you need help or want to learn more about something.
I think one way that you get better at something is helping other people — teaching them and showing them what you know, and then seeing what they know and kind of doing this collaborative feedback process. Finding a good sounding board or fellow tech writer can be helpful in that way, and tech comm has communities for that too.
The Society of Technical Communication (STC), the IBM Pathfinder program, or even chatting with your fellow MSTC grads are all great resources. Networking or sharing, whatever that might look like for you, but finding some way to kind of share with people is important for helping feel more comfortable, more confident, and then figuring out where you might want to go next.