Featured Technical Communicator: Jody Winter

July 2022

A photo of Jody smiling - she has hair hair pulled back, is sitting at a table holding a white mug of coffee and is wearing bright red nail polish.Jody Winter is a Documentation Specialist/Freelance Technical Writer, working for Affinity Employer Services (full-time) as well as various freelancing gigs (currently Redocly).

You’ve likely seen Jody on the TechCommNZ Slack, as well as many other places online. She has been a technical communicator for almost 20 years, so we’re excited to get a peek into her amazing work, experience, advice and recommendations.

Here’s what we asked Jody.

How long have you been a technical communicator and how did you start out?

After previous careers in accounting and project management, in 2003 I took a year out to retrain as a technical writer. I did the GDID full-time that year, with an unpaid internship at SKYCITY at the end. 2024 will mark my 20th professional year in the field.

What does a typical work day look like for you?

I work my main job at Affinity from 6.30am until about 3.00pm, then a few days a week, from about 3.15pm I work a few hours for my client which is currently Redocly. At Affinity, I provide writing and editing services to the entire organisation alongside maintaining our end-user help, so there are no typical days! For Redocly, I am currently focussed on their open-source docs and I typically concentrate on one function at a time.

What kind of content do you create?

For Affinity, I create and maintain end-user help and build internal knowledge assets. I’m also responsible for UI/UX language and consistency for on-screen elements and messaging. Soon I’ll be trying my hand at blog articles to support our new Sales and Marketing team. I joke to our marketing manager “they beat the creativity out of you when you become a tech writer”. It’s a new style of writing for me, but I feel very supported.

For Redocly, I’m currently editing and testing docs that support users of their open-source products. I also recently developed API reference docs for another client. I use the docs-as-code methodology for this type of work.

Are there other technical communicators in your workplace? How many?

At Affinity, it’s just me. I’m their first — and so far only — tech writer. At Redocly, I work with two other writers: one based in Croatia and the other in Ukraine. I feel very lucky to experience both 100% autonomy in my main job, and to be a part of a team of writers in my freelancing work. When freelancing, I’m typically brought in as a specialist resource because many organisations don’t have a full-time tech writer.

Do you work with subject matter experts or product owners? How?

All the time and with both. For technical content, collaboration can take the form of emails, Slack or Teams messages, and meetings. In my main job and in freelancing, I work with people from all over the world so time zones can get a little interesting when securing SME interviews! But mostly, SMEs are happy to engage, and we always find a way.

Did COVID-19 change your role? If so, how?

Not really. I was already working from home three days a week. Affinity has a very flexible approach to work, plus a global workforce. So back in 2020, when lockdowns were first announced in our respective countries, we all made that transition pretty seamlessly.

What tools do you use to do your work? Are there any you recommend?

At Affinity, I use Author-it to manage end-user help content. I have always found it to be a total workhorse, very reliable, and perfect for our needs. I’ll probably review our use of it next year because our content needs are changing, and we have some exciting product developments in the pipeline which will require a different approach to user support. I use Camtasia to make video content and it’s easy to learn and easy to use. I always recommend it. Audacity is fantastic for slicing and dicing audio, and Amazon Polly is a must for producing text-to-speech narration.

When I’m working on docs-as-code projects, I use whatever source control system the client/project uses (to date, just GitHub). GitHub Desktop is also a must when I’m dealing with a bunch of individual files for larger projects with lots of branches because I can work on them locally and submit my changes in a pull request when I’m ready. This is especially useful for docs because they take time, and the review process in GitHub is great for docs as well as code. I have used Stoplight for documenting APIs (both reference and conceptual docs), Postman for testing API calls, and Visual Studio Code for authoring YAML and Markdown. Dillinger is also great for authoring Markup when you need to see a preview of the layout.

Which parts of your role do you enjoy the most?

At Affinity, I enjoy editing the work of others and helping them to get to a concise, clear message. I also enjoy managing the naming and describing of all of our database elements. Outside of my main job, I enjoy documenting APIs. I get the best of both worlds: the discipline of documenting the API schema, and the creativity of helping developers understand and consume the API. So far I’ve only had limited exposure to writing API docs, but I am always on the lookout for more opportunities so I can become an expert in it.

Do you user test any of your content?

As much as possible myself, otherwise the SME will test (with some guidelines from me).

How much focus does your team put on using plain language?

At Affinity, we implemented a common language initiative about three years ago which makes plain language a cornerstone of UI/UX enhancements and general communications we send to customers. Whenever I offer editing services — either in my main job or to a client — I always go for simple language.

Can you tell us about a rewarding project you've been involved in lately?

There are so many! In 2021 I spent several months documenting my first API. How this work came about is hilarious. I was a total badass with this one and threw myself at a great opportunity when it presented itself. Read all about it here. I’m also chief writer on the docToolchain open-source project which is based in Germany but has contributors from everywhere. It’s very much a work in progress, with many pages still needing an edit but we’ll get there. I love collaborating with my colleagues from Nigeria, Germany and the Czech Republic. Our Zoom meetings are a melting pot of accents! I also need to mention my current work with Redocly which is helping me to learn products that are used specifically to document APIs. I feel like I’ve won the lottery with my Redocly gig!

Can you share any examples?

My portfolio is here. It only showcases very recent work, but it gives people an idea.

What advice would you give to someone starting out as a technical communicator?

Is there anything else you’d like to share with us about the work you do, experiences you’ve had or your thoughts on technical communication in general?

Whether you’re new to tech writing or a seasoned professional, my advice would be to get outside of your comfort zone as much as possible. The world of technology is changing, and organisations’ expectations of tech writers along with it. You will never get all of the professional growth you need from one job. I have always been completely honest with my main employer about my need to freelance, and they actually benefit because I pick up some amazing new skills.

I also encourage writers to embrace different ways of writing and producing documentation. Not only is it a great challenge but it will make you more attractive to future employers and keep your skills sharp. I did this by joining open source projects and being available for freelancing work.

If you’re time-poor or simply not in the zone to tackle a big learning curve, how about joining an online community and just watching and listening? Write the Docs has an amazing and supportive Slack. And our own TechCommNZ community is very generous when you tap into it. I am also a part of the apidays Women in APIs initiative. They have a quarterly online catch up and a friendly Slack community. I’m also a mentor via Coffee Chat and so far have mentored two young software developers in the dark arts of tech writing: one in the States and one in Nigeria.

Grow your network on LinkedIn. Share your ideas, experience and expertise as much as possible. I write a blog (new subscribers welcome!) and it’s been a great way to document my recent API docs journey.

Ngā mihi nui, Jody!

Thank you so much for sharing your knowledge, experience and passion with us. We love your work!