Zohra Mutabanna: 0:04

Hello folks, welcome to season five of Inside Techcom with Zahra Mudabana. This season, we are focusing on tools, tips and strategies to elevate your craft. Let's dive right in. Hello listeners, welcome to another episode of Inside Techcom with Zahra Murabana. This is going to be the last episode for this season and I'm excited to have Selva Raju Murugesan. Selva is from Kovaico and he focuses on integrating AI features into Document360, a knowledge-based SaaS. He's an active community member in the technology and documentation space and his recent article Is your Content Ready for Gen AI-Based Agents? Was featured in the TC World magazine. He is the head of data science. With that, selvaraju, welcome to my show. I'm excited to be talking to you today.

Selvaraaju Murugesan: 0:57

Yeah, thank you for hosting me, Zora.

Zohra Mutabanna: 1:00

Yeah, it's my pleasure. Thank you for writing this article, because I think this is kind of the need of the hour. How do we think about how the roles of content creators, specifically technical writers, are evolving, but also, what do we do with the content that we have and how do we take it to a place where it can be consumed by generative AI and repurposed to how humans consume it? So I think we're going to talk about all that. So, salva, tell me a little about yourself, let's dive in.

Selvaraaju Murugesan: 1:32

Yeah, I'm not a tech writer by profession, so I'm an engineer by profession.

Selvaraaju Murugesan: 1:37

In fact, I did the mechatronics engineer, which is sort of dealing with machines, especially with the hardware and stuff like that. Then I did a master's in electronics engineering from La Trobe University, australia, where I get an opportunity to continue with my post-graduation PhD in computational mathematics. So in terms of technical writers, I'm very far away from what the profession is. But having said that, I wrote a 15,000 page thesis in six months, so I get into a bit of writing okay in terms of obviously conveying all this technical knowledge I have into putting into thesis. But having said that, over a period of time I work for a lot of SaaS companies, especially in the data science space, and with the current company I'm part of, which is Coveyco, I get to manage the documentation team for more than three and a half years and I managed a lot of tech writers producing a lot of SaaS product documentation, troubleshooting guides, liaising with that, and that's how I ventured into technical writing and the most fascinating world of the tech writers, the whole ecosystem, the tools, the practices and the frameworks and it all amazes me in terms of producing a simple troubleshooting guide or a how-to article or something like that. It takes so much research and effort in crafting that article. I fundamentally believe that it's an art by itself and I was fascinated by this technical writing and that's how I ended up.

Selvaraaju Murugesan: 3:02

Having said that, I also work for a SAS product company which builds tools for these technical writers and document. This is one of them and which means I get to work with the technical writers who produce a lot of content. At the same time, I work with the product team who actually builds such kind of products to help to enable the technical writers. So that's how my field actually converge. So I get the bit of a background from the technology and also from the practice side, from the technical documentation side. So that's how my field actually converged. So I get a bit of a background from the technology and also from the practice side, from the technical documentation side.

Selvaraaju Murugesan: 3:28

So that's how I ventured into the world of technical writing and where I actually my expertise lies in terms of I understand the technology point and, more importantly, I understand the documentation process and the frameworks and I am in the right space in the convergence. So when the tech and the technical writing converge and that's a niche place to be. It's a very narrow field in terms of understanding how this technology works, and it's pretty excited to be in this space, to be honest, given that there's a lot of gen a stuff it's all text information and who produces text information more than anybody else in the world? They are tech writers. So I'm very excited about what the technology can offer and how the content creators can tweak the content to make it work for AI. So it's a very niche sector and I'm very fortunate to be in a good place at the moment.

Zohra Mutabanna: 4:17

Wow, salva, you know you are making my heart sing. I rarely hear anybody say that tech writing amazes them and how it fascinates you, that it's a craft and you know so much about it. In your own way, you've given it your own I guess, your own color to it. But this bridge is that is what we are looking for, and it's awesome that you come from an engineering background and know so much about technical writing and you've made the effort, and this is exactly what we want. We want to be talking, we want to be reaching across the table and connecting with people that work with us or want to know more about us yeah, yeah, absolutely.

Selvaraaju Murugesan: 4:56

Look, some of the things you learn from the engineering background still applies to the technical documentation. Yeah, you call it as a business process modeling, if you're if you're a business analyst and then you come into the technical writing world and they call it as workflows, and then it's basically a business process on how you build your technical documentation, but you have a different terminology. But the concepts you learn in engineering are still applied to technical writing. And but guess what, if you come from the engineering perspective, what engineers love is they measure, they love to have quantity, metrics and stuff like that. You bring that to the technical writing practice, where people love in technical writing world. People are fascinated by words. They are so much into the power of words they have little knowledge about data in measurements and metrics. And that's the value add you bring in when you come from engineering background into technical writing.

Selvaraaju Murugesan: 5:47

And for me, that's one of the contribution that we want to make to the community in terms of how do we focus on quantifying some of the value of documentation? Yes, which is a bit tricky. If you take any kind of technical writing team in the world, it's extremely hard for the technical writers to quantify the value they actually produce, because always considers a cost center. And when you ask for scaling your technical writers they always say why can't you? Why do you need one more technical writer? Why can't you just do it by self? Take it slow.

