Meet Suzanne Rubinstein: Mapping the Way Through Technical Writing

Gowri: Good day, everyone, and welcome to the Knowledge Base Ninjas podcast. With me today is Suzanne Rubinstein, a technical writer at TruLogix Software.

Hi, Suzanne. It’s a great pleasure to have you on the podcast. Before we begin, could you tell us a little about yourself? How did you join the technical writing community, and how did you choose this as your career path?

Suzanne: I always joke that nobody really says, “Hey, when I grow up, I want to be a technical writer.” But it’s actually an amazing career, and my path was definitely not linear.

I worked in government for a while and then in tourism. After becoming a mother, I found that motherhood and government didn’t really mix very well, so I got an amazing job in education.

I was one of the first generations in Mexico to be recognized as an Apple Distinguished Educator. Then we did Google schools, so I was really immersed in education, but always in technology.

For some reason, I didn’t really appreciate that being good at technology was actually a talent and not something everybody is good at. I naturally became the person who would have to explain everything whenever somebody had a technology-related question.

That path takes you directly to technical writing if you’re lucky.

I got certified and moved from education into a private company, where I stayed for about five years. After a couple more changes, that’s where I am today.

Gowri: You describe yourself as “insatiably curious.” What does that mindset look like in your day-to-day work?

Suzanne: I think it’s vital for most technical writers because usually you’re writing about things that you don’t know. Whenever you move to a new industry, there’s so much to learn.

For some people, that can be daunting because they specialize in one area of their life, and that’s what they do. As a technical writer, you have to specialize in whatever you’re writing about.

So, if you’re not a curious person who actually wants to learn, it’s not going to be easy for you. Luckily, I love to learn. I love learning not just about what I’m documenting, but also about tools.

It’s always fun, and my brain stays happy because it’s busy.

Gowri: Does learning more about a subject always make it easier to explain, or can it sometimes make writing harder?

Suzanne: I think generally it makes it much easier—but not necessarily for everyone.

If you understand a subject really well, you can sometimes breeze through the steps and explain something very simply. But the person you’re explaining it to may not understand because you went too fast or skipped steps. That’s where they get lost.

A good technical writer not only deeply understands the subject but also understands the audience.

That’s where you slow down and go step by step, explaining everything you need to in order to create documentation that’s actually useful.

Gowri: How do you know when you’ve learned enough about a technical topic before you start writing about it?

Suzanne: I never write about anything unless I’m able to reproduce it myself. That’s part of my principle.

Whenever I’m writing about something, I ask for access to a development environment, test credentials, or whatever I need. But it’s not just about reproducing what the subject matter expert tells you happens.

I want to go in there and check everything step by step.

That’s usually really good for the company as well, because we always find typos or small issues along the way. So they get QA and a technical writer in one.

By the time I’ve finished reproducing all the steps, I understand the process because I actually did it. That’s when I go back and start documenting the steps.

Gowri: So until you’re convinced about the process and understand it, you don’t start writing?

Suzanne: Exactly. Otherwise, you’re just a ghostwriter.

Gowri: What happens when a technical writer stops being curious?

Suzanne: That’s a really hard question to answer because the first thing that comes to mind is that the person may be getting burned out.

And it happens. There’s no shame in that.

Technical writing is a weird career because sometimes you have two weeks where there’s nothing and you’re just coasting along thinking, “Oh my God, do I still have a job? Will they still need me?”

And then suddenly, 50 urgent things get dumped on you, and they’re all needed yesterday.

That’s when you probably stop being curious because you’re just working in nonstop “resolve everything” mode.

Gowri: So it’s more a symptom of the situation you’re in than the technical writer not doing their job correctly?

Suzanne: Exactly.

Gowri: Is there a point where experience can become a barrier to picking up something new? When you gain a lot of experience, is it possible to become complacent and think, “I already know about that”?

Suzanne: Not really. I think technical writing is one of those careers where more experience actually tends to make you a much better technical writer.

Not that younger technical writers don’t have their own space—everybody does. But the more experience you have, probably the more empathetic you become toward beginner readers and more advanced readers.

You’re also probably a better mentor if you have other technical writers working with you.

I’ve worked with younger technical writers who are just starting out, and it’s so much fun to help them navigate those things that you only learn through experience.

Suzanne: I saw an article the other day where somebody was asking, “What’s more important: documentation being clear or being concise?”

I think that’s a bit of a beginner question because most of us know that it has to be a balance.

Documentation always has to be very clear and complete, but you need to understand your audience.

If I’m explaining to an engineer how to turn on a computer, it is complete—it’s just not useful.

Gowri: So it all comes down to the person who’s going to be reading your content. That matters most in the end, doesn’t it?

Suzanne: Yes. I would say audience is king.

Gowri: You read a lot of content. Is there anything interesting you’d recommend to our audience, particularly documentation-related blogs or books?

Suzanne: I would be remiss if I didn’t mention a book that just came out, where I have a chapter: Women in Technical Writing. It’s an amazing book.

It’s not a technical book that will teach you to be a better writer, but it will teach you to trust the journey, understand what’s going on, and get an overview of what fellow technical writers are doing.

In the end, the technical writing community has been the strongest resource for me in learning and continuing my path.

It’s a book I highly recommend, and it’s also a really fun read.

And although Reddit gets a bit of a bad rap lately because of all the AI-generated content, there are treasures to be found. The Reddit technical writing community is a very strong resource for everybody.

Gowri: What is the one word that comes to your mind when you hear the word “documentation”?

Suzanne: Map.

If you know where you’re walking and what you’re doing, you absolutely don’t even think about a map. You’re just walking and everything is fine.

If you’re using whatever software or hardware, you don’t even think about documentation.

But the second you get lost, the first thing you do is ask, “Where’s a map?”

And that’s what technical documentation needs to be.

Gowri: What is the one piece of advice you would give to your 20-year-old self?

Suzanne: I would say, trust the process.

I was jumping around careers, enjoying it, but also very worried about what would happen in the future.

I think we all, at some point—even now, even in a stable career—worry about what’s going to happen in the future.

If you do a good job and keep focused on what’s important, trust the process. You’ll get there.

And don’t ever, ever stop learning. That’s for me and for anybody. Learning is magic, so don’t stop. Ever.