Carolyn Carpenter graduated from the MSTC program in 2013 and is now a ContentOps Lead and Content Strategist at IBM, where she has worked for the last ten years. Carolyn completed her Bachelor of Arts in Linguistics and German with computer science classes mixed in.
When looking for a field that combined language and computers, Carolyn found the MSTC program at NC State. While in the program, Carolyn maintained her technical focus by taking courses, such as Human-Computer Interaction and Digital Humanities, while participating in the IBM-NC State Pathfinder program as a mentee.
“The IBM-NC State Pathfinder program gave me a window into what it’s like to be a technical writer for a tech company and helped me understand the day-to-day of a technical communicator, which can be so nebulous. Interacting with my mentor and engaging in internships were eye openers in understanding what the role entails.”
While in the MSTC program, Carolyn worked as an information development co-op at IBM and, upon graduating from MSTC, started working full-time at IBM in that same role.She continued working as an information developer for six years before transitioning to her current role — ContentOps Lead and Content Strategist for the IBM Cloud docs.
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: The top three courses are Human-Computer Interaction, Usability Studies, and Information Architecture (Online Information Design & Development). The Human-Computer Interaction class focused on how people interact with computers, with a touch of software engineering processes, and I work with software engineers everyday. Similarly, I work on user interfaces everyday with our Cloud Docs website, so having foundational knowledge of best practices and why they matter from the Usability Studies class is invaluable and critical to designing a good user experience. For example, in my role I integrate those best practices, and combine them with IBM’s own design guidelines, as I work with user interfaces to change elements like where fields are displayed within our API Docs framework.
I also frequently use the principles for organizing information I learned in the Information Architecture class. For example, I do a lot of content strategy mapping, so I use the card sorting techniques I learned there to support grouping together like content into where we might need it, to be displayed on our different properties.
Q: What technology/software have you used in your technical writing jobs?
A: Markdown, GitHub, marked-it-cli (our open source Markdown parser), Jenkins Travis CI, automated quality and code validators, Slack, Box, Webex, API tools
Q: Do you follow or operate within a project management model?
A: Agile* — In an organization this large, it’s always Agile with a little asterisk because we aren’t truly free-flowing from iteration to iteration, and we have a master roadmap and plan to make sure everybody’s aligned. But we are largely Agile, in that we work in two weeks sprints, have sprint planning and daily scrums, and do a retrospective and playbacks at the end of it.
Q: What does a typical workday look like for you?
A: A typical day starts with a scrum with our development team for the IBM Cloud docs website and build pipelines, where we figure out what features we’re going to be working on during the day. I then provide input from a content experience perspective and then do testing to validate that input, after they’ve developed the new features, to ensure the features are functioning as we expected them to and aren’t introducing any other bugs to the framework. Then, throughout the day, I answer any questions that developers might have about the process or content and I answer questions on Slack from content contributors, which can include writers, developers, and product managers.
I also support the build system as our build lead. We have a centralized build system for all of the hundred-plus people who write content for IBM Cloud platform,which takes the Markdown-based content, transforms it to HTML, and publishes it to our IBM Cloud docs site. I support writers that use our build system by helping to answer questions around it, such as “My topic isn’t showing up, what’s going on?” or “How do I make a note or other topic element be styled in a certain way?” or “How do I get my API docs to appear like I want them?”, and so on. So I’ll either be answering those questions myself or helping our other build focals to answer them.
In addition to answering writers’ questions directly in Slack, I also write internal documentation that describes content guidelines, Markdown coding best practices, our automated tooling and how to troubleshoot it, and more. Just like with our external customers, internal docs help our writers learn about how to deliver content according to our standards and self-solve if they have any issues!
Q: What is your favorite aspect of what you do as a technical communicator?
A: Helping other people be successful — I get to design processes and write documentation that help make other writers’ jobs easier and help them if they run into a jam. That’s rewarding to me because I used to be in their shoes as a writer, and now I get to work with hundreds of writers, help them be successful, and see the relief on their faces when I help them deliver their docs.
Q: How have you seen the role of technical communicator evolve?
A: Project management used to be more Waterfall, with a project plan and everyone doing their individual pieces, but it’s now more Agile with technical communicators being integrated with development teams rather than being a final step in the overall product delivery process. Along with that, there’s been a shift in technical communication from being focused only on professional writers to encompassing content contributors from various backgrounds, which includes writers, developers, product managers, etc. as people who contribute content to a project.
We now do more content design and provide more input into the user experience within the product user interface — so, at least on my team, what that means is providing UI content like field labels, tooltips, or links to the documentation, enforcing a common product terminology, and being involved in the end-to-end content experience, rather than just that final editing and review piece.
Q: What are some challenges you face as a technical communicator?
A: There’s always more work than we possibly have the people to deliver. We have all these cool ideas for things we want to do and it’s always a matter of prioritization because we can’t get everything done. It tends to be a struggle in the industry to get enough people to work on documentation delivery because it often isn’t considered a priority.
Another challenge is showing value as a technical writer, and answering people who ask why they should invest in a good technical writing team. We need to be able to talk about and demonstrate our value added. For example, we can add value by bringing the user’s perspective, thinking through documenting how users use the product – not how the developers think the product should be used – and answering their questions before they even have them. So putting in the work and doing the research to better understand the product, and then the users as well, is so important.
Q: What skills do you value in technical communicators you work with and/or hire?
A: I value people who can do their own research and research independently — that’s honestly ~75% of a technical communicator’s job role. For me, as someone who has interviewed new people for our team, seeing that people can do research, ask good questions, and not be intimidated by the unknown is important. Our job as technical writers is to document things that are constantly changing and not already documented fully, so you need to be able to do that groundwork yourself.. That’s important, not only to produce good documentation, but to build rapport with the people and SMEs you’re working with. Nobody wants to rehash the basics of a concept from nothing when a writer could have tested the product, read existing documents available, or done some preliminary research. Being proactive in gathering information and independently learning is probably the most overarching skill that anybody should have. You gotta love learning and be willing to go after knowledge.
Q: What is your biggest piece of advice for MSTC students preparing to enter the tech comm industry?
A: It’s important to get an internship, mentor, or some other experience to gain insight on the industry and figure out if you like certain job roles. There are so many different fields or areas you can go into with a tech comm background, students may not have insight into what it really entails to do the day-to-day work. You don’t want to get a degree where you’ve spent two years training for something only to find out you don’t like the work!.
Networking – not necessarily networking where you rub elbows and impress people, but networking to learn of others’ experiences – is in that same important vein of figuring out what’s out there in the tech comm industry early on.
Get involved with the industry through an internship, a mentor with the IBM-NCSU Pathfinder program, meet-ups for your areas of interest, industry communities like Write the Docs, student organizations like TCA, and technical communication conferences — like TCA’s annual SpeedCon where students, alumni, and industry professionals can share knowledge and experiences.
And finally, don’t be intimidated by technical skills you may not have. For example, you may not know what working on Cloud computing docs means, but nobody does until they start working on it themselves — don’t be afraid to not know things, don’t be afraid to learn. You’ll develop skills as needed, and as long as you have the basic aptitude for writing and learning you’ll succeed anywhere!