Why Technical Writers Need Professional Standards | Mikhail Ostrogorskiy

Gowri: Welcome to the Knowledge Base Ninjas podcast. With us, we’ve got Mikhail Ostrogorskiy, an independent technical communication consultant and researcher. Mikhail, it’s great to have you on the podcast. With nearly 30 years of experience, how did your journey begin, and how are you enjoying it so far?

Mikhail: This November, I’ll celebrate 30 years in the profession. I started when I was still an undergraduate studying math and programming. I began writing to make some money. Software was what I knew, so naturally, I wrote about software.

But soon I discovered something about myself. I was too honest to write advertising materials, and I wasn’t sarcastic enough to become a proper journalist. So I talked to a few software companies I’d written about and convinced them to hire me to write user manuals instead.

At that time, I didn’t even know I was a technical writer. Other people had to tell me. Later, I built my own technical-writing business. We documented software and business applications, trained technical writers, and helped companies build and manage their own documentation teams.

We often worked with entire families of products and several projects built on the same platform, so automation and single sourcing were very important to us. They saved us a lot of time and effort. A few years ago, I stepped away from that business. These days, I work as an independent professional.

Gowri: Congratulations on 30 years in the profession.

Gowri: To start, what does a professional standard mean for technical writers?

Mikhail: We’re technical writers, yes, but first of all, we’re human beings, and we cannot live in isolation. We need to belong and create community. That’s just how humans work.

In a community, we help each other and share experience, knowledge, and resources. In the past, people were usually born into a community—a village, a tribe, or a small town. Today, things are different. Most of us have to find our own communities, and a professional community is a good choice.

It gives us connections, new ideas, opportunities to learn, and people who can support us. It also gives us something very important: a sense of who we are. But a community cannot survive on words alone. People need to do things together. Otherwise, the community turns into a swamp where even frogs get bored.

One great thing we can do together is develop and maintain our professional standards. Why is that useful? We get to share our experience. We discuss what technical writers actually do, what roles we play, what tasks we perform, and what skills and tools we need. We learn from each other. We start to understand the profession better. We discover people who have something valuable to teach us—experts, leaders, and future mentors. The process itself is valuable even before we have a finished standard. Once we understand who we are, we can explain it to employers, managers, recruiting agencies, engineers, and other people we work with.

Nobody is going to appreciate us by default. If we don’t explain our role, people may think we are just losers who write bullet points because we failed to become engineers or fiction writers. We know that’s nonsense. Technical writing is not just about writing instructions and data sheets. It’s about managing knowledge, understanding complex ideas, making them clear, and helping people find and use information. But it’s our job to explain that. Nobody will do this for us.

And finally, there’s a clickbait part: artificial intelligence. AI keeps getting better, and we keep having to explain what we can do that machines still cannot. Those boundaries keep moving all the time.

Our professional standards cannot be something we write once and forget. We need to keep them up to date. We need to show what makes us valuable today, not ten years ago. In that sense, our professional standard is more than a description of our profession. It is our declaration that we are still needed, that we are not replaceable.

Gowri: How do you define the skills and knowledge a technical writer should have in order to meet these professional standards?

Mikhail: Skills are important, of course, but we don’t start with skills. We start with roles. Roles are easier to identify, they are more stable, and they give us a better picture of the profession.

Once we identify the roles, we look at what people actually do in each role. We call these activities functions, and each function produces a useful outcome. Then we ask what skills and tools people need to perform these functions. There is one more thing: careers. How can you move from one role to another? What do you need to learn to make that move? So we have four levels: careers, roles, functions, and skills.

For us, a role is something like a professional mission. Imagine three technical writers. One writes articles for a technical knowledge base, another creates video guides for users, and a third writes API documentation. This may even involve writing and debugging code samples. They are all technical writers, but their missions are very different.

They produce different results and need different skills and training. That’s why we focus on roles, not job titles. We’ve almost given up on job titles and grades. Every company has its own system. A senior technical writer in one company may do completely different work from a senior technical writer in another.

