Writing Is the Smallest Part of Technical Writing: Understanding the Broader Role with Strahinja Milošević

Gowri: Good day, everyone. Welcome to the Knowledge Base Ninjas podcast. With me today, I have Strahinja, Senior Technical Writer at Bitvavo. Welcome to the podcast! I’m excited to learn about your 10+ years in this space.

Before we begin, let’s start with your journey. How did you first get into technical writing, and how has that journey evolved as tools, teams, and expectations have changed?

Strahinja: I studied English, and where I come from, people usually expect you to pursue a career directly related to your degree. After trying a few roles and figuring things out, I stumbled into technical writing—like many people do.

I was always interested in technology—computers, guitars, video games, and new tech in general—and I wanted to use my language skills in a technical environment. Technical writing turned out to be a natural fit.

Gowri: You work closely with tools like Docusaurus, GitHub, and internal engineering systems. How does working close to code and developers influence how you think about documentation?

Strahinja: Conceptually, not that much. The goal is always the same: pass on the right information so users can accomplish what they need to do.

However, from a workflow perspective, working closely with developers is very rewarding. You begin thinking like them—using version control, integrating tooling into your daily workflow, and adopting engineering practices.

Docs-as-code has been a major topic in our space. But ultimately, whether you use an XML editor, a CCMS, or the same tools as developers, the core purpose remains the same: pass on knowledge clearly and effectively.

Gowri: With AI, automation, and docs-as-code becoming more common, do you see AI as more of an assistant or a disruptor?

Strahinja: Both.

There’s a lot of discussion around “augmented” professionals—like the idea of a 10x developer. That same conversation is happening in technical writing. AI can help with drafting, refining content, assigning personas, and critiquing drafts—it’s powerful.

But we often forget that large language models are trained on structured, purposefully created content—much of it written by technical writers. The structured, topic-based approach we use is exactly what makes AI output readable and useful.

Some people worry about being replaced. I don’t see it that way. AI changes how we work, but it doesn’t remove the need for us. It automates parts of the journey and allows us to do more in less time.

I’m currently a team of one, embedded in engineering. Without AI, I would need additional writing and review support. It’s a tool—just like any other technological advancement.

Gowri: What do you think cannot be automated in documentation?

Strahinja: Communication.

If nobody gathers the information, tests it, validates it, and understands it, there’s nothing to automate.

Writing is actually the smallest part of the job. Seventy to eighty percent of technical writing is gathering information, testing it, breaking things, reviewing, discarding what doesn’t work, and finding the little nugget of truth that remains usable.

Human coordination and communication cannot be automated.

Gowri: What conversations are you seeing around the future of technical writing?

Strahinja: Right now, it’s all about AI and LLMs—similar to how microservices once dominated conversations.

Some say traditional technical writing is becoming obsolete. I disagree. People will always need content curation.

Documentation is a product. If we don’t define what that product should be—who it serves and how it fits the market—AI alone won’t get it right.

AI can build, but someone has to define what should be built.

Gowri: Are there trends in technical writing that aren’t talked about enough?

Strahinja: Yes. Documentation is becoming operational—not just instructional.

We’re shifting from writing only for humans to also writing for machines. Chat-based systems now search across entire knowledge bases. Tools scrape, index, and serve documentation content.

This means we must create documentation that works well for both humans and AI systems.

Not everyone is adapting to this shift. Some writers feel protective of traditional craft. But instead of resisting change, we should embrace it and use it as an opportunity to advocate for our value.

Gowri: What resources would you recommend?

Strahinja:
• The Write the Docs community—especially their Slack channels.
• Google’s short technical writing courses for beginners.
• Tom Johnson’s blog, I’d Rather Be Writing, for API documentation.
• Jill Shaheen’s portfolio and blog.

Gowri: When you hear the word “documentation,” what comes to mind?

Strahinja: Goals. Purpose.

For me, documentation serves a clear outcome. It sits perfectly between language and technology, which is why it fits my personality so well.

Gowri: What advice would you give your 20-year-old self?

Strahinja: Don’t let people put you into a predefined category based on your degree. Explore. Try things. You might fail—but you might also discover something meaningful.

Just write it down.

It doesn’t have to be technical writing. It doesn’t have to be creative writing. Write ideas, expenses, thoughts—anything.

Writing reinforces discipline and improves retention. You don’t even have to publish it. But writing things down matters.

Disclaimer: This transcript was generated using AI. While we aim for high accuracy, there may be minor errors or slight timestamp mismatches.