Zohra 0:02

Hello friends and welcome to season 8 of Inside Tech Comm with Zohra Mutabannna. This season features a collection of conversations that explore the ideas, challenges, and opportunities shaping technical communication today. From AI and content strategy to leadership, product thinking, and the future of our profession. Each episode offers a fresh perspective from people doing the work. Let's get started. Hello listeners. Today on the show we have Vinay Payapilli from Hyderabad, India. And Vinay was introduced to me by Nibbu Thomas. And Nibhu Thomas introduced me to Sagar, and Sagar introduced me to Vinay. So thank you to all of them. We are going to have a great conversation here with that, Vinay. Welcome to the show.

Speaker 0:52

Thanks, Zohra. Very excited to be here.

Zohra 0:54

Yes. Vinay, please tell us a little about yourself, what you do, and where you're at in your career, so that we can kickstart this awesome conversation that I have in mind for you.

Speaker 1:05

Yeah, so I've been in tech writing now for just over 26 years. And why I'm so exact about it is because I remember the exact date on which I landed in Hyderabad and then kind of like got into tech writing. So before that, I was into um instructional design. I used to write textbooks for a computer trading company. The same company asked me whether I'd they were also building a software. So they asked me whether I'd do the documentation for them. I'd never done documentation before. It was with a little bit of trepidation that I bought into it with little idea that for the next 26 years I would, you know, do it and love every minute of having done it. So yeah, here I am writing about six companies down the line. I'm totally enjoying the various, what would you call it, uh, evolutions that uh documentation has gone through. Because I remember initially we would send out Word documents and then it became PDFs that we would email out. Then you had RoboHelp come in, and then you had online help, then it became structured writing. And today we are talking about uh docs as code and things like that. So uh being part of many of those uh moves, and it's been a completely exciting career.

Zohra 2:15

It's so awesome to hear that you've enjoyed this path. And I think that's super important, and that's possibly why you're still in it. And we had a great conversation when we connected uh for a quick chat, and we talked about challenging some of the assumptions around documentation. And that is the approach that I would like to take with our conversation today, because you had some great perspectives that I wanted to dive into. One of the things that you mentioned was when you broke down the documentation process, you've given us the evolution in your background. But then as we look at the documentation process, you looked at the critical path. So we'll talk about what that critical path in your words meant and that writing itself wasn't actually on it. Vinet, please share with us what is it that in that documentation process, what was the critical path that you were thinking about?

Speaker 3:11

Yeah, so one of my subjects in college was operations research, and we had a subject where we kind of like what are critical paths. Now, for those who don't know what a critical path is, when you have any activity, you can break it down into smaller activities. In documentation, it would be, you know, like data collection, reading background stuff, testing the software, writing, review, publishing. Each of these is an individual task. And when you have all these tasks, you know what the start point and what the end point is. And many of these tasks can run in parallel. And once we put that chart, right, what task A is, what task B is, how much time it takes, blah, and you come to a path which is the longest path from beginning to end, right? And every item that is on that path, when there are two items, let's say that are parallel, one taking three days and one taking five days, and then the item that takes five days is the one on the critical path, because any delay in that activity means a delay in the project. While the activity that required three days, you you have an elasticity of about two days, and that delay does not really affect the project. So what I did was I put the critical path. So just to step back, right? Everybody, the knee-jerk reaction everybody had when ChatGPT first came out was hey, the writers are going to be out of jobs because chat GPT is going to do all the writing, right? And uh very quickly we found that ChatGPT wasn't very reliable when it came to the writing in terms of the correctness or the information it had. It was hallucinating and things like that. And everybody was trying to solve that problem. But I kind of like asked myself, hey, what's the biggest problem I have? Is it writing? That's when I sat down and I put the critical path. And I realized that the two pieces that were on the critical path, which actually delayed projects, were the data collection, getting the background information, okay, and the reviews. These were the two pieces that were on the critical path. And any delay in either of those meant a delay in the delivery day. That is when me and my team started looking to see how Gen AI could solve that problem for us. And that's what AI is pretty much very good at. Give it a lot of data sources and say, hey, give me a summary of this. And Gen AI does that very well. That was what we did. We gave all the data sources. Now, in a in a perfect world, you would have a single source of truth, and that would be something like Jira, right? Or a related software. But in the real world, that's not what happens. So some of the information is in Jira, some of it is in Confluence, some of it is in Slack or Teams, and some of it is in the Google Meet transcripts or the Zoom transcripts. So we gave all these data sources and said, hey, why don't you now go in there and give me a summary of what this feature does? What are the decisions that have been taken? Who are the people who hold key responsibilities in this project? And then every time we would rerun this skill, we would also ask it to go identify what changed from the last time it ran to the current run. And that would then tell us the what's new. Like so, if let's say the engineer has changed, or we decided to change a button to a uh, let's say a radio button, all those changes that get documented in these conversations get called out. And that was perfect because before that, we were dependent on somebody coming and telling us this. It is common for one technical writer to handle multiple features in a product, and in some companies, even multiple products. So if we were to go and attend every stand-up and read every Slack conversation, that would we would have only time for that. That would kind of like just freeze us. So having something like this that went in and basically participated in those conversations in terms of listen to everything and then came back and gave us a synopsis of what happened and the key points meant that the writers were now free to actually focus on the writing part. And more importantly, we were not dependent on somebody coming and telling us that a decision had been taken. We would get that from the AI. And then if we wanted clarity, we knew exactly whom to go and ask that question to. Hey, what does this change mean? So it took away a lot of the time-intensive stuff and let us focus on things that were key to the activity of writing. So, yeah, that's how the critical path thing kind of like rolled into this.