Selvaraaju Murugesan: 6:19

And people never considered technical writing as a part of the product. If you work for a sas company, the product and the sas documentation are two separate entity. Even the product managers they struggle to think product and product documentation single entity. They always segregate. But if you come from an engineering background you know how to exactly quantify this, what value the technical writing is adding to the product, to the support, to the enrichment of customer education. So those things can be quantified using metrics. And that's the amazing story for a technical writer to tell to a c-level executive. And I find that it's a very interesting kind of a paradigm shift from technical writers who produce words and then telling a story using data.

Zohra Mutabanna: 7:04

Yeah, you do make a point that at some point, to a large extent, we do. As writers, we are very focused on words. Fortunately, I've had the opportunity to work on teams where there is a focus on recognizing the value, the business value that we bring, especially in my current role where we do track metrics to a large extent, but, I think again, converting that data into a business value and the story to tell. It's interesting that we kind of struggle, you know, despite dealing in words, we struggle to spin a story where you know we can market ourselves yeah, that is true, zora.

Selvaraaju Murugesan: 7:45

The thing is, a lot of people think that it should be towards a business value. When you say business value, let me give you a better use case. People talk about reducing the support tickets or reducing the resolution time, increasing the age and productivity in the sas environment using documentation, and there is a lot of metrics around self-service. People come and self-serve, they learn and they do, but I fundamentally believe that paradigm, that hypothesis, is not valid. Okay, the reason is if you understand why we build documentation, what's the outcome? As a technical writer we want to do is we want to empower our customers to achieve an outcome, okay, or complete a task. This outcome could be completing a task or completing a process or configuring something, so they want to do something with the documentation that we have to be perfect. To be honest with you, you should not have any documentation. If your ui is amazingly better, okay, give a best example apple iphone doesn't come with the documentation, even though it's a hardware product. Okay, it never comes with documentation, any apple products for that matter. Okay, the? U is so good that you don't need a documentation. But, having said that, we don't live in a perfect world like apple and you don't have a much r&d. We work with a lot of sass companies where the ui practice and everything is maturing and sometimes the products are so complex. You're taking the documentation to help customers to configure or troubleshoot or anything. But here's the crux of the documentation. So you're helping your customers to achieve an outcome.

Selvaraaju Murugesan: 9:14

If you really want to quantify the outcome of your documentation, find out how many people have configured or completed a task using your documentation. That is an amazing metric to do. It's very hard to collect, given that there's a lot of engineering effort should go in and to collect all these metrics, but if you can do that, then you show the amazing value. You can go to your c-level like is going to guess what our product is so complex. I produce the documentation because of that. People are actually able to configure x number of features within Y number of minutes or Y number of hours or whatever. So that would be an amazing story to tell, because you are actually empowering your customers to accomplish a task and that is where the value of your documentation comes into play. Absolutely, and I fundamentally believe in that metric. Yeah, and there's a lot of frameworks we are trying to build to compute that and some kind of analytics framework around that as well.

Zohra Mutabanna: 10:05

But I find that it's an interesting kind of a quantifying the value of your documentation yeah, one thing I did forgot to mention that numbers scare me and data scares me, but despite that, I make an attempt to whatever uh extent I can to understand the data that I'm, uh, you know, kind kind of to build that story, as you said. But I want to come back to that Apple use case where there is no documentation. Now, when people think about documentation, you're thinking about the traditional long form content, right, you think about guides and you think about context sensitive help. But I'm going to suggest and you know I want to extend that definition of content. Even when you buy an Apple device, you're not just buying something with a UI, which you're just having UI elements. There is content embedded in that, and the content that's provided with that UI experience is what technical writers do.

Selvaraaju Murugesan: 11:00

Exactly.

Zohra Mutabanna: 11:01

We need to understand that content and documentation. The nature of content that is being worked on by technical writers has evolved and to provide that UI experience without content. If you just had images, that's not good UX experience either. Little color to what you said that there is content that is technical writing, but it's it's in the context of the user experience. We are not providing something where you go off the ui experience and you need to read that content is what is guiding you through that experience.

Zohra Mutabanna: 11:33

Actually, it's sort of it's part of it's part of the product. Actually, that's what I think you were trying to suggest yeah, that's right.

Selvaraaju Murugesan: 11:41

So if you look, look at the design philosophy of when you build a kind of just a hardware product or a software product, the design philosophy has to treat product and its associated documentation as a single entity rather than a separate entity. In terms of the experience, it has to be very native in the product itself. The documentation should not be a distraction where it takes you to another page or maybe loads in another browser or another tab so it actually creates a friction in terms of the experience. So that's the user experience component. You're talking about the documentation part and I fundamentally believe that the product and the documentation should work seamlessly inside the product, creating that what we call it as a knowledge experience. You not only tell them how to do this, and then that becomes a habit, but most importantly, oh, I learned something new here, not by reading a bunch of articles written by a tech writer, but guess what? It's inside the product. It's giving the context and I'm learning while I'm inside the product. I believe that that's magical.

