Knowledgebase Ninjas · 2026-06-30 · 15 min
Key moments - from our scoring
Substance score
55 / 100
Five dimensions, 20 points each
Steev Kundukulangara brings a unique perspective shaped by his transition from technical support and systems analysis into technical writing. Rather than fearing AI replacement, he frames the challenge differently: the volume of technical writers needed may decrease, but their strategic value increases. The core argument centers on domain expertise and accuracy validation - something AI cannot self-generate. When organizations deploy AI chatbots or LLM-based solutions, they need technical writers to structure knowledge properly, ensure accuracy, and define audience needs. Kundukulangara emphasizes that today's documentation practices won't survive the next 3-5 years due to shrinking attention spans; instead, documentation should shift into products as contextual help, chunked into bite-sized pieces. He describes implementing AI agents using compressed style guides to review his own work, discovering that accuracy matters more than information volume. For technical writers navigating this transition, the key differentiator is developing AI-ready documentation structures - clear headings, proper relationships between document sections, and chunked content - that systems can consume effectively. His advice: explore AI tools like ChatGPT, Gemini, and Claude; understand where your domain is heading; and publicize your work to build recognition.
AI won't eliminate technical writers but will reduce the volume needed; however, technical writers become more valuable because they possess domain expertise to validate AI accuracy and structure documentation for AI systems to consume effectively.
AI produces outputs that are not 100% accurate, so human-in-the-loop review is essential - only someone with deep domain knowledge can verify whether the AI output is correct before it reaches users.
Static, long-form documents won't survive; documentation will be compressed into brief, contextual in-product help and pop-ups that appear when users face specific errors or issues, matching shorter attention spans.
Documentation must use clear headings, proper audience definitions, chunked sections with defined relationships between them, and accurate, crisp information - not dumped raw data - so AI systems can consume and leverage it effectively.
Steev recommends exploring AI tools like ChatGPT, Gemini, Deep Seek, and Claude to increase productivity; the key is learning how to use these tools effectively rather than avoiding them.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains some substantive points about AI-ready documentation structure, the importance of domain knowledge in validation, and future trends in documentation (shorter chunks, in-product help). However, substantial portions are filler - rambling personal anecdotes about LinkedIn visibility, self-promotion advice, and vague motivational statements ('keep exploring'). The core insight that technical writers should focus on accuracy validation and chunking is valuable but takes 12 minutes to extract from 15 minutes of content.
For that you need to have a good domain knowledge. You need to be well versed with the product that you are handling. So those are information which AI cannot have it on its own.
It should be chunked, it should be split into multiple sections. It's like the limited information, but that limited information should be accurate and it should be crisp.
The core argument - that human expertise is needed to validate AI outputs and that technical writers should focus on chunked, in-product documentation - is sensible but represents mainstream thinking in the AI+docs space circa 2024. The guest recycles familiar frameworks (human-in-the-loop, shorter attention spans, structured data for AI consumption) without contrarian edge, novel methodology, or first-principles challenge to conventional wisdom.
the human in the loop aspect that you always have to factor in
in the future even like people will have even less attention Spanish
Steev Kundukulangara is a Senior Technical Content Strategist at Teradata, a legitimate database/analytics company, with genuine domain experience spanning technical support, systems analysis, and technical writing. This is a real practitioner, not a pure consultant or thought-leader. However, his visible impact is constrained to conference attendance and LinkedIn - no evidence of shipping large-scale documentation systems, leading teams, or measurable outcomes that would indicate top-tier operator status.
Senior technical content strategist at Teradata
I am working like I have implemented kind of AI agents for writing, for reviewing my documentation
The episode lacks named examples, metrics, and concrete data. The guest mentions implementing AI agents for documentation review and compressing a style guide from many lines to five-six lines, but provides no company names (other than Teradata), no performance benchmarks, no before/after comparisons, and no timeline. The advice is largely abstract (chunk documentation, validate accuracy, focus on clarity).
I initially dumped all my style guide into the AI and it was hallucinating and it was giving all kinds of rubbish answers. But then I compressed that old MD information into like five to six lines
The amount of technical writers that was needed to work on a particular product has reduced significantly, like with the help of AI
The host (Speaker B/Gauri) asks opening questions competently but rarely pushes back, challenges claims, or pursues specific follow-ups. When the guest makes broad assertions (e.g., 'organizations that are laying off technical writers completely...will see what kind of bad decision it was'), the host does not ask for evidence. The 'rapid fire' section devolves into soft softball questions ('one word that comes to mind') rather than probing deeper. There is minimal tension or productive disagreement.
So today's documentation, uh, do you think it won't survive the next three to five years?
Got it, Got it. Now, uh, with AI, everybody can produce content much more easily, right?
Computed from the transcript - who did the talking, and the words that came up most.
In this episode of Knowledgebase Ninjas, Steev Kundukulangara from Teradata talks about how AI is reshaping the world of technical writing. He shares his honest take on whether AI will replace technical writers, and why their skills are still very much needed - especially when it comes to making sense of AI-generated content. Steev also touches on why accuracy still depends on human expertise and how shrinking attention spans are pushing documentation to become shorter and more in-the-moment. The conversation wraps up with Steev's experience experimenting with AI tools for his own documentation work and a simple but interesting lesson he picked up along the way. Thank you for tuning in! In the meantime, if you're ready to explore Document360, a knowledge base platform that can help your customers and teams get instant answers, we’d love to invite you to try it first-hand. Simply use this link - to start your free trial.
Transcribed and scored by The B2B Podcast Index.
Speaker A: How do you know whether if it's accurate or not? For that you need to have a good domain knowledge. You need to be well versed with the product that you are handling. So those are information which AI cannot have it on its own. Like that's where a human aspect comes in. We are in a better position to write better knowledge for these chatbots.
Speaker B: So today's documentation, um, do you think it won't survive the next three to five years?
Speaker A: In the future even like people will have even less attention Spanish. So when you're writing documentation like your focus should be to reduce what you call compress lot of information into like little sentences. Documentation should be living inside the product or whatever documentation that we are writing. It should be chunked, it should be split into multiple sections. It's like the limited information, but that limited information should be accurate and it should be crisp.
Speaker C: Welcome to the Knowledge Based Ninjas podcast where Gauri Ram Kumar of document 360 finds the best SaaS self service knowledge bases in the world and then interviews their creators. Let's get started with today's episode.
Speaker B: Welcome everyone to the Knowledge Based Ninjas podcast. Today we have Steve Kurankara, senior technical content strategist at Teradata. Hi Steve, how are you doing today?
Speaker A: Hi Gauri. Good evening. Yeah, I'm doing great. I'm excited to be on the podcast. Like this is my first podcast so like looking forward to see how this interaction goes.
Speaker B: Fantastic. Yeah, thank you so much for taking your time and um, yeah, we are also excited to hear your experience so far in this uh, space. Now before we start talking a little bit deeper into the current topics, I just want to hear from you. How did it all begin? And uh, just give me a little background about yourself and uh, yeah, who was your inspiration to decide on technical writing?
Speaker A: Yeah, so like when I started off my career I was into technical support domain. Then I moved on to become a system analyst and like, and in during this uh, period of technical support as well as system analyst, I have been doing documentation for my companies where I was working. But uh, it wasn't categorized as a technical writing, uh, designation as such. But it was like it was a combination of multiple responsibilities. So and technical writing was part of the responsibilities that I was handling. And uh, like after some time I realized that uh, like technical writing is something that I can actually contribute more and I could be a good technical writer. The reason being with the extensive knowledge that I have gained through the system analysis that I used to do and the technical support work that I used to do so. I had the technical know how so and my focus then was to improve my writing. And then that's how actually I, you know, I decided to become a technical writer because there is a reason why there is technical in technical writing. It's not just any other designation wherein you say content writing or you know, there are like different, different writers but technical writing, there's a specific reason why there is technical word inside the technical writing. So and I, as I have gained over the, over the uh, work experience, which knowledge that I have gained, I wanted to put that into practice. So that's how I, you know, transition my role role into a technical writing.
Speaker B: Fantastic. That's great to know. And uh, to be really honest, it's very different to what I used to hear from other guests. But um, how are you enjoying by the way?
Speaker A: Yeah, I mean initially there were a lot of hiccups. As you know, it was something that I was transitioning from a uh, technical role into uh, writing space. So there were a lot of hiccups and there were uh, feedbacks that were coming from my colleagues as well. Like this is the kind of designation wherein you are not getting valued in the organization. You know, there will be less uh, what you call like less visibility for you in the industry, in the work that you are doing. But then like, like I don't uh, what you call, put that much heat into the negativity but more into like what the. Whether it will be useful for me. Will I be, will I be enjoying the job? That's what that was more of a uh, positive thing that I was looking at. And yeah, since I transitioned into that role I have like, my visibility have increased. Like if I go to any tech writing conferences, people are always recognizing me as Steve. I know Steve. And you know, so. And people are always looking out for my LinkedIn post when I, like I have been bit dormant on my LinkedIn for a while because of my work commitments. So like whenever I post something, people are always commenting. Whenever I go to any conferences, people are always looking out for me. So that is the actual motivation for me. You know, I keep posting, I do conferences, I share my knowledge. And so all these contributions are actually that's what I'm enjoying if I want to be friends.
Speaker B: Nice. Very good, very good. Fantastic. Great. So now I'm going to talk about AI as your, as your very first conversation. Um, because as you are actively participating in multiple social media and uh, conferences now, do you think AI will reduce the need for documentation or will it Increase the need for better structured documentation.
Speaker A: There are two aspects, like will AI replace technical writers? You know, that's something which everybody talks about a lot from, from what I have seen and I am not an expert in, you know, to decide, okay, technical writing is going away, or, you know, I have not that position and I'm not in a position to talk about that. But yeah, like the amount of technical writers that was needed to work on a particular product has reduced significantly, like with the help of AI. Like the amount of work which a technical writer can do is more compared to before because tools are already available for you. You just have to, you know, you should be having the technical expertise to make the best of it. If you look at all these, uh, LLM models that we are currently using, the ChatGPT, the flawed and Gemini, all these kind of tools, the data that was ingested into all these platforms are written by linguistic specialists, PhD scholars. You know, these are the, these are the individuals that have actually contributed to the making. I mean, these are the data that was ingested into all these, uh, AI platforms. The reason this data was used because they are, they have good command over the language. They are, you know, expert in, uh, communication because if you put garbage inside the AI system, it will be garbage that you will be coming out. But they needed a good information. That's why they use, relied on these individuals for data engine. Similarly, if, if we have a company wherein they need to use integrated chatbot, who will be in a better position to write this documentation? It will be technical writers. Because of the extensive knowledge that we have gained over the years, uh, we are in a better position to write better knowledge for these chatbots. We, you know, we are good at uh, writing for good audience. Who we are, we are good at deciding, okay, will this information be useful for the end user, how information should be chunked? It should be, you know how like there are a lot of uh, technical stuff that we do, not just about writing content. So from my understanding, we are in a better position and like organizations should always, uh, keep some kind of budget for the technical writers so that they can expand more, they can expand their skills, they can look out for how to make their uh, chatbot or wherever they were, wherever the value they can bring into the system.
Speaker B: Got it, Got it. Now, um, with AI, everybody can produce content much more easily, right? So content making content is not that difficult anymore. But, um, then what becomes the hardest part of documentation? Steve?
Speaker A: Now everybody is relying on writing the content through AI and it's quite common. Everybody should be aware of, Aware by now that you know whatever you're writing through the help of AI, it's not 100 accurate. Like there is the human in the loop aspect that you always have to factor in. So when, how will you have that knowledge? Okay, now when you give something to AI and it produces the output, how, how sure are you, whatever input, whatever output the AI is giving, how do you know whether if it's accurate or not? For that you need to have a good domain knowledge. You need to be well versed with the product that you are handling. So those are information which AI cannot have it on its own. Like that's where a human aspect comes in. So women in the loop is something you know, we have to factor in. Like it's not just for us, it's what organization also have to factor in. Because I have seen organizations that are laying off technical writers completely because they believe AI can do the job. But I don't know, like they might see the, may not see the impact very soon but in the long run they will see what, how, how, what kind of bad decision it was.
Speaker B: So today's documentation, uh, do you think it won't survive the next three to five years? What's something today about documentation? Do you think it won't survive for the next three to five years or what should be the strategy to make it like a lifelong uh, or to, to stay a bit longer.
Speaker A: So from, from the knowledge and from what I have seen in the industry like this, we have long past that time wherein we'll be writing, you know, static videos, long pager documents for the customers. Like we hardly, if you look at the current generation, there's hardly anybody who will have a more than 30 second attention span. Because of all the social media addiction that we are currently even I am one of the 34 victim of that because I can't have more than 30 second attention span. So if we are uh, in the future even like people will have even less attention Spanish So when you're writing documentation like your focus should be to reduce what you call compress lot of information into like little sentences. Let's say if I'm using one particular product and when I'm doing something inside the product, if I have some issue, if I face any error, I should be having some kind of pop up that will come and say hey, you are facing this issue because uh, something went like some kind of message should be displayed ah, on the screen. You know, that will help the user to understand okay, this was the reason why the Error occurred. So that's more like a contextual help in product health kind of a thing that we should be looking for like. So instead of reading a whole uh, pager documents we should be documentation should be leaving inside the product.
Speaker B: Right. So I think the next question kind of relates to my very first question that we started. How do you think AI ready documentation structurally differ from the regular documentation?
Speaker A: So in AI ready documentation what we are doing as a technical writer is we are writing for the system and uh, systems requires clear structure, clear headings and uh, there should be a proper, what uh, you call audience that has to be defined. There has to be information has to be properly structured. It should be, there has to be a relationship between different uh, different structure of the document. So and all whatever documentation that we are writing it should be chunked, it should be split into multiple sections. So that's how the AI system will be able to consume and make the best use of the documentation that we are writing now. Quite recently I am working like I have implemented kind of AI agents for writing, for reviewing my documentation that I have written. So what I did was I initially dumped all my style guide into the AI and it was hallucinating and it was giving all kinds of rubbish answers. But then I compressed that old MD information into like five to six lines and when I looked at the output I was quite amazed because I realized that it's not just a dump of information which uh, improves the AI performance. It's like the limited information. But that limited information should be accurate and it should be crisp.
Speaker B: Yeah, I think that everybody's got a long way to go in this space is what we could infer at the end of the day, isn't it? Yeah. Let's move on to your rapid fire round questions. Uh Steve. So I'm sure by the sounds of it you keep reading a lot of resources but anything that you can suggest to our audience today, particularly on documentation space.
Speaker A: For me like I mainly rely on AI tools. I go to Gemini, I go to Deep Seat, I use Plot, I use chat GPT. So like these are all my, you know, go to resource. Like I don't have to what you call as I said I have a very less attention span. So for me to, I need fastest information. So what is the uh, fastest way to get information? This AI rights, you know using this AI tool. So whatever information I, I can ask stupid questions. I, I don't have. I, I mean AI doesn't mind, they know that I'm a stupid person. So anyway it will Give me the right answer. So that's what the. Like you keep exploring the AI tools, find out the best way to use AI tools. That's how you will be able to increase your productivity is what I believe.
Speaker B: Okay, so one word that comes to your mind, uh, when you hear documentation, Clarity. Okay, thank you. My last question to you is a piece of advice you would give to your 20 year old self.
Speaker A: Yeah, so if I have, if I was a 20 year old, I would say keep exploring. You look, look out for the future. Like be in the present, but look out for the future. Always look for where exactly our domain or wherever, what, whatever work we are doing, where exactly it is heading into. So that's where you will be. That's when you will be able to create a leverage for yourself in the industry.
Speaker B: Okay, that's great. So I try to do justice to your experience and uh, cover as much as possible. But anything else you'd like to add to um, our audiences?
Speaker A: Yeah, I mean as I said, like the same advice that I gave for the 20 year old myself. Similarly, whenever uh, like all the technical writers out in the whole world, I want to just say keep exploring, keep trying out new, new inventions, new discoveries. Keep. And publicize it. Don't, don't just keep it to yourself. Publicize it. You wouldn't know how useful and you know how beneficial it is for you. Only unless and until you go public with it, people won't recognize the effort that you are doing. That's what I did in my previous organization as well as we are working in a fintech domain. I was like, I was previously working in a fintech domain. The knowledge was always internal. Like people wouldn't know the kind of contribution that I was doing over there. So when I went public with it, that's when people actually started realizing, oh, this is the kind of work Steve used to do. So yeah, don't keep everything yourself, everything to yourself. Keep exploring, keep, go public with it. Let people know that yeah, there's somebody called Steve and let them others know that yeah, you're doing this kind of work in technical writing.
Speaker B: Great. Fantastic. So all I can tell you is ah, please continue to do the wonderful contributions you're doing to this community and uh, wish you all the very best in your future projects.
Speaker A: Yeah. Thank you G. Thank you.
Speaker B: Pleasure having you.
Speaker C: Thanks for listening to today's episode of the Knowledge Based Ninjas podcast. Please head to iTunes Rate and provide honest feedback on the podcast. See you next week.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
#291 Why Most AI Projects Fail to Deliver ROI, Sinohe Terrero, CFO and COO, EnvoyGrowCFO Show · on Claude91 / 100
Why a $1.2B exit felt like his biggest failure, and the customer-obsession thesis behind AgencyThe GTMnow Podcast · on Claude86 / 100
Is Your Business Invisible to AI Search? (And How to Fix It) ft. Ray YoungRevenue Science · on Claude85 / 100
Episode 018: Season 2, the $75 Consult and the Frankenstein StackAI Tools for Practicing Lawyers · on Claude84 / 100
Agentic Engineering for Testers: How to Automate Your Way to the Top with Amit RawatTestGuild Automation Podcast · on Claude82 / 100
PwC's Chief People Officer on Training 80,000 People for the AI Era With Human Skills at the CenterFuture Ready Leadership With Jacob Morgan · on Claude81 / 100
Technical Writing Leadership in the Age of AI - with Ramesh Aiyyangar, TechWritePro59 / 100
From Developer to Tech Writer: How AI, Empathy & Localization Shape Modern Documentation51 / 100
Role of Cybersecurity Documentation: Beyond Compliance with Abhishek Sahoo42 / 100
No One Wants to Submit a Ticket: Role of Documentation with Rachel Johnson, Ripple
Building Down-to-Earth Documentation: Lessons from Cody Deitz