Zohra 7:29

You kind of gave us a I didn't know the textbook definition of critical path. So having that was a good thing to know. Uh so thanks for that. And then also I've also encountered in my recent day-to-day, probably in the last few months, with how that process has changed, where the upfront getting the information and then the reviews itself. In fact, I'm noticing that those bottlenecks have gone away in a sense. Which I think is empowering the profession of technical writing. So with AMI now, we know it can write. There's a lot that goes on with writing. It's not just what it's the whole process, as you talked about. There are multiple stakeholders, multiple moving pieces. So all that needs to come together. And AMI, you give a prompt, AI is just gonna do that. You need a better context and who brings that. It's the writer. We also talked about so much of the early AI conversation focused on the generating content, which you already touched upon. Whereas your team has been looking at other parts of the workflow. So if writing isn't the bottleneck, have we spent too much time asking whether AI can write documentation and not enough time asking what problems AI could solve?

Speaker 8:44

I think that's true. Even when it comes to writing, I think there are what we forget when we are having these conversations is that there are different types of articles we write. We don't write the same type of article. Or it's not just one type of article that we write. Let's say, for instance, I'm just taking an example here. Let's say I build a software which allows you to make payments, you know, something like GPA or something of that sort. And now, let's say it's a B2B kind of thing, right? So for one business to make payment to another business, right, instead of the interpersonal payments that we are familiar with. Now, let's say we also open a wallet, right? So we give the customer an option that, hey, you can have a wallet where instead of having multiple transactions in your bank statement, you make one large transfer to your wallet, and then all the smaller transactions take place from the wallet. Now, you can either do that, or what you can do is if you don't want to use the wallet and you don't want to use your main account, you can create your own account. So there are two ways to do this. You can use my wallet or you can transfer it to a specific account from where you are then making those transactions. Now, to document this feature, there's a couple of things. Now, how to make a payment? That's a simple document to write. And I think that kind of document can very easily be written by AI. Because if you look at code, what is code? Code is a series of steps that have to be performed. It takes some inputs from the user and some other inputs which are already in the system, which mostly are what we call prerequisites. Those are already in the system, and then there are some human inputs, then there's some magic that happens, and then there's an output. And that's exactly what code is. And AI can very well look at that code and say, hey, these are the steps you need to do to complete this task. What AI can't do is help me decide whether I should use the service provider's wallet or I should have my own bank account. What are the benefits of doing one or the other? Because everything is a choice. And that document, okay, AI can't write. Okay. So I think it's very important to understand what kind of documents AI is able to write versus what kind of documents we it can't write or the human can write better. If there is something that is how to complete a task kind of document, I would be very comfortable having an AI that's constantly looking at the repo. And every time there's a change, the AI makes a decision on, hey, does this affect the user's workflow or not? And then if it does affect the workflow, let me update the documentation and then create a PR and then the human checks it and then publishes it. But would I be comfortable with AI writing a document on, hey, why do you need this solution? How does it change your life for you? What process changes or efficiencies would it bring to you? And what changes do you have to make inside your organization to be able to benefit from the efficiencies that this software is going to give you? That is not documentation that I would trust AI with. It would require a lot of human input to be able to do that. So I think more important than can AI write or not, is what can AI write? What kind of documentation can AI write? And then once we identify that, then it becomes a lot more clearer as to do I need as many technical writers in the team or not? How much work can be outsourced to the AI? Those questions can only be answered once you're clear which of your articles can be written by AI versus which those which cannot be.