Zohra Mutabanna: 12:45

Yes, I think you're right. It is magical because the objective of we talk about design, the design principles, you're trying to reduce the cognitive load of the user and, as you said, you want to reduce that friction. So if it's such a unified, streamlined experience where content you're not even thinking about content, I think as you won your product design itself because you've just eliminated the difference between that wall that exists between content and product Fascinating. This is exactly what we are striving for to kind of bridge that design and content experience. In fact, I have my latest episode that went out with Scott Abel. He's known as the content wrangler. He hosts several webinars. We talk about content experience where every team that is creating content there is such a wall that we are thinking more about content than the customer at this point.

Zohra Mutabanna: 13:37

And how do you provide that unified content experience where you're taking away that friction look, we have a different take on content.

Selvaraaju Murugesan: 13:44

Of course, the content is a more commonly used word. We use the word knowledge and I fundamentally believe that, if you look at the whole paradigm, I mean from evolution we created data, we created information, but there comes the knowledge. I fundamentally believe in knowledge. As a technical writer, we are creating new knowledge or enhancing the existing knowledge, and that's what we do. I think content kind of puts the technical writing perspective in a paradigm where it doesn't show the value or the impact they're trying to create.

Selvaraaju Murugesan: 14:17

I fundamentally believe that the technical writers work is to create new knowledge or enhance an existing knowledge, and what we need to think about is in terms of creating that rich knowledge experience. How do I come into a product or a documentation where I feel like my knowledge is enriched and I feel glued into this product because the product and documentation work seamlessly? If I get stuck, there's an in-app assistance or the product is trying to help me out with the right kind of tips, nudges or any kind of a in-app tutorial kind of thing, where it comes and shows me up I've learned it, I know how to use it and it just disappears.

Zohra Mutabanna: 14:55

So that kind of experience is what makes a product a great product yeah, I love the presentation of, or rather the take of, knowledge, experience, and that's what we are creating, that's the value we are bringing. I love that take especially. We are trying to reach across the aisle and try to understand, so you are kind of telling us what value we bring to you, which is great, yeah, yeah, no, look, absolutely, look.

Selvaraaju Murugesan: 15:20

The more I get into technical writing world and understanding the ecosystem, there's a lot of things that the technical writer has been doing for so long years and what we're trying to do is having a framework and then telling them the amazing work they've actually done in the past okay, and then helping the future people that there is a value in what we do and I fundamentally believe that the technical role as such given.

Selvaraaju Murugesan: 15:43

There's's a lot of anxiety about Gen AI coming and taking over especially technical writing, because we produce a lot of textual unstructured information and I fundamentally believe that the Gen AI is not going to take away any of the technical writing job. I fundamentally believe that because, at this point in time, gen AI, where the Gen stands for generative, it can only generate that's already been there. It cannot create a new knowledge by itself and that's the power of the technical writers they create new knowledge. Nobody in the world create new knowledge except technical writers, especially for any kind of documentation, procedures, policies. They are the fundamental piece in this value chain of knowledge creation, knowledge organization and knowledge sharing.

Zohra Mutabanna: 16:27

So we've talked about the old and the new paradigm in your context, in the context of technical writing, and you also touched upon how technical writers are key to creating that knowledge. For generative AI Now, the risk is real. Not all technical writers are embracing artificial intelligence, specifically generative AI. Now, the risk is real. Not all technical writers are embracing artificial intelligence, specifically generative AI. They are kind of, I guess, either fearful of it or dismissive of it. In your opinion, since you have such an interesting take, what do you think technical writers should be doing to kind of own this?

Selvaraaju Murugesan: 17:03

There's's few things why technical writers abandon.

Selvaraaju Murugesan: 17:06

Okay, let me list a few. The first one is trust. How do you trust what jenna is giving you is is truth, how reliable it is, how consistently it can produce the same output? To be honest, at this point in time it's not trustworthy. When I say trustworthy, it is not 100 accurate. When I say 100 accurate, it cannot produce the same response 100 of the time, all the time. It's not. And why? Because if it does, it just memorized everything you said. There's no a component.

Selvaraaju Murugesan: 17:39

So the nature of gen ai is it is probabilistic in nature. That's how the technology has been Always. The AI is probabilistic in nature. It always produces output which are variable and it falls under certain accuracy, but it just achieves the outcome to certain level of accuracy. And whenever there is a certain level of accuracy which it can be given to a human consumption and most of the technology guys, they just roll it out, okay, and there comes the problem. So I talk about the trust.

Selvaraaju Murugesan: 18:08

The second one is in terms of how it can actually adapt to my style and then my own way of writing things. Because, generating stuff, how can I be sure that it is imitating my own way. It's very tricky to measure at this point in time If you use certain words, certain style of writing. I don't think Jene can actually be able to understand by a few texts At this point in time. It's very tricky. You have to train your own model to for you have your own style and stuff like that. I mean it needs a little bit of time. I don't think anybody is focusing on at the moment all the jenna technology is very generic and then very generalized at this point.

