From Developer to Tech Writer: How AI, Empathy and Localization Shape Modern Documentation

Gowri Ramkumar: Welcome, everyone, to the Knowledge Base Ninjas podcast. Today with us we have Rutva Safi, senior technical writer with Gantner. Hi, Rutva. Welcome to the Knowledge Base Ninjas podcast. How are you doing today?

Rutva Safi: Hello, Gowri. Thank you so much for inviting me to the podcast today, and I’m doing pretty well. Thank you for asking. How are you doing?

Gowri Ramkumar: All good. So it’s all going great on my side, and once again, thank you for your support in this episode. So before we start with anything, how did you get into this wonderful journey of technical writing? Who was your inspiration or motivation? Can you shed some light on that, please?

Rutva Safi: It’s actually a very interesting story because my career graph has never been linear. I’m an engineer by trade, and I started my career as a developer. But very early on, I realized coding wasn’t something I truly enjoyed.

I still wanted to remain in the tech industry because technology fascinated me, so I moved into a Quality Analyst role. Later, I transitioned into a Business Analyst role. I kept exploring different areas until I discovered what I genuinely loved doing.

At the same time, I had started writing blogs and articles. I even created my own website where I shared my thoughts and ideas. One of my friends read my blogs and suggested, “Why don’t you combine your writing skills with your technical knowledge?”

That idea completely changed my direction.

I then moved into a content writing and strategy role at an IT organization, where I wrote about technologies like AI, Machine Learning, IoT, Virtual Reality, and Augmented Reality.

Later, an internal technical documentation project came up, and my tech lead asked me to take ownership of it because of my technical background. That’s when I realized I had the ability to understand complex engineering concepts and explain them in simpler, user-friendly language.

That became my turning point. From there onward, I moved fully into technical writing roles, and today I’m very happy working as a Senior Technical Writer at GANTNER.

Gowri Ramkumar: AI is rapidly changing how documentation is created and consumed. How do you see the role of technical writers evolving in this AI era?

Rutva Safi: That’s definitely the million-dollar question today.

AI is transforming industries at an incredibly fast pace. Personally, I see AI as a collaborative assistant — something that helps us work faster and more efficiently.

A lot of people fear that AI will replace technical writers, but I don’t believe that’s going to happen anytime soon.

AI can definitely help with simplifying information, restructuring content, and generating drafts much faster than humans can. For example, if I’m dealing with a complex scenario and need to break it down clearly for users, AI can help speed up that process significantly.

But there’s an important difference between AI that writes and a technical writer who uses AI to write.

AI doesn’t truly understand the product the way humans do. It doesn’t understand user frustration, emotions, urgency, or real-world edge cases.

Imagine an airport check-in system crashing while customers are waiting in long queues. The employee handling the system is stressed and under pressure. AI cannot fully understand the emotional and practical realities of such situations.

Technical writers, however, can.

We understand products deeply. We understand users. We understand empathy.

That human perspective is something AI alone cannot replace. The future is really about humans and AI working together.

Gowri Ramkumar: Can you walk us through your documentation process and how your current role works?

Rutva Safi: Absolutely.

A lot of people assume technical writers simply sit down and write documents. But documentation actually begins much earlier.

For me, the process starts with sprint calls and product discussions. That’s where I learn what features are being developed, what changes are happening, and what challenges teams are solving.

The first stage is information gathering.

I ask questions during sprint meetings, collaborate closely with developers and product teams, and then I personally use the product myself. I strongly believe that technical writers should become the first real users of the product.

If you don’t experience the product yourself, it becomes very difficult to write documentation that truly helps users.

Another important thing is that documentation should happen alongside product development — not after development is completed.

Documentation is part of the product. It is not an afterthought.

When I write documentation, I also involve business analysts and product managers to understand edge cases and real-world scenarios.

For example, instead of simply writing “Click Save,” I explain:

• Why the user should click Save
• What happens after clicking it
• What could go wrong if they don’t

That additional context makes documentation genuinely useful.

I also spend time thinking about:

• Information architecture
• Terminology consistency
• User personas
• Navigation flow

Because documentation is never written for just one type of audience.

In SaaS products, you may have:

• End users looking for quick task guidance
• IT admins configuring systems
• Developers integrating APIs

Each audience has different needs, and documentation should support all of them.

Gowri Ramkumar: Your product serves a global audience. What are some common mistakes companies make when creating documentation for international users?

Rutva Safi: One of the biggest mistakes companies make is confusing translation with localization.

Translation is simply converting words from one language to another.

Localization is much deeper.

It involves preserving meaning, tone, cultural understanding, and context.

When you know your audience is global, you need to think about localization from the very beginning of the documentation process.

For example, idioms or culturally specific phrases may completely lose meaning when translated into another language.

A phrase like “burning platform” may make sense in English, but when translated literally into German or Japanese, it becomes meaningless.

Another major issue is date and time formatting.

For instance, a date written as 01/02/2026 could mean:

• January 2nd in one country
• February 1st in another

If time zones and formats are not clearly explained, it can create serious operational issues for users.

This becomes especially critical in SaaS products where scheduled reports, automation workflows, or system configurations depend heavily on time settings.

The goal of localization is to ensure that a customer in Mumbai, Melbourne, or Munich interprets the documentation exactly the same way.

That consistency is incredibly important.

Gowri Ramkumar: Are there any resources you’d recommend for aspiring technical writers?

Rutva Safi: Definitely.

I regularly follow:

• Write the Docs
• TCWorld Conference

I also follow industry experts like:

• Karl Isak
• Tom Johnson

And of course, podcasts like:

• Knowledge Base Ninjas
• The Not Boring Tech Writer

These are all excellent resources for learning and staying updated.

Gowri Ramkumar: One word that comes to your mind when you hear the word “documentation”?

Rutva Safi: Foundation. Documentation is the invisible infrastructure behind every successful product. It creates structure, clarity, reliability, and trust for users across the world.

Gowri Ramkumar: What advice would you give your younger self?

Rutva Safi: Keep learning. Keep exploring. And don’t be afraid to try different roles early in your career.

Every role teaches you something valuable.

Being a developer, QA analyst, or business analyst helped me understand different user perspectives — and that eventually made me a better technical writer.

Every experience becomes part of your journey.

Rutva Safi: Use AI as a collaborative support system, not something to fear. AI is not here to replace us. It’s here to help us create better experiences.