Zohra 12:14

The process is evolving, and as we recognize where AI can be of help or not, is your team evolving with that? And are you feeling that tech writers need to be bringing special expertise?

Speaker 12:29

You know, one thing that I always say, and this is a divination, but something that I always say is the two toughest roles to recruit for are the product manager and the tech writer. Now, the reason I say that is neither of these two carry over anything from their previous job to their next job unless they are moving within the same vertical. Let's say one day I'm writing for a telephone mobile company. The next day I'm writing for let's say something like an online payments software. There's very little expertise that I am carrying over from my previous job to my next job. If I'm somebody who goes in-depth into the product, yeah, I mean I can I can bring the writing stuff. Okay. But really speaking, how difficult is that? I mean, it's pretty much look at this and write. The real skill that you're looking for is is this person able to dive deep into the product that they are documenting? And are they able to understand the nuances that drive this particular industry? And that's very difficult to measure for, isn't it? So does it change the way or you know what kind of person is going to be successful? It's going to be somebody who is ready to dive very deep into the product. There are a couple of things we need to sort of like take into account here. A lot of our writing processes, I believe, are holdover from the days when we used to write for kind of like I would say household goods, like how do you use a washing machine or how do you use the oven. And I think we continue to do pretty much the same kind of writing today when we have software where the UI can be made as intuitive as possible. So I don't think we've sort of like graduated out of writing for that kind of hardware. So that's one change that we really need to look at. As writers, we shouldn't be like the guy who has a hammer and then everything he sees is a nail. We should be ready to push back and say, hey, you know what? I could write volumes on this subject, but unless the UI is fixed and the process is fixed, the user is still going to have trouble. Right. I remember that there was this one product that I used to document, and uh it was for an industry that had a lot of churn, right, in their employees. We had an employee module, and let's say you didn't want the employee to appear on the main screen, the employee's name to appear on the main screen so that he or she is assigned to a task. What you would do is typically go into the employee module and you'd search for that employee, and there's a delete button there. You'd delete their employee. Okay. And then when you go to the main screen, the employee doesn't appear on the main screen and can't be assigned to any of the tasks. Great, works for me. I don't, I'm not going to read documentation now because it's done what I wanted it to do. What did I want? I didn't want the employee to appear on the main screen and to be assigned tasks. That was my need. And I was able to achieve it. So I'm not going to read the documentation. But since I didn't read the documentation, what I didn't realize is when I delete the employee, I have deleted all this employee's records. So every payment I have made this employee for salaries and things like that, all of that has got deleted. And what we would find is at the end of the year, when the employee would ask for their tax receipts, you know, their tax sheets, whatever that needs to be filed, uh, okay, I wouldn't be able to find it. So then I would have to create a support ticket on my service provider and say, hey, can you go back into your backups and get me this information? So every March we would have the spike of tickets that came because people wanted tax information about employees who had left their employment. So and no matter how much we tried to tell them that this is the problem, they would keep saying, no, just document it. And I'd be like, it's documented, right? It's just that nobody is reading the documentation because there is no need to read the documentation. It's very intuitive. I see the employee, I see a delete button, I do it. So then what I did was we used an invisible button on top of the real button. So the user thought that they are clicking the uh the delete button, but they were actually clicking my invisible button. And there we would ask them if you delete this employee, you're going to lose all their records. Do you want to delete the employee? Or do you, or is the employee leaving the organization, in which case you have to put the last working day? So something to that uh effect. And what happened was we found that over 90% of the users actually clicked, I want to enter the last working day. And then we were able to take this to the development team and say, hey, we need to fix this. It will solve 90% of those tickets that come in March. And we were able to get it done. The thing is, you've got to be ready to do those kind of experiments. So, why I told you the story is I can write as much content as I want on how to do this correctly, but it's never going to get solved because the solution is in the product, not in the documentation. So, as documenters, it is very important that we ask ourselves: is this solution the right solution for my customer? If I put it in my documentation, does it solve the customer's problem? Or are we just washing our hands off it and saying, hey, you know what? It was there in the documentation, you should have read it. We're just transferring the responsibility from the product team or us to the customer. I don't think that's the way to retain customers. Something I like to say is my team today, we are at that point when somebody asks us to jump before we ask how high, we ask why. If you give us a good enough reason to jump, then we'll jump as high as you want. But the first question is why? Why are we jumping? And I think as documenters, that is something that we should keep in mind when we are documenting. So that's one kind of documenter. The and that relates to a completely different piece, right? And I think we discussed this on our previous conversation offline as to the key requirements of what makes a technical writer. Uh, you know, I remember when I started out way back in 2000, if you applied for a job in my team, the first thing I would look for is, hey, can this person write in English? And then the rest of it we can train them. But today, I don't care what language you write in. You could write in Gujarati for all I care, because my customer who's sitting in Japan is anyway asking the question through an AI bot, which is going to translate what you wrote into Japanese. There again, things have changed a lot. The one skill that tech writers needed to possess is no longer important. It's gone out the window. And it's now the person who can actually sit and understand the product, understand the customer, and then write in a very clear manner what is required in any language. I don't care what the language is. So I think these are the two big shifts I have seen. One is we should start pushing back. Or, you know, a lot of writing teams are pushing back and saying documentation is not the solution for this problem. And the second one is who is a documenter? I think that has also changed.