Selvaraaju Murugesan: 18:47

The third one, of course, is the fear in terms of adapting it. If I I use it, yeah, I can be productive Then what is the value that I bring in? I write articles at this point in time, if you're saying that I have a chat GPT plugin that can be put into Teams when you record, when you come out of the meeting, it's already drafted article. That puts my job in jeopardy and that's the fear factor I talk about. And these three concerns are completely valid. It's absolutely there. But as a tech writer, you need to prepare for certain things. The trust factor it's going to improve the new models they are actually launching. It's a lot more accurate. It has reduced hallucination, so the trust factors are able to produce the outputs very consistently in terms of reliability. It will be there okay, over a period of time. It will be absolutely there.

Selvaraaju Murugesan: 19:37

And the second thing, in terms of understanding your style and then able to execute some of the certain tasks in your own style, adhering to your company policies, your style guides and everything. It will be there okay. Third one is, instead of fear, we should embrace it. I keep telling, uh, in a lot of the meetups I go to, if you think that as a technical writers, you will scale your team from one to ten, forget it. In the future there will be like one technical writer in the entire sas company, even if they are multi-product sas company managing portfolio of products will be like one technical writer in the team managing multiple llm agents. So I fundamentally believe the future of technical writing where the technical will be managing multiple digital workers you call it as an agents who can do tasks as per your policies and your command. That's the world you need to be prepared for.

Selvaraaju Murugesan: 20:29

And guess, guess what? Most of the tool vendors are already incorporating some kind of a technology into their tools already. If you talk about knowledge creation, they already have a lot of tools where you can actually generate a content outline. You can do taxonomy. You can do a lot of amazing stuff with the information architecture. You can rephrase things. You can actually enhance the knowledge from your support tickets. You can do all these things amazingly. Things you can actually enhance the knowledge from your support tickets. You can do all these things amazingly.

Selvaraaju Murugesan: 20:54

And when you talk about all this knowledge sharing and dissemination of the knowledge, you talk about having a generative search experience. Just like google, your customers will no longer come to your knowledge base site or your documentation type where they type in keywords. Instead, they'll ask a very specific question and then they get the answers and then they go and do their achieve the outcome. I think you need to be as a technical writer, you need to be prepared for that, which means there's a change in role. There's three things that will be added to your portfolio. The first one is, since I've talked about trust, I think technical writers will be tasked with because they are the subject matter experts in some of the things they produce. So they will be tasked with because they are the subject matter experts in some of the things they produce, so they will be wearing a hat of evaluating the response from the genii tool. Okay, so that's the first response, new responsibility that gets added to their plate evaluating the response of all the genii, I mean, which means they just go type in an answer, find out whether that's the right answer that's being generated. If not, add the manual input, give the feedback to the JNA agent or the tool so it can actually improve, learn over a period of time. So that's one.

Selvaraaju Murugesan: 22:00

The second most important thing is in terms of guiding this JNA agents with certain kind of vocabulary, the business vocabulary. Let's say, in your pricing plan of your sas platform, let's say you're using a term called members. Okay, so this is, you price your product based on the number of member seats you have, but your customers are going to come and type something like how many user license do you have in the pricing plan? Remember, you use the word member in all your technical documentation, but your customers are using, actually using your word called user license. So, which means as a technical writer, you have to give clarity to gen ai in terms of what this means. Okay, so, which means there's a lot of curation you have to do for business glossary and then incorporating into your technical documentation and stuff like that. And third, most important thing, is how do you bring richness to your documentation, which means it's just not textual content? The future of the LLM is going to be multimodal. How do you bring in all the information, like text, video, audio, everything and let your customer decide what medium they want and how they want to do it? And that's something a technical writer have to learn over a period of time Writing this content based on the personas.

Selvaraaju Murugesan: 23:14

They're all gone. Now you write a generic content. It's the customer who decides what kind of persona hat they want to wear and then they can go on to the generative ai hey, I am a four year old baby. Explain about this salesforce documentation in layperson terms. And it beautifully writes in. I mean, you as a technical writer, you never write that content, but it's able to take your content, which is written a generic way, and able to reduce it to the format and the medium and then the language your customer want. So they have the freedom. Now, as a technical writer, you have to give that freedom and then trade off with something else, but you have to give it to the customers now, so they have the freedom to wear any persona and then ask any kind of questions great points.

Zohra Mutabanna: 23:56

Uh, salva, really interesting. What I really liked about uh, you know how we have to pivot is we will tech writers will be managing llms, the large language models and the training of those.

Selvaraaju Murugesan: 24:08

Yeah, yeahm agents?

Zohra Mutabanna: 24:10

Yeah, llm agents, but in that little nugget it appears you also mentioned that instead of 10 technical writers, there's going to be that one technical writer, which means I think that fear is valid, that either you evolve or that role is going away Because one. I just wanted you to address that Because I think we sort of contradicted ourselves here yeah, yeah, correct.

