How to Make Docs Effective & Mistakes to Avoid: A Chat with Pradeep, Coralogix

Transcript:

• • 01:13 – 05:56 Pradeep’s Journey into Technical Writing

    Gowri Ramkumar: Welcome, everyone, to the Knowledge Base Ninjas podcast with me today we have got Pradeep Venugopal, Technical Writer at Coralogix.

    Hi, Pradeep. How are you doing today?

    Pradeep Venugopal: Hello, Gowri. Am doing good. How are you?

    Gowri Ramkumar: Fantastic. Thank you so much for asking.

    So, yeah, before we dive into anything, any other topics, just help us understand how did you start this journey? Looks like you’ve been in this industry for over ten years. So let us know what inspired you and how you are enjoying so far?

    Pradeep Venugopal: Okay, so I think, journey as a technical writer started with a suggestion from a friend who said that it’s a job like technical writing, because ten years ago, it was not a prominent field and I still think it is still niche, because when I introduce myself as a technical writer, some of my friends here, they just ask, what is it?

    Gowri Ramkumar: Okay. Interesting.

    Pradeep Venugopal: I mean if you are a software developer or something in a team of 20, there would probably be just one technical writer and it’s not a very well-known field yet, right? And then, even though it’s been around for a few hundred years, nobody knows what it is.

    So then I was introduced to this by a developer friend of mine. Back then, I was doing back office works and everything. So then I thought this would be a nice switch. With my degree in computer application, and I was running a travel blog, and then I thought, this is a nice combination of things that skills, that I already have, which I can use it for a job. So then once I entered, then, you understand, like, you get different perspectives of a lot of things and it keeps it interesting over the years. And I stuck to this.

    Gowri Ramkumar: Fantastic. So I’m sure you must have worked in multiple organizations. What did those organizations teach you? To sharpen your skills or to improve in the next project?

    Pradeep Venugopal: That’s quite a lot. So I started with SAP, and I was there for like six years, and I thought it was a very solid start for a career and technical writing because they had everything. They had this mammoth of product which so a central process, and they also had smaller SaaS products that I can work on. Which is more fast based compared to the enterprise one.

    And then so that’s my, I’m just out of university and I’m starting as a technical writer and all I have known was a six months certification course because that’s all I know. So the real work started from SAP. And then it was quite a challenge in the beginning to understand how the product works, because it’s a very complex tool. You or people working in the field they need like, years of training to understand that, right? But then you get thrown into the sea on day one, which is quite an adventurous way to learn things.

    Gowri Ramkumar: Yeah. That’s right. Yeah. You might learn the hard way, but that will stick with you forever, isn’t it?

    Pradeep Venugopal: Yeah. You learn to survive. You learn new tricks on learning things. And so I got that start from the beginning. So now if you put me anywhere in any complex places, it becomes easier to learn, because that’s the only way I know how to survive, I think.

    Right. Yeah. And so once I’m out of there, I know how to document for an enterprise product. And I also know how to document for a SaaS product, which is more people-friendly, which is more technical. So out of there, I moved to Amazon here in London, which is completely different. It is user-focused, but then the user base is large, right? If it’s internal, it’s large, if it’s external, again, it’s huge.

    Gowri Ramkumar: Huge. Yeah.

    Pradeep Venugopal: And then the way you write for each of them is completely different.

    Gowri Ramkumar: Wow.

    Pradeep Venugopal: And here I was also doing some of the project management work for technical writing. So you have to write use cases and vignettes to get budgets out of it. So that means you go to a warehouse to see how it actually works. And then write vignettes of that. And then you, it is more of like so you have different perspectives and different personas within the company, and then you have different personas outside the company as well.

    For example, an AWS product it touches a lot of companies, right? Which, in a way, like I said, I was prepared, in SAP, right. So you have multiple personas working side by side in there, which helped a lot in Amazon. And then I moved to a completely different domain called the observability, ITSM, and observability platforms, which I just started three years ago. And I find it very intriguing and interesting so far. And it’s highly technical. Right. Fast evolving, right? So yeah, so that’s pretty much it.

    And now I’m in Coralogix. So it’s more of a, it’s one of the top ten observability tools right now. So it’s kind of still very new. So it’s just a five-year-old company that’s still growing.

    Gowri Ramkumar: So that’s fantastic.

  • 05:56 – 07:01 Measuring Knowledge Base Effectiveness

    Gowri Ramkumar: Now you spoke about big names. How do you measure or how do you know the knowledge base is effective?

    Pradeep Venugopal: Okay, so for a knowledge base to be effective, it should be easily discoverable. Like, people can find it when they need it without any searching. And then they need to trust the knowledge base, they need to trust the teams that they need to trust that it is accurate and up-to-date. And also, it has to be actionable.

    Instead of pages and pages of blogs and then on concepts, you are writing for people who are learned well, who are skilled. So you need to make some assumptions that they know things, and then make those documents actionable. They take information from there, and they accomplish something in their daily life, and they reach that goal. So it’s as simple as that.

    But then, so in practical terms, it kind of looks like a structured knowledge base with clear ownership who owns which product and then regular review cycles and integration into daily workflows. So this, in turn, I think it fosters a culture of sharing knowledge across companies, yeah. And it kind of helps teams grow together.

    Gowri Ramkumar: Right.

  • 07:01 – 08:45 Common Mistakes in Setting up Knowledge Base

    Gowri Ramkumar: Now, when we are trying to make the knowledge base really effective, as I mentioned in the, as you mentioned as well, you were thrown to learn the product, and you know, come up with the documentation.

    So, what have you observed as some of the common mistakes when setting up a knowledge base or wiki, internal wikis?

    Pradeep Venugopal: Okay. So that is something that I work multiple times within multiple places where they come up with their own, like teams, come up with their own knowledge base, etc. Right?

    So the first and foremost mistakes I think they make is treating it as a one-time project for an ongoing living system. So once they do that, the second one that follows is overloading it with unstructured content. So they write new topics again and again instead of single-sourcing and finding that one single source of truth that can be updated.

    Gowri Ramkumar: Yeah.

    Pradeep Venugopal: It does not matter who wrote it, right? If you’re updating it, you write, you learn the whole thing, and then you update it. And then the other thing would be no clear ownership. So the content becomes outdated, and people start trusting it. And then they write their own great documents and store it somewhere, and they refer that instead of a central location.

    The final one, probably the poor user experience, like inconsistent labeling, like navigate manuals, or forcing users from multiple clicks. Because when it comes to a knowledge base, I think even if it’s internal or external, it should be treated as a product in itself. So user experience becomes important there as well. Because every time someone searches for a new information, they are losing time on doing something else.

    Gowri Ramkumar: Correct. Yeah.

    Pradeep Venugopal: Making this easier, makes everybody’s life easier. Like go about your own.

    Gowri Ramkumar: Very well said. Yeah.

  • 08:45 – 11:00 Documentation Best Practices for Fast-Paced Teams

    Gowri Ramkumar: We keep talking about, trust the team, trust the system to have the latest updated information, right?

    Now, how do you ensure the documentation keeps up with the frequent updates or even agile releases? Because many of the organizations you described now, or many of them outside, are all very agile. They have releases every month, if not every week. Right? So, how do you make sure that the documentation is updated?

    Pradeep Venugopal: The personal way that I do is I sit with the PMs when they are writing PRD. That’s like even before sprint zero. I’m there, so I know what’s coming. So the best way is to embed documentation into the product’s lifecycle. So that means participating in sprint planning releases, which is the normal thing every writer does. Making documentation reviews part of the definition of done. So sometimes this is the part you have to force yourself into the development process and say that the feature is not ready because the documentation is not signed off yet, right?

    Gowri Ramkumar: Alright, make it part of the release.

    Pradeep Venugopal: Yeah. So you make friends where possible, and then you tell them, see, this has to be done as well. And then some, and some places you can use automation where possible, like linking box to release notes. And some of the Jira updates that they’ve come up with does that automatically, like it stops any feature be released. Because a ticket that’s related to documentation shows as a blocker. Right.

    So this is done two different ways. Like in enterprise, the challenges often documenting something very complex like that, documenting complex changes through thoroughly for specialized users. Right? So you have 2 or 3 personas who have been working with them for like years of years. So for them, you need to document very technically. They need to know everything that’s coming out. But as far as the challenge is, speed.

    Gowri Ramkumar: Yeah.

    Pradeep Venugopal: The features could be small, and the user could be anyone, from a common man to anyone. And so the ensuring docs are ready at release time or shortly after sometimes, in both cases proactive environment in the development process is what keeps the documentation from lagging behind. So it’s you embedded yourself in the production process.

    Gowri Ramkumar: Very well said. Yeah.

  • 11:00 – 12:44 Why Docs Are a Product, Not Just Support?

    Gowri Ramkumar: I think this question might also be very interesting, which is, though we want to be part of the release, how should one consider documentation?

    Should it be part of the product experience, or should it be considered more like a support function?

    Pradeep Venugopal: It’s definitely a product experience.

    So imagine, you have a product, and then someone’s stuck on like IKEA furniture or something, they are stuck on something, and they go through your manual to fix, which should be a very simple fix. But then your documentation is not very clear. And then they’re not able to put together, let’s say, a simple software or something. And that spoils the product, the user experience, which in turn spoils the goodwill for the company itself.

    If a user can’t figure out how to use a feature, it doesn’t matter how well it was engineered, right? It’s effectively unusable. So…

    Gowri Ramkumar: True.

    Pradeep Venugopal: And the other part is if you have good documentation, it reduces support burden.

    Gowri Ramkumar: Yeah.

    Pradeep Venugopal: It, in turn, saves cost. And saves money and time. But its primary role is enabling success to from A to B. So you can reach as quick as possible without support from an external factor. So in that context, great documentation acts like an extension of product design. So it guides, explains, and helps users accomplish their goal as quick as possible. Like in this scenario, I can think of like, for SaaS, especially where self-service a norm, documentation is often the first interaction a user has after they sign up. So maybe that makes it critical when they are onboarding, adopting and also using the product.

    Gowri Ramkumar: Yeah that’s true. So it should be definitely a product experience.

    Pradeep Venugopal: Correct.

    Gowri Ramkumar: Right.

  • 12:44 – 14:35 How AI Is Changing the Role of Technical Writers

    Gowri Ramkumar: I’m sure you’ve experienced a lot in the ten-plus years of journey.

    Now, we all are talking about AI. Now, what are your thoughts on how AI is changing the role of a technical writer like yours?

    Pradeep Venugopal: Well, I think AI is transforming technical writers in several ways. I would say. So, probably on a tactical side, AI tools can draft like boilerplate content, summarize release notes and suggest structures, or even help with localization. So this would save time for me, as like we, as technical writers, can become like curators, validators, and designers of knowledge ecosystems with the help of this tool. Right. Which we were doing previously as well, but then it saves a lot of time.

    Gowri Ramkumar: Yeah.

    Pradeep Venugopal: So now I think if we are using an AI-generated content, you still have to make sure it’s accurate, consistent with the brand voice, which I don’t think the AI can do it from scratch unless you train it through. Because each company has its own voice and it has to be aligned with its users’ need. So these users or people that we interview like that, we need to, so we have more empathy towards them than AI. So I think it becomes like we kind of test the outcome. We personalize it instead of, you know, instead of just making charts, you write something and just throw it out. And so when the time that we save, instead of spending all their time writing from scratch, writers are increasingly focused on strategy and information architecture, and quality assurance.

    Gowri Ramkumar: Right. So that’s a human in touch, human in the loop concept?

    Pradeep Venugopal: Yes. So I think, making the role less about typing words and more about orchestrating knowledge. So in our own way, personalized way possible.

    Gowri Ramkumar: Understand. Understand.

  • 14:35 – 16:33 ⚡Rapid Fire Round

    Gowri Ramkumar: Now, moving on to the rapid-fire round questions, Pradeep, do you have any resources that you think you can recommend to our viewers, particularly on the documentation side?

    Pradeep Venugopal: Resources and something?

    Gowri Ramkumar: Any blogs or any books, or anything that you found very interesting that you recently consumed?

    Pradeep Venugopal: I think instead of blogs and books, I prefer going to one of the tcworld conferences that happened like two, three years. So, the thing about tcworld is we always talk about technical writing as a software product, right? But technical writing exists in every possible way. Everything is documented, like any hardware, like a washing machine that you buy, like anything, like a screw in an aircraft, everything is documented. And all of that is technical writing as well. So you meet these people, and when you talk to them about their perspective and their content strategy, it kind of broadens the way you think about your product.

    Like I think that is more helpful rather than reading a blog or a book. So if someone can do it, they could just like visit any of the tcworld like events that happen all around the year.

    Gowri Ramkumar: Nice. Thank you for that.

    What is that one word that comes to your mind when you hear “Documentation”?

    Pradeep Venugopal: Well, I think documentation is a part of knowledge management.

    So documentation could be your user guide or an API reference, or tutorial, or something. So when several documentation comes together, that becomes knowledge management. That’s how I feel.

    So it often feeds into knowledge management systems.

    Gowri Ramkumar: Now, a piece of advice to your 20-year-old self?

    Pradeep Venugopal: A 20-year-old self?

    I don’t know I think probably just choose to be a technical writer early on so that you are more prepared.

    Gowri Ramkumar: Right. And take any challenge as it comes, as you did straight out of uni, right?

    Pradeep Venugopal: I think life just throws you on something. So just be prepared.

    Gowri Ramkumar: Yeah. All right. Fantastic.

  • 16:33 – 18:17 Essential Skills for Modern Technical Writing Careers

    Gowri Ramkumar: Now, did I miss anything that you would like to share?

    Pradeep Venugopal: I probably think for the next generation of technical writers. I think because of the, like I’ve heard, there’s a lot of fear of AI and everything.

    I think AI literacy is important. So it’s just a tool that we can use and know how to leverage effectively while maintaining quality and then collaboration skills, working closely with product, engineering, and support, because people skills it’s utmost important as a technical writer because you’re dealing with a lot of people. But getting out and then comes probably your tool fluency and analytical and data literacy on how to, they need to learn how to use metrics to improve docs.

    Once you have all of this in place and once you’re a technical writer for a long time, your content strategy and information architecture, so I think it should come naturally to you once you understand and have empathy for the product and the people using it.

    Gowri Ramkumar: Right. Right.

    Pradeep Venugopal: So Pradeep, that was an amazing conversation we had now. And, thank you for sharing all the nitty gritties of how you started your journey and what you accomplished in the last ten plus years. And, we wish you all the very best for your upcoming projects. And, good luck with a lot more innovations that’s yet to be experienced.

    Pradeep Venugopal: Thank you so much.

    And those were interesting questions, and I hope it reaches a lot of people.

    Gowri Ramkumar: Absolutely.

    Pradeep Venugopal: Thank you.

    Gowri Ramkumar: Thank you so much. Take care, Pradeep.

    Pradeep Venugopal: You too. Thank you.

    Gowri Ramkumar: Bye-bye!