Zohra 19:22

I think you illustrated some of the challenges that we face and how the thinking itself needs to shift. I like the fact that you narrated this incident about where you had to push back with a solid example and how you approached it with the data backing the need, the why, why you need to shift. But I ask myself, When I how easy is it if, especially if you're a solo writer in a company, even with all the facts available to you, it's very hard to push back. The first line of failure if it is in the product. Now, I do want to call out this that I do look at documentation as part of the product. It is a product that is delivered with a product. The design is something that generally is what technical documentation is trying to solve. And what you said was no, product has to do that lift. Design has to do that lift. But that pushback is hard. As an individual contributor, probably I'm doing what I can to push back and to bring these conversations. And I think with AI now, probably these conversations are easier because if you're able to collect data factor and if you have access to those tools, then you're able to build your ask faster.

Speaker 20:44

Yeah. You know, I remember, and this kind of like very nicely ties into your episode with Sagar, because Sagar used to be my manager at one point, or Frank. There was this one point when the ask he had from me was when I we've got to go and reduce at least 5% of the support tickets that we that are coming in. I was like, okay, great. That's a challenging ask, and a challenge is always welcome. And I spent a whole year actually looking into support tickets and trying to figure out which of those support tickets would allow me to reduce 5% of support tickets, right? By documenting. Trust me, it's an impossible task to do it manually. Even now I can actually remember how tired I felt because every time I would find something that could reduce uh support tickets by writing a document, okay, that would push the needle by 0.5 of a percent. So 5% reduction in support tickets was just not thinkable in those days. But then you know, AI came along and AI is very good at categorizing things. So if your company has uh a support team and they have this data, they they definitely have this data, then feeding This data into AI and saying, hey, categorize this and tell me in the last 90 days which was the one question or the one solution, either ways, that was sent out the most number of times. And AI will figure that out for you. It's very good at doing that. Now suddenly it becomes easier to identify the big ticket items instead of just working on the items that have either the product manager or the customer screaming the loudest about. So in the old world, it used to be the crying child that got the milk, or in this case, got our attention. In this new world, I think we can look at it and say, hey, I want to solve this problem because the most number of customers have the problem, not because there's a particular customer who is screaming the loudest, right? And I'm going to affect the most number of customers. And maybe they've normalized this problem and they're still doing it or they are asking about it, but they aren't screaming about it. So I think in the AI world, it is easier to identify those pieces and then chase those pieces down.

Zohra 23:08

Very true. And I think that's probably my experience too. And there's definitely that shift that is happening. And if it is not, we definitely kind of need to look at that. Because now when that's available at your fingertips, that orientation needs to happen faster for that pushback, as we were talking about. This also kind of ties into the metrics, right? We are looking at in the traditional documentation process, we are looking at which topic we're at the most, where did we get the most? If you have feedback, then what are the pain points? But then if you're the way to address this is not uses one bug, one isolated bug from another, but looking at the overarching problem. Where is that? So even if you don't have access to the support team or that data is not solid, kind of looking at those overarching issues that will rise up, especially with AI, you can surface loan.

Speaker 24:02

That is true.

Zohra 24:03

Yeah.

Speaker 24:03