Selvaraaju Murugesan: 24:34

So I didn't say that it's going to be the technical writer will be obsolete. I say it's a reduced headcount. I never said the technical writing profession is going to go away, okay. What I'm trying to say is, given the impact of the technology, you will see reduced headcount of number of technical writers working on particular documentation. The AI agents and the tight integration with other tools will help technical writers to be efficient and effective at the same time. So if you look at the basic tasks, zora, in terms of what technical writers do day to day, okay, they go sit on a meetings, they listen to a lot of product calls, feature calls, and they draft an article and then they also enhance it over a period of time. And then they also go and produce screenshots as per the style guides I'm talking about typically about the SaaS documentation here and then they come with the other admin overheads. For example, when you're publishing a tool or something, they need to write SEO, description, title, title and they work on the taxonomy, the content design itself and stuff like that. And then they do the process, the workflow process, they go to the peer review and then they get published. Okay, if you look at the whole value chain, the value stream of what value, as a technical writer, I am trying to produce, and the end of the value chain. Your output stops when you publish the documentation. Okay, once it's live, anybody can access. That's where it stops. But if you look at any of the activities that the technical writer do, there are a lot of things which are of no value or low value, for example, adding SEO meta description. Really, as a technical writer, I should be spending more on the content side, not writing this marketing SEO thing or generating tags or alt images. That should be taken away by the technology. In fact, it's a lot more better than a tech writer would do understand the basic concept. So I fundamentally believe that what the technology is going to do is it's going to make a lot of time savings for the technical writer and then it'll be a lot more efficient. With the time savings, then the technical writer should be mostly focusing be a lot more efficient. With the time savings, then the technical writer should be mostly focusing on the high value task. So that's where I see a lot of companies will think about how we bring in the technology to assist the technical writers in terms of being a lot more productive and then focusing on high value, high priority workload. So that's why I'm saying it will not be obsolete. You will see a reduced headcount in many organizations going forward because of the impact of the gen ai. Okay, and it's not about the technical writing as a profession. It will still exist because we need to create new knowledge and, going forward, you will see reduced number of hiring in terms of technical writing.

Selvaraaju Murugesan: 27:13

Again, this is what I foresee. The number of technical writers in the world is already saturated. It's I don't think it's growing unless there's a lot of people retiring and then you need new people coming into the field. That is not also happening. It's just that the field is a little bit stagnant. The number of technical writers over the period if you do a linkedin search and then if you compare, you know it's not like 10 increase or 20 increase in the headcount over a period of years just very, very minuscule amount of increase in technical writers over the world. Compared to other profession where you see a engineers, full stack developers, they are growing by eight percent, six percent year on year, but not technical writing and I feel like that's how it's going to be in the future okay.

Zohra Mutabanna: 27:55

So I think you kind of painted a very realistic picture where the reality is also tech. Many technical writers are not going to college to study and graduate with a technical writing degree. We chance upon this field and I think that experience itself brings a lot of richness to the profession. Yeah, and that's been my trajectory and I've been in this profession for 20 years and it has evolved. It has pivoted quite a bit, and staying current, staying trying to bring that higher value, as you talk about, is critical, especially now. And how do we think about sort of to that next level, how do we push ourselves to that next level? It's super important and I think these are the hard conversations that we need to have.

Selvaraaju Murugesan: 28:38

It is so. That's why I believe, like you want to become a manager of LLM agents in the future. The skills that you need is like how do I create, how do I write the policy in such a way that this LLM agent behave in the constrained environment? What are the constraints I have to do, what is the freedom I have to do and what is the task you need to accomplish? How do I articulate to this LLM agent what is the task it needs to accomplish? How can be very clear with that? So that's the skill that you need. That skill is not possessed by anybody in the world at this point in time. It's a new, emerging role that you need to build.

Selvaraaju Murugesan: 29:12

I fundamentally believe that part of the role will fall on the technical writer's lap in terms of writing that and managing some of the thing. Imagine, like when having an llm agent who's like a peer reviewer. You give certain instructions this to this llm agent how to peer review, what are the guidelines for peer review and finishes that once it finishes, once the ageLM agent finished that work, and then you give it to another agent to fix what it actually found and you get the there's human in the loop. I fundamentally believe that A it cannot be left unattended. There should be a human in the loop. That's where the technical writer is coming. They go, they verify, vet it, peer review, it make Verify, vet it, peer review, it make sure everything's correct and then they get the chance to hit the publish button at the end. So I fundamentally believe that there's a human in the loop. So whenever you design a Gen AI product, especially for technical writers, having a human in the loop is a very important design principle.

Zohra Mutabanna: 30:05

Yes, you mentioned peer review and I think I'm thinking very it's again an interesting take there, because you're peer reviewing content of the LLM agents and you've been talking a lot about LLM agents. Can you just, for the audience, just explain what an LLM agent is?

Selvaraaju Murugesan: 30:20