Instead, we use professional levels. At the entry level, we have beginners, interns, career shifters, and people who are just starting out. At the regular level, people can work independently as long as the requirements are clear and the tasks are relatively simple. At the advanced level, people can deal with uncertainty, figure out what needs to be done, define requirements themselves, and handle complex tasks. At the top level, we have department heads and leading experts.

A good career doesn’t have to end in management. You don’t have to become a team leader or department head to be successful. You can become a better expert instead: take on more difficult problems, create new tools and methods, and teach and train other people. That’s a great career too. We call this a horizontal career. I strongly believe that a top-level expert can be just as valuable as a department head. They deserve the same respect. They deserve comparable pay. This is one of the principles I always try to include in a professional standard.

How do we actually develop the standard? The standard is not just a document. It’s a way for the professional community to understand itself, so it has to be a collective effort. First, we put together a working group. We invite heads of documentation teams, experienced technical writers, and people who are known for their contributions to the community. Together, we identify the roles and create a list. Then we divide the work, and each person takes a role and describes its functions and the skills needed to perform them. We keep shared lists of functions and skills. This helps us avoid duplication. When the first draft is ready, we bring it to the community. We invite people to read it, discuss it, criticize it, and suggest changes. We use the feedback to improve the standards.

Gowri: You’ve also worked on automating content publishing and delivery. Where does the professional standard fit into this process?

Mikhail: Look at large business systems—ERP, CRM, BI, and so on. They take standard models of business processes, and then companies adapt these models to their own needs. Technical writing is a much smaller field, of course, but the same idea works here.

If we want to automate something, we need to understand what we are automating. What roles do people play? What functions do they perform? What results do they produce? This is where professional standards can help. They give us a model to start with. We can use this model to understand how information is created, how it moves through the company, and how it gets published. Then we can design reasonable processes to automate them. Otherwise, we just take messy processes a company already has and try to automate them. We end up with an expensive mess—a pile of special cases, exceptions, and workarounds.

Professional standards should also describe the skills needed for automation. I’m talking about content management, publishing automation, docs-as-code, single sourcing, other helpful technologies and approaches, and AI tools, of course. We need to know what these tools can do, what they cannot do, and where they can get us into trouble. But knowing the tools is not enough. What’s more important is knowing how to design the entire process. A technical communicator should understand information architecture, how to structure information, how to organize content, and how to design automated publishing processes. Most importantly, they need to know what should be automated in the first place.

There’s a big difference between understanding how to use a tool and understanding how to build a good solution. I believe the second ability is a much more important professional skill.

Gowri: You seem to read a lot of valuable content, either online or in print. Are there any resources you would recommend to our viewers?

Mikhail: I have this Pocket Style Book written by journalists and editors at The Economist. It has nothing to do with technical writing or computers, but I like it very much. It’s funny, and it has a lot of helpful advice on how to write in general. What’s especially interesting about this book is that they are crazy about British English. They often discuss how Americans spoil the language and how to write in British English. There’s a picture of a robot reading a newspaper, and the paper is completely unclear to humans. The book isn’t new; it’s from the ’80s, about 40 years ago.

Gowri: When you hear the word documentation, what’s the one thing that comes to mind?

Mikhail: Inside Macintosh. The old Inside Macintosh. It’s the best documentation set I’ve ever seen.

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

Mikhail: Get a rabbit. I love these animals, but I only discovered that in my 40s.

Mikhail: I have something else to share. The Armenian community of technical writers is developing its own professional standards now, and it’s a great honor for me to be part of this project. We plan to use a new way to classify roles, functions, and skills, and it’s closely related to AI.

The idea is very simple. We ask two questions: Who is the writer, and who is the reader?

A human can write to other humans or for machines, and a machine can write for humans or for other machines. So we have four areas, four quadrants, to classify skills, functions, and roles.

Gowri: Wow. Four basic categories. That sounds interesting.

Gowri: I think we’re up on time, Mikhail. Thank you so much for joining us today, and all the very best for your upcoming projects. Keep safe.

Mikhail: Thank you. It was great to meet you and to discuss those matters. Good luck to you. Great podcast.

Gowri: Thank you very much for your support.

Mikhail: Thank you.