And uh but it also really depends on the product. I would kind of like caveat that a little bit because there are some products that unless you have access to a whole bunch of hardware and a whole bunch of data, you can't really look at it as this is what my customer is going through. Let me kind of like illustrate that with an example. Let's say you're creating a point of sale. The point of sale, and usually I find that point of sale applications are completely disconnected with the actual user because the person who takes that decision to buy that point of sale software is not the person who's standing at the point of sale and collecting that you know receipt. You know, I was at a supermarket the other day. I wanted to make a payment using a particular payment app. The guy who was checking me out said, you know, he didn't know what to do. So he looked to the lady on the next counter and asked her, Hey, how do I do this? Right? And her answer was very revealing to me. She said, Hit tat twice, press enter three times, down arrow once, a space bar, and enter twice. Okay, that was eye-opening. Because I was like, hey, this person is not worried about what's on the screen. They aren't worried about what error messages or success messages you have shown them. Okay, they are just completing a task. And unless, you know, whoever's designing that software, unless you're standing at that point of sale and you have seven people standing in queue to check out those items, you do not know the pressure that this person is going to go through when they are using your software. It might look very simple to you saying, hey, you know, I've got a drop-down list with all these items, and they've just got to select that item. But what you don't realize is in the supermarket, okay, there are like 1283 items. So your drop-down is now 1283 items long. And it is not easy for this person. It might look easy for you when you were doing it in your nice little lab, but it doesn't work in the real world. I think that is where the disconnect really is. And I'm talking about the person who's designing the software. So that really is the real-time scenario to stand there when you have seven customers waiting for you. So there was uh for one of the organizations I used to work for, we had a point of sale. And when one of our product managers was visiting one of these places, he was just sitting behind the point of sale and watching what was happening. And he saw that these people were just collecting the money and noting something down on a sheet of paper, but they weren't using our point of sale. And at the end of the day, he asked them, hey, why aren't you using the point of sale? So they were like, Oh no, your point of sale is we use it, okay, but we do it in a batch. At the end of the day, we enter everything before we close for the day. But it is too slow for us to be doing it in real time. So somebody has found a workaround for this problem, and it hasn't come to you in your support tickets either. Nobody's complaining about this. But it is a problem, and I can document all I want about how to collect a payment. They don't want that. So it is a design problem. I mean, I can document everything I want, but it's it's a design problem.

Zohra 27:16

It is a design problem, and I would go a little further and say it's also a market research problem. You haven't done the usability on the ground, right? The market research on the ground to really get the user research and collect that data. So that isolation. So what this tells me, Benet, is that the things that happen outside of the realm of AI still need to happen. Yes. Right? Otherwise, AI can do all the documentation you want. It's not going to solve the problem that's on the ground.

Speaker 27:48

Exactly.

Zohra 27:49

Yeah. So I think that traditional way of doing things are still very relevant. And yes, you did.

Speaker 27:58

I completely agree with you on that. Yes.

Zohra 28:00

Right? The scenario that I was talking about in a software world where you're where you have access to a product that has been well researched and you have all the information. I'm talking about probably a more not idealistic process, but more a process that is well defined, that a company that's mature and has things in place, then that's one way of looking at how do you fix it. That's not the only way. As you said, the human in the loop comes back. And because for me, that is very critical. The human in the loop is never going away with as you look at the overall process. Process may be changing, but it's the insights that are coming in still come from the ground, the reality. I have not been in that sort of a business, in that sort of a vertical. So I wouldn't have expected. Of course, in India, when we've done these payments or anywhere wherever we are doing this, there are things where the users on the ground are, they have these workarounds. And that's when it puzzles me to think what was documented? Do they even care about the documentation at that point? And the design becomes so critical. And everything before that.

Speaker 29:05

Exactly. And this reminds me of a very interesting scenario or something that I'd read some time ago. That when Edison came up with electricity, you know, everybody was very excited about electricity. And they all bought into it. All the factories bought into it, right? But we didn't see the benefits of electricity for another 15 years. And the reason we didn't see the benefits of electricity for 15 years is because the factories were still built for steam. And it took 15 years before those factories were redesigned to take the benefits of electricity. The same with computers. Computers came out way back what? Desktops, way back in 85, is when we started seeing desktops in offices and even some homes. But the benefits of IT didn't start to accrue until we hit somewhere in the mid-90s, is when we started actually seeing the benefits of using computers. So the same I would say with AI. AI is a great technology, but I don't think we are set up today to get or to gain benefits from what it does. And to try and even guess what that benefit would be would be futile. One of my favorite questions to uh people when they debate AI with me is you know, I ask them what the biggest benefit of the railways was. The answers are typical, right? I mean, it we move from place to place faster, we can move goods, we can move a lot more goods in one go and all those kinds of things. But to humankind, the biggest benefit that AI gave, I mean, that railways gave us was standard time. The railways couldn't run without a timetable. And until the railway started running on a timetable, every city and every town had its own time. And the biggest benefit that humankind got from the railways was that I know when it's 6 p.m. in Hyderabad, I know what time it is for Zora in her part of the world. Just because we have standard time, and there's a whole bunch of things that we can we can coordinate because we have standard time. Trying to guess what the benefits of AI is an exercise in futility, and I'm not even going to kind of like guess what my children's worlds are going to look like.