so an LLM agent, in a nutshell, is a autonomous or sometimes having a human in the loop human in the loop which can accomplish a task based on the certain instruction that you provide. So that's what an LLM agent would do. The important paradigm, when you compare to like a robotic cross automation or even an API call, is that it actually understands the instruction in a natural language and is able to execute that, and it can also communicate with another LLM agent or with a human if it needs any kind of certain directions, and it can actually do all the contractual negotiation on your behalf. So it's all happening under the hood and you can have an LLM agent for content creation. You can have LLM agent for content review, style guide, checking, proofreading you can name any kind of the task that you do as part of your regular workflow as a technical writer, and everything can be an agent.

Selvaraaju Murugesan: 31:13

Remember, agent. He can do only one task very, very good. So, which means you can go narrow down, you can, you can date it, you can explain all the tasks in detail and if you change a lot of a task and it becomes a process, and you can chain all these agents to accomplish a process or, sorry, go through a process so you can chain all these agents to accomplish a process. Or, sorry, go through a process so you can actually accomplish an outcome. So that's how you can think of them. Look, I believe that the technical writers they won't even have a luxury of seeing all these agents, because everything happens under the hood. I fundamentally believe that they'll be seeing it or maybe clicking some buttons, but every single action happens under the hood. Yeah, Awesome.

Zohra Mutabanna: 31:52

We've talked at length about you know what technical writers should be thinking about and how the role is going to pivot, but then we have to think about the knowledge creation and that knowledge management, and that's what I believe your article is about, and I wanted to dive into that and have you share what it is in the article that you talk about.

Selvaraaju Murugesan: 32:14

Yeah, so in the article I talk about how do you refactor the content for Gen AI. So I'll tell you the interesting paradigm that's happening so right now. So this is the old paradigm. In the old paradigm, let's assume how people discover knowledge. They always used to Google search and then they land up on your documentation and then they go to your knowledge base search and then they put some keywords and then find the information they need. This is a convoluted kind of process, a long step process, and there is always a human, okay, involved to accomplish the task. They are the ones who read the documentation, but when the geni came, came in, what actually become is it becomes an interface between the human and the documentation. As a human, I no longer go to your documentation. Of course you can, but there is this interface gen a interface that's there to get the information that you seek, any specific information you seek, and then through which the human can actually interact with. And what that article is talking about is how do you tell this Gen A agent, how do you write for this Gen A agent so you can actually understand and then translate that content that your customer need? Okay, it acts as an interface between that, and when you write for a Gen A AI, it's a very different paradigm. To be honest, the reason is all this large language model with the gene technologies built on or text hungry applications, which means you have to produce a lot of text in the documentation. But as a technical writer, we always have this minimalism concept because as a human, we have a less attention span and then we take into the characteristics of the human audience and we write for it. But it's the other way around for the jenna. You got to produce a lot more content, much more elaborative content for jenna. So that's one paradigm which we talk about.

Selvaraaju Murugesan: 34:00

And then the second aspect, zora, is in terms of how do we structure this content. Okay, for example, when you talk about writing content, you always talk from h1 tags to H6 tags, and then that's how you nest the content based on your information architecture. You have and you need to have that content hierarchy nicely detailed out so that the JNI can actually understand the concept a lot more holistically, because most of the JNI tool they work on either something called as a RAG architecture retrieval, augmented architecture where you chunk the content. When you chunk the content, it loses context. Let's say, you chunk at the H3 level, then you lose the H2 and H1 information. So I fundamentally believe that content hierarchy plays a huge role in terms of the architecture. So that's the thing that I talk about, and the other one is in terms of zora is in the table, because we love tables, but the llm to actually understand the table, it's a different ballgame. It's very hard to do, especially I've seen where the documentation, where they use the cross mark to say yes in a lot of documentation, but when you send it to an llm, cross means it's no. That's how it actually infers the information. So that's why you have to refactor the content in terms of make it suitable for an llm to actually consume.

Selvaraaju Murugesan: 35:18

And then the third important thing I keep insisting to a lot of people in the technical writing world have a good business glossary. Curate all the business term that you use and use it consistently across all your knowledge base articles. The moment you use synonymous terms, you are introducing ambiguous content actually, and that confuses the Gen AI to hallucinate more. So having a good kind of a business vocabulary and using consistently is a good practice to write for Gen AI. The other most important thing is when you write technical content. In the old paradigm you don't always add metadata. When I say metadata, you add information like when was this image created, who was the author, what is the alt text, what was the table. If the table information has any kind of acronyms, you abbreviate it. Any kind of rich metadata, you can actually add it to your content. Gen A tool can actually use that to produce a lot more accurate answers. So that's the kind of five themes of a concept I talk about in that, reflecting the content for jna readiness zara fantastic.

Zohra Mutabanna: 36:23

So you're literally telling me to unload everything that I have done to move away from minimalism?

Selvaraaju Murugesan: 36:28