Zohra 31:22

Yeah, I think we have all jumped on this AI bandwagon a bit too soon. At least that's what I feel like. And you're right, the fruits take some time to ripen by the time. But right now, I feel like we are at an early stage. And too many companies are overcommitting or overexcited about it. Now, I'm an individual contributor, I'm not a C-level executive, so it's hard for me to say. But I feel, Vene, that there is a disconnect between what an individual contributor thinks and what the leadership thinks. And this is a conversation that I'm running into with my peers. Why is there such a disconnect? And this is not a rhetorical question, actually. With you leading a team and you having that access, can you please throw some light on this?

Speaker 32:11

So let's step into that CXO shoes for a minute, shall we? So she goes to all these conferences where she is being given demos by people saying, Hey, I built this software from scratch over the weekend. It was just me and I built the software. And your CEO is most probably looking at this and saying, Oh wow, this one person sitting in a garage somewhere built this over a weekend. And I have 500 engineers who I'm paying very good cash to, and they don't seem to be able to ship anything unless it gives me, you know, unless I give them six months or eight months. That's a very valid question. I mean, it's a human question. Recently, I had, I don't know if I should say good fortune to see this in action, where at a conference something was demoed and one of the VPs looked at it and said, Hey, we need this in the product. The director of engineering was sitting next to me and they were having this conversation. You know, the VP said, Hey, we need this in the product. And the director of engineering was like, Yeah, I agree, we need this in the product. So he was like, uh, so when can you get this done? The director of engineering said, uh, yeah, it'll take three months, I can get it done. So the VP was like, What do you mean three months? This person just built it like over a weekend. So why do you need three months? And uh, it'll take three months. Uh, there are a lot of pieces in this. So he was like, No, no, no, give it to me in 10 days. So he was like, Okay, fine, let's do it in 10 days. But let me also tell you that there are a bunch of teams we need to interact with, and I will need permissions. So, can you take responsibility for that to smooth the communication between teams? Right. And uh the VP was like, yeah, sure, I'll do that. And then the first clearance they needed was from the legal team. And uh director of engineering gave it to the VP and said, Hey, the legal needs to give us a sign-off on this. And legal took three weeks for the sign-off. Then they needed to interface with two different teams that needed to give them APIs into their pieces of code, and that took another two, two and a half weeks. So by the time this was tested and built at a scalable level, it was three months. Because a product that goes into the market can't be built unless it is scalable. You can't go to the market unless it is scalable, unless it is tested, unless it is certified for a whole bunch of things. Okay, but where did that VP's come from? And I can understand that. That's one aspect of it. The other aspect is there is a first mover advantage, right? I might do an experiment and I might fail, and I am good with that, but I'm thinking about that one experiment that might succeed. And if I don't do that experiment, or if I don't do any of the experiments, okay, I'm not going to find that one experiment that's going to succeed. As a CXO, I have my OKRs just as an individual contributor has their OKRs. Right? What are OK? And one of my OKRs? Objectives. So objectives and key results. So I'm being measured on my objectives. So as a CXO, I have my own objectives that I have to meet, my own goals that I have to meet. And one of those goals definitely at some level is hey, how are you going to save money for a company? How are we going to become more efficient in how we use money? If the question is, okay, shall I reduce my uh workforce so that I can use AI to do more with less? Okay, that is an experiment, right? And I'm ready to pay the price for that experiment. Or, you know, I might say, hey, guess what? I'm going to give all my employees, every one of my employees, $1,500 to use AI. Right? I'm going to give them $1,500 worth of tokens every month. Okay. Now, when you look at it, it doesn't make sense because $1,500, if I had $1,500, that's one headcount in India. Right? So if you're going to give $20,000 people $1,500 each, why don't you just go and hire 10,000 people? The $10,000 people are not going to push the envelope. The $1,500 in the hand of $20,000 people using AI to do their work more efficiently is going to push the envelope. So it requires you to kind of like step out of the world that you can see. It's not easy for a CXO. It's horribly bad for a CXO. Because left, right, and center, almost everybody is saying the same thing. There are companies that are gaining more customers but losing market value. And the only reason they're losing market value is because they don't seem to have an AI story. But their customer count is growing month after month after month. But somebody in the market somewhere has decided that they might be growing now, but they won't be growing in five years because they don't have an AI story. So what's the CXO going to do? The CX CXO is going to go and say, hey, give me an AI story because that's the only way I can prop up my market value. I saw a cartoon recently which is very relevant. This boss walks into the room and tells his employee, we need an AI story. And the employee looks at the boss and says, We're a restaurant. So he says, I don't care. We need an AI story. So the employee quickly writes something on a piece of paper and then turns it around to the boss. It says, DOSI. So instead of dosa, it says dosai, and AI is kind of like a little separate from the DOS. So it's dosai. We have an AI story now, and the boss is happy because everybody needs an AI story. Finally, I will wrap up this answer with an insight that I got when I was talking to a CXO about they just had a round of layoffs and I was talking to him. And he said, You know what, when I looked around the organization and I identified the people who don't understand what AI can do, who are not ready to experiment with AI. They aren't pushing the envelope. Now, those people I don't want in my organization. There is no place for them in my organization. And I completely get that. Because any CXO is going to be looking at their team and saying, hey, that one brilliant idea lies in that team. But it lies with the people who are working with AI, not the people who are working against AI or who are refusing to see what possibilities AI is going to open up for them. So I get where your question is coming from. And I guess the answer is nobody really knows what AI is going to do. But they are every CXO is looking for people who are playing around with AI and pushing that envelope on AI because every CXO believes the answer lies in their team. I am one of those people who could possibly have a solution that will allow you to leverage AI. I hope that answers the question.

Zohra 38:57

It's definitely revealing to me. I do come from a place. I understand, Vene, the challenges that the CXO is dealing with or grappling with. But there is still that disconnect. You brought up a good point that if I'm not thinking creatively about AI or if I'm against it, then I may not be relevant to an organization. I understand that. But there is, again, I'm speaking from an individual contributor perspective. There are many of us that around me that have been laid off who are good, who are amazing, who are creative, and yet they were let go. Nobody knows what AI is going to do. Nobody knows what the future is. But it kind of runs counter to what you talked about. There are peers who are not experimenting with AI, and the CEO doesn't have visibility into that. How do we communicate? I think my question here is how do we bridge that gap? Because good talent is being locked in this whole AI-first rush to experimentation and yeah, I get that question.

Speaker 40:03

And the fact of the matter is that it is very difficult to individually look at people and say, okay, is this person AI ready? Is this person not AI ready? So more often than not, what you will find in organizations is a complete theme or a complete vertical being laid off. There might be a bunch of people who are very good at AI, but they just get lost because they are part of a vertical that the organization at some level has decided can be rolled into yet another vertical or into yet another theme, right? It's just that. I mean, it is not a reflection on the person per se, right? It's just that. And the fact of the matter is we are very good at reinventing ourselves. I mean, you know, from most of your listeners, maybe from outside India. So let me kind of like lay out the scenario that I'm talking about. About 20, 20, 30 telephone boots, manned telephone booths all over India. And uh uh that was a very steady source of income for a lot of people. Having a telephone booth uh was a steady source of income. And then mobile phones came along, and suddenly there was a mobile phone in everybody's hand, and the telephone booth just disappeared. Now, the question really is what happened to all those people who were running the telephone booth? Right? They were they were good business people. They were running their businesses well, they were setting aside money for tomorrow or whatever, right? They all basically evolved, and today many of them are running mobile phone peripheral shops. They give you the back covers for mobile phones and the screen guards and the charging wires and things like that. I know that that's a very simplistic example of uh things, but the fact of the matter is AI at one level is taking away jobs or people are losing jobs. But according to me and to whoever I speak to, that's going to change very soon because the number of companies is going to explode, right? Because what AI allows us to do is it allows us to take an idea from where it is just a thought to a fully fleshed out working prototype, more than a working prototype, in much faster time than we could ever do. So that does not mean that we are going to now build the same amount of software that we used to build, say, five years ago. Instead, I think the number of software that's going to get built is going to explode. And as the number of software explodes, you are going to need people to build those software. And that is going to mean that there's going to be an explosion of jobs at some point or the other. It's just that we are kind of like going through that dip right now where people haven't yet decided what they want to do. So I don't think that this is a permanent situation. I believe that this is very quickly going to change where people start seeing new ideas and experimenting with new ideas. And as those new ideas come to fruition, we are going to get jobs and we're going to get a lot more jobs. Whether they're going to be exciting jobs or not, I don't know. You know, we might end up being delivery boys for food. I don't know. That might be what it allows us to do. But there are going to be a lot more jobs eventually. It's this is something that is temporary. I don't see this going for more than a couple of years.