this is hard for me yeah, but just remember, in the future people are not going to go into your documentation directly. They're going to come with this jna interface and if you go to any documentation sites or at the moment, everybody's powered with jna, right, everybody wants this chat gpt like interface on the top of your documentation because that's the need for the hour. If you're not tuning to your customers behavior shift, you're out. Because why would a customer want to? If they want to know a specific piece of information, why would they want to spend a few minutes okay, or 10 to 15 minutes, okay, putting a search keyword, going through that particular article of yours and then skimming through all the content and then finding out what they need. Instead, they'll go to a chat GPT like interface type in the question, get the answers and then get out of the platform.

Selvaraaju Murugesan: 37:17

And that's what the need of the hour is, because people are pressed for time here. And why this behavior shift happens? Thanks to twitter, people can't no longer read more than 140 characters. Thanks to shots and reels, they no longer can't watch more than 30 seconds videos and, as a technical writer, we had so much content, so much videos that are more than 30 seconds long. It's not going to tune to the gen alpha, gen z or gen y kind of customers we have.

Zohra Mutabanna: 37:47

It's the technology and then the behavioral shift that's pushing people to this new paradigm and, as a technical writer, we need to produce it for that, for that medium basically I was just joking when I said I don't want to unlearn, but I think this is exactly what needs to happen, where we need to be creative in how we approach our profession itself and unlearn, probably because the tools that we are going to use and the way we interface with them to manage knowledge creation, as you said, is going to look different in the future and I think, to some extent, probably I am already experiencing the business glossary, the lack of consistency that we are revisiting, and I am seeing a lot of chatter about it around me.

Zohra Mutabanna: 38:31

Let me put it that way Also, with no beta data and how your content is tagged and also how is content archived Because, again, this is where I think technical writers become relevant no-transcript and managing that content, making sure that it is accurate when you say accurate, what does it mean in your environment? Coming up with a definition of accuracy and all those things, and then, of course, making sure that your content is rich. I mean not dropping your minimalism principles, but then thinking about how is AI going to consume this?

Selvaraaju Murugesan: 39:11

Correct, correct, exactly, so you can look. You can think about ways of. I know there's a lot of compromise we have to make. Do I write for humans, who are still coming to my documentation, or do I write for a Gen A bot where the future would recommend people to go and adapt a generic kind of a search technology? Put a tool on the top. Then you look at how many people are actually using search keywords and how many people are actually asking questions in this new chat GPT-like interface. Okay then once you have the numbers, it can actually tell you the story, how many people are actually using and where that option is numbers. It can actually tell you the story how many people are actually using and where that option is. You can actually track the numbers over a period of time. And if more queries are coming to this chat gpt like interface, maybe you need to switch. People are no longer interested in reading your documentation. They come to chat gpt like interface. They ask a question in a documentation where they get the answers and then they just move on to a product or try to accomplish some soft, some task with the new knowledge they actually gain. And if that's the behavioral shift you are seeing with the data then shift.

Selvaraaju Murugesan: 40:24

Then your content has to be a lot more elaborate. You put a lot of faqs in the document to make the output a lot more deterministic. Then you have a lot more enriched vocabulary and use the terms consistently. You add a lot more deterministic, then you have a lot more enriched vocabulary and use the terms consistently. You add a lot more metadata. Then you do all this refactoring of the content to suit for them and that could be the new paradigm. We need to shift and that'll be a fascinating word. Absolutely. Look, if you look at it, people are having conversation with your documentation. Usually, when you have conversation, you always have conversation with your support agent, but I have seen people having conversation with documentation. I mean, that's a new paradigm right, right, that's a great perspective.

Zohra Mutabanna: 41:04

Salva, you know you mentioned that your company makes tools for technical writers, and are these considerations being taken into account?

Selvaraaju Murugesan: 41:14

yeah, absolutely, absolutely. Look at Documentary City. We recently launched a Gen AI kind of technology called Eddy Eddy AI and it actually covers two aspects to it. We cover in terms of content creation or the knowledge creation, where we provide a lot of tools for making technical related jobs very easy in terms of creating an outline or creating a template, or how do I rephrase it, how do I improve the content in terms of flow, cohesiveness, checking grammar, punctuation and everything. And we also build tools for reducing this content management.

Selvaraaju Murugesan: 41:47

When I say content management, producing SEO, metadata, alt tags, alt text for images tags, related articles how do you add related articles to a particular thing? Title recommendations for articles so all these admin overheads that a technical writer do. We have tools to actually offer suggestions to technical writers, to pick one based on the intelligence that we gather around the content. And the other side is in terms of the search experience. So we have ADI Ask ADI where it can actually produce a chat, gpt, like a Q&A kind of a module on the top of your documentation, and it is very conversational in nature, where you can have conversation underneath your knowledge base.

Zohra Mutabanna: 42:30

Is ADI is something that you can expand, that Is that an acronym?

Selvaraaju Murugesan: 42:35

No, it's just a name. We give it to this AI because we don't want to call it as a AI.

Zohra Mutabanna: 42:41

I see, so it's the name of the tool.

Selvaraaju Murugesan: 42:43

It's the name of the AI. Yeah, yeah, it's like Alexa and Siri. We want to give it as a cool name, like AD.

Zohra Mutabanna: 42:48