Zohra 43:20

I love that optimism and the message that the human spirit endures and will overcome. The only thing that I'm seeing, you took me down memory lane with the PCO booths in India, what, 20, 30 years ago, before mobile phones became commonplace. The pace at which AI is changing is faster. And I think the disruption is more stark. And the impact on human lives, which I think is the unfortunate downside that it's happening too fast. And not too many companies are coming with great ideas too fast either. So, but I do see this disruption. And when I say disruption, Disruption, not the CXO disruption definition, the negative impact of a disruption that's happening with the layoff. But then this question comes to my mind.

Speaker 44:09

If I could just stop you, if I could just kind of like interject over here, sorry, but you know, let's go back to Sadar, right? And Xenius is a product that he built with his team in two years. A product like Xenius could never have been built in two years. It would have taken a lot more time than that. You know, simpler products than that have taken a decade to build. So there are going to be people like Sagar who are going to come up with ideas based on their experiences. And they are going to say, hey, it's now easy for me to build it. Let's take a look at it. You know, two years. If you and I, we've set aside money because we want to start some company or we want to build a product, and we know that it's going to take two years versus we know that it's going to take 10 years. Can you imagine the fewer number of entrepreneurs there will be if a product is going to take a decade to build versus if a product is going to take, let's say, a year to build? Right? I just need to set aside money to support me for a year, and then I will have a full-fledged product. So the number of entrepreneurs is going to go up just because it's easier to save up Monday for tomorrow and take the risk today.

Zohra 45:19

Gary. Gare. So yeah.

Speaker 45:21

It's very optimistic.

Zohra 45:22

Yes, I would like to go with that optimism as well. And like you said, I think I was reading somewhere that the gig economy economy is just going to like skyrocket with the avenue that you and people are hustling and people are able to, those who've been laid off, I what I read on LinkedIn, people are thinking creatively. How do I survive? How do I write this out? And they are definitely thinking creatively out of the box. So yeah, there is something to be said about that. I guess what I'm trying to do is invite my listeners to think along those lines that this will not last, the bad times will not last. And to think about if they've had an idea to leverage AI, if they've been against AI. So I think I'm kind of trying to challenge that notion that maybe, maybe it's not another job. Maybe it's something a creative idea that you've always lived with. Maybe it's time to experiment with that. I love your optimism, Vene. I love how this conversation. I appreciate you taking these hard questions. I have not attempted this before, but I don't get to talk to senior leadership. So you kind of were my segue into that. And you gave me a different perspective. You know, that human touch again on how I should probably shift my thinking. It hasn't fully shifted yet, but I think that dialogue needs to happen. And I appreciate that the insights that you've brought to it. Any last thoughts that you would like to touch upon or add to the conversation that we've had?

Speaker 46:48

I would just like to finish off with a lot of people ask me when I what should I do to be ready for tomorrow, right? Or for today, uh, for that matter of fact. And I'm like, there is nothing like being ready. You can be ready for what you can expect. We are in you know, in space that we have never really encountered before. So all you can do is to be open to the ideas that are flowing towards you. Don't be close to those ideas and dive deep because uh expertise is going to be valued. Today, AI can take a picture and uh redo it for you the way Van Gogh would have done it. But then uh, do you value that painting as much as uh if Van Gogh had really done it? So people who can actually create that is going to really have value. So diving deep and not looking at your job as just a way to earn a salary, but uh, you may not get the perfect job. But once you're in there, I think it is very necessary that you dive deep and understand the space in which you are. If you have that attitude, I think you'll survive anywhere. So that is the advice I give anybody who asks me what they should do to prepare for the world that uh we find ourselves on.

Zohra 48:04

Thank you, Benet. This was a fantastic conversation. I've learned so much. I appreciate everything that we've talked about. Thank you again and have a wonderful day. Thank you. Thank you for listening to Insight Techcom. If there's a guest you would love to hear on the show, please let me know. And don't forget to follow and catch every episode on your favorite podcast app. See you next time.