Yeah, oh, ad Got it. I'm like huh, what inspired 80 got it, yeah. So I think that would definitely benefit us considering how we have to pivot and rethink our roles.

Zohra Mutabanna: 43:03

we've covered some good ground here salva, I think we've had a pretty wholesome conversation about where technical writing was as a profession, what we should be thinking about and how it's going to evolve. We've covered that whole gamut. We've talked about refactoring of the content that we need to be thinking about and all the good nuggets in there. Anything else that you would like to add?

Selvaraaju Murugesan: 43:25

Not so much, but one of the key vision we have is, especially for technical writing. Just focus on knowledge creation and that's where the whole thing around technical writing would come in. And I think if you focus only on that new knowledge creation and just remember, new knowledge can can happen anywhere in the organization, it can happen over a coffee chat in a kitchen or maybe an informal coffee chat in a cafe the most important thing for a technical writer is to capture that knowledge at the source, the new knowledge at the source, and maybe with the help of ai, with the data integration, anything, let it, let it enrich, but most importantly, you need to mobilize that knowledge and I think that's the value of the whole. Documentation would come in, especially with the technical writers profession, and I fundamentally believe that if the technical writers can focus on that particular mission of theirs, I think they would succeed in the future generations to come yeah, that's awesome, but that brings up a question in this remote experience that we are all in to a large extent.

Zohra Mutabanna: 44:32

The coffee chats are far and fewer, so how do you suggest we mobilize that content?

Selvaraaju Murugesan: 44:37

go to office. I'm just joking. It's very tricky given that we are in the remote situation. But, having said that, if any of these conversations can be digitally accessed or digitally stored or digitally captured, you can use that knowledge. I fundamentally believe that a lot of conversations happen over Zoom, call and Slack chats, just like you and I are doing right now.

Selvaraaju Murugesan: 45:02

Yeah, yeah, absolutely. And then what if we have a small chatbot in the Zoom called Zora and then it writes all the write-up for you as a blog or based on your instructions? Maybe it can create shots, videos and stuff like that that captures things. It's all happening at the moment, okay, and that's what the world is getting, yeah.

Zohra Mutabanna: 45:20

Yeah, I mean that question was really to kind of for us to think a little bit about from a company culture perspective. There is a lot of this demand to return to office.

Selvaraaju Murugesan: 45:33

And.

Zohra Mutabanna: 45:34

I think, where there is collaboration happening and collaborative tools, that is also a place where content is being created, and I'm in conversations where, like you said, content at source that is being created, knowledge is being created at source and for companies to be keeping that in mind as well, because content, that's another area probably where I mean I'm not in favor of one or the other, but as we become a globally connected world, we are being remote and we are creating content in new ways, knowledge in new ways.

Zohra Mutabanna: 46:06

And that's something to keep in mind, especially for the upper leadership. To keep that in mind, yeah, absolutely it doesn't have to.

Selvaraaju Murugesan: 46:13

When I say that new knowledge has been created in another part, the new knowledge can also can happen through a lot of support tickets that you have.

Selvaraaju Murugesan: 46:20

So that's the support team, and I'm pretty sure in your organization, or many of the organizations where the technical writer is part of, they have a weekly cadence or a monthly cadence with their support team to sort out how many queries actually came in where documentation could be a touch point, or how many support details you have got for which the resolution is in the documentation and how many of them don't.

Selvaraaju Murugesan: 46:44

So you create new knowledge, you enhance the knowledge. But, having said that, if you can make all these tools integrate, talk to each other, the tools can automate this and all the technorators have to do is get the information for accuracy and let it go live. And and the other thing is the sales and customer success calls and they are the biggest source of knowledge for a technical writer to listen to, to find out what the exact vocabulary a customer actually use when they mean a certain feature or certain functionality, and that can that can be incorporated into the documentation right away. So a new knowledge for technical writers can happen across the whole user journey with that product, when they come in as a lead and then all the way before they churn. I think technical writers have to be involved in that entire customer journey to enrich the documentation, and I fundamentally believe that they can actually do this. It's a lot of work, but guess what? It's an efficient work if you have ai with you absolutely.

Zohra Mutabanna: 47:42

I think I really liked how you put it. We have to be part of that entire user journey. We have to be more proactive. What I really like the most was how technical writers have to start thinking about how do we show up on the business side, because at at the moment, we are pretty much downstream. And with the whole automation and the data, the tool integration that AI can do for you, this is our opportunity to really show up on the business side.

Selvaraaju Murugesan: 48:07

Yeah, absolutely Zara.

Zohra Mutabanna: 48:08

And on that note, Salwa, thank you so much. This was a fantastic conversation. I really appreciate your time and for bringing this great perspective to my profession.

Selvaraaju Murugesan: 48:18

Thank you, Zara, for hosting me. It's a pleasure talking to you as well.

Zohra Mutabanna: 48:21

Absolutely. Thank you. Subscribe to the podcast on your favorite app, such as Apple, spotify or YouTube Music, for the latest on my show. Follow me on LinkedIn or visit me at wwwinsidetechcomshow. Catch you soon on another episode.