S3E4 Through the Lens of QA and Project Management - Discussion on Why Writers Matter! with Tejasvi Patil

Zohra Mubeena-Mutabanna: 0:04

Hello, listeners. Welcome to Inside Tech Comm with your host Zohra Mutabanna. In Season 3, we shift our focus to shed light on why Technical Communication is a core business asset. In this regard, we will speak with guests who are our stakeholders, such as product managers, marketing professionals, UX designers, QA and customer support, who engage with writers to create a seamless experience for the customer and meet business goals together. Let's get started. On today's show, we have our first international guest for the season, Tejasvi Patil. Tejasvi is a Senior Project Manager based out of India. She comes from a background in QA where she grew through the ranks and eventually switched gears into project management. Tejasvi is a certified scrum maste and she also holds a certification in Scaled Agile Framework, aka SAFe agile. Hi, tejasvi. Welcome to the show.

Tejasvi Patil: 1:09

Hey, it's a pleasure being here. Thank you so much.

Zohra Mubeena-Mutabanna: 1:12

Absolutely. It is my pleasure. Let's get started. So Tejaswi share your background with us,

Tejasvi Patil: 1:19

Hello all and just a quick intro. So myself into IT for past 16 years, I've completed my computer engineering, from Pune PICT and since then, it's been lovely 16 years that I'm here. So most of my experience has been with service based companies. I just worked with one product-based company where I and Zohra were together. So that's my only product-based experience that I have to share. But currently I work in Globant, where I am forthe last five years and really proud about the organization which supports its employees and its value to the employee where you know, the employee is heard of and their their say matters the most. So yes, this is it.

Zohra Mubeena-Mutabanna: 2:02

Can you please share with us what is

Tejasvi Patil: 2:04

PICT is Pune Institute of Computer PICT stand for? Technology. So when I was there, it's one of the topmost colleges for computer fraternity. And I was lucky to get in there. So honestly, speaking, only children who have in their grade 12 score a 300 on 300 are the ones who are there, the rest do not make it there. So I really find myself very lucky that I was there. And it's really proud to share that. I'm an ex-PICTian, for sure.

Zohra Mubeena-Mutabanna: 2:34

Congratulations. And that's an amazing achievement. Congratulations on your success.

Tejasvi Patil: 2:40

Thank you.

Zohra Mubeena-Mutabanna: 2:43

Tejaswi. In this season, my goal has been to sort of understand or rather expose what value technical communicators bring to the business. And listeners, I had put out a post on LinkedIn, inviting anyone that would be interested in being on my show, and Tejasvi came forward. So, Tejasvi, thank you, I appreciate it.

Tejasvi Patil: 3:25

I was really elated, you know, for being chosen to be, you know, interviewed, I would really say thanks to you. But, yes, when you put out that post, and I probably because I have that QA experience with me, I know how much value a technical document adds to the whole product lifecycle or the project whole thing you know, so I would really want to, I wanted to share my thoughts is the primary reason why I'm here.

Zohra Mubeena-Mutabanna: 3:50

That's fantastic. Full disclosure, we worked together, but we probably worked on one minor project, I would say, and that was years ago. So this is my way of sort of getting to know you. In my personal experience, I have always been on teams where I'm I'm receiving information first-hand from my subject matter experts, my SMEs. Now, with you coming on board, I have the opportunity through my podcast to sort of show what companies are doing outside of the United States, you know, beyond the western shores, and what those business models look like and how do technical communicators participate in content creation at companies such as yours. So with that I would like to understand from you Tejaswi at a broad level. I know we did talk about the business model that your company is a service based company, but sort of now getting into the weeds a little bit. Share with us what when your team is developing the solution or the custom solution for a client, what does that look like?

Tejasvi Patil: 4:56

I will share about now that is there the current model to a little later. But let me go back where I have actually worked in organizations where I have benefited because of technical documentation. So in one of my older organizations where we were working on a project, which was for a bank, so it was clearly a cheque scanning process. And so it had two applications where it is expedite in exchange, where a physical check, okay, so we had demo checks, which had MICR code and the numbers. And we had some characters that needed to be scanned. So there was a physical scanner that came from the US. And we had physical checks, okay, demo checks, where we could write amounts, and we could actually scan them. But though, it may look very easy, and you know, as good as a normal card swiping machine, it wasn't that easy. It actually had a supporting technical document with it, which was there because of which we could actually install that device connected to our machines and get it up and running. Okay, so it needed a lot of settings. It was not, like, you know, plug and play. No, it wasn't like that. So after this also there was for this Expedite, there's Expedite for physical check scanning. Okay, so once the checks is check is scanned, and the data goes in how to read this data? And what are we doing with it, we had another document for this, where you had to do a data set of where your data was going to be correctly interpreted. So even in that case, if a cheque was not scanned, rightly, what were the codes we were getting? So the codes were there in the technical document, right? If I didn't know the codes, there was no way to know that it was an incorrect checked or an invalid check. Or the, you know, the dates were also there. So there was some expired checks, you know, then there were checks, which had torn borders or something like that they were not acceptable. All this came in that technical document written write what is okay and what is not. Okay. So I think, because when I, when I joined, that account was already running, and I was a new member in the team. So what they gave me first was read this. So that's one example. There was one more medical medical stream that thing it was Bokhara, where patients reports, okay, there were patients reports, which had to be studied, and we had to deliver, you know, API's written actually, for this patient's data, which was going to be analyzed, and then they were going to set up alarms to these patients. Okay. So it was all about if the report is having some extreme values, right, which are alarming and which need to be, you know, notified to the health. I mean, the probably the patient is okay, but not only this, if the values were even more alarming, okay, there was a medium where a phone call used to go to the person's connected hospital, and the person who's there to take care of him to because the patient is unaware. Okay, that has results have been so out of the borders, and he needs to be getting medical assistance immediately. Okay, so those were also there. So the basis for all this all the information for all this came in a document, okay? Why would I know what's okay? And what's not okay, unless it was all mentioned there. So at least these two examples are the code examples I have to give. Whereas been exclusively used it for my learning or my understanding. I mean, that became the crutch for information when you are actually working. If you talk of now I have a client who's into a lot of products, and like a numerous products, okay, it has got 1000s of products. So each product has a different way to get installed. If it's on a Mac machine, like the different environments we work in, if it's on a Mac, if it's on a Unix machine, if it's on Windows. So all this is documented, okay, so they have so much of technical documentation. So I feel the project is one part of it. And parallely the technical documentation for the current project that I've worked on. But since it's a client thing, I think the entire thing is is taken care by them. But I can share a small this where it's useful for me. So any new member coming into the team, and I have to onboard that person. I share it, onboarding document with him. Okay. So I think the technical document or that onboarding document serves a very good purpose, where it is used and it helps me I feel, you know, day one, when the guy begins his steps from morning, when he comes in the evening, he's done, and in the evening, we'll make sure he pings me a high on the slack, that is a proof that he's done with a setup. Okay. So I feel it's very beneficial. Recently in my organization, I have talked to my design head. And I was just having an insight from her because I saw a post from her on LinkedIn where we have posted specifically for a hiring for a technical writer and I was so curious to know, okay, like, wow, you know, who are we hiring and what is it? So this hiring was, it was in India, but the person had to work in US timezone overlap. It was a medical project that we have, and for that reason, they needed a technical writer. So that was really exciting for me that okay, because since I came in, I didn't see these kind of positions in my company, or maybe I wasn't aware, but since you know, I registered for your session, and since then I started looking around probably it struck me that yes, we do have. So yes, I feel a technical writer needs to be there in project lifecycle. right from day one, I think that really helps. Okay. So even if you're going to start something, okay, let's, let's see, we are building a new application today, for me to have some basis for me to start. Okay. I think we need a document which needs to be in place. Yeah, only then. So I'll give an example of one more e commerce website that I worked for, I can take that name, because I have a preferred long as it's called Snap AB. So it's an IT cum, I mean, it's, it's both it's electrical, and IT devices and everything. So security devices is their major selling thing. So for every product, okay, if you have the product, the product displays a description page. And next, there is a technical documentation page. So imagine their products are so complex, that they have certified people who will install those systems at your place with the technical document. So when we have been testing, I have also read through the technical document, you know, just see, I wouldn't know everything that is correct as a functional part of it is mentioned. But yes, for the language that's put in for the formatting that's there. Those are the kinds of issues I have found and I have shared, or probably sometimes, the document itself is not getting loaded for some products. Okay. So that's one classic example where almost every product has a document tab. And there are a few which will also have a video, like how that product is installed and how it is going ahead. So I tell you, you, you stand everywhere, basically, Zara, your team is up there. I mean, that when I was I didn't remember snappy, but now when we're talking, it just struck me. Like for every product sold on this snappy site, there is a document tab that's there, where you go and see detailed information or the actual the technical information about the device, okay, how it needs to be installed? What is the like, you know, device current capacity that's there? And what know how if there are speakers or there are, I would say, security cameras. Okay, so the security camera? What is the backup rate? How long is it going to play? How much can you read record, this load of information there lot of like, Now, I realize I haven't gone to my detail into it, because they had someone who's gonna test that. So though I have just gone to that tab and make sure that you know, things are getting loaded. It's there, it's there for every product on that site.

Zohra Mubeena-Mutabanna: 12:32

Okay, so awesome. Now, as you were talking about the different the success that you've had with technical content, right. One is the importance of the content itself, right, that it sort of became your onboarding document. Did you have training? Or was this in addition to training?

Tejasvi Patil: 12:52

So there wasn't see there was training for using the application or about the application?

Zohra Mubeena-Mutabanna: 12:59

Okay, so I think my reason for sort of doing a little more deep dive is to show to companies that when you develop content, and if the content is good, it can help you onboard your customers, of course, if you're writing for end users, but also internally, in situations where you have, especially in a service based model where you're onboarding team members offshore. And in those scenarios, if there is no content, I cannot imagine how hard it would be for somebody like the learning the learning curve, or the lost opportunity there, there is that capital cost that you have to take into account. So companies, I believe, need to pay attention to creating content and if the content. So let me ask you this question. Were you always happy with the content that you had? Or did you have challenges also with it?

Tejasvi Patil: 13:52

I would say there were a few challenges, because you know, not all technical documents, maybe you have to have a little induction or a little training to even read through a technical document. It's not all that straight, right? If if you are writing about some XYZ step, and I don't know, what is that, till I haven't finished my basic induction, I think that is as good as awaited for me. So only if I have finished my induction program where I know, parts of the application, it is only then that the technical document will help me. Of course, if you could just hand over that to me and then leave me like that probably, no, I don't think I mean, I haven't come across the situation where I was okay with only having a technical document that I was going and starting. No,

Zohra Mubeena-Mutabanna: 14:38

I think let me clarify what I meant was content can sometimes be ineffective. And my objective in asking you this question specifically is, let's say I give you a manual and if that manual is very well documented, right? It has it's following a certain style. It's well documented, it's formatted well. The language is clear, then, then it helps you with your learning process. So my question was more in the sense, since you have had an opportunity to sort of depend on technical content to to enable your success. Have you had, in your experience? Did you have content that was not good enough, and you had to give up? Nobody likes to sit and go through a manual. And in your situation, you're forced to sit with a manual? And of course, you have an objective there, you have to go through it. But have you had a scenario where you were like, Oh, my God, I just wish this manual was better written. So that it would help me.

Tejasvi Patil: 15:37

I was working part time and I worked for an IoT based company, okay. IoT stands for Internet of Things. Correct. I worked for a startup. And while there, they had a product, which was actually being used on shop floors, so they were injection machines, okay, basically, molding machines, where at every shot, a product is getting produced. Okay. So that count was actually being kept there. But I personally felt we were short of documentation there. So if there was a guy who was actually going and installing this product at the client's place, there was only one master, okay, that guy was the only one. If he was not going to be there. I don't know who was the other supporting guy who was going to take over his task and do it, I actually felt that we lacked the real technical documentation that maybe they now they must be having it. But then I remember that I was feeling you know, why don't we have things written? Would it be not nice? So he will write something on a piece of actually a piece of paper. And he carried with him. So I was like, why don't we have it well documented? And well, this? Okay. So then I think that because it's a startup, I can understand we were here growing and the clients were coming in and huge clients later on. I'm so sure by now, we must be having it. But yes, in the initial days, I could feel the pinch that it's not there.

Zohra Mubeena-Mutabanna: 17:02

I see. So in this scenario, content itself was missing. I mean, but but also, you mentioned that it was a startup, so they had not developed the content. So again, in those circumstances, then you're the knowledge is residing with one person. And if that person leaves, the knowledge leaves with them. So the sooner you start developing that content, the better it is for the company in the long run. Right. Yeah, I think you make a very valid point there. And you also mentioned, KT, and I want to explain to our customers what that means. I know what that means. It's knowledge transfer. Is that right? Yeah. Yes. And it's, it's colloquially used in an Indian context. And I've used it in the past, and I had almost forgotten about it. So you brought back some, some good memories there. All right. I wanted to sort of take a step back in time. You've talked about, I guess, more of your experience in the current, probably in the last few years. I want to go back to the time when you were in QA, and how, if then, content contributed to your day to day? If so how? And what did that partnership with a technical communicator look like?

Tejasvi Patil: 18:16

So honestly, in the entire career path that I had physical content writer apart from you, I haven't, you know, even you, I think just virtually Right, right? So I haven't met someone, we were always at the receiving end of ready, Doc. So there wasn't ever a one on one communication with the technical writer that I ever had the pleasure of, it would have been nice, probably a very nice opportunity to actually interact. But that was not the case. So it was always that something was there and be referred to it. I see. There could be a case where, you know, like you mentioned, did you find something is missing or saying, so I'm not very sure, but probably it just about noting down that little missing thing and informing the team or the manager and that will be taken care of. Apart from that my interaction has been absolutely zero about if you talk about using those documents. Yes. Like I told you, right now, if I go back, I can actually associate to so many accounts or projects that I worked at, yes, I have made use of that, you know, so it's there everywhere. So Right. It's not like, even today, okay, so the account that I work for now, after becoming a program manager that I am for a year, though I may not be, you know, having a role where I'm technically contributing, I do make sure you know, when I take my scrum meetings and my stand ups or I'm talking to my team to ask them if they have everything they need, okay. So when they say it's a yes, that means they have every document that is needed for them for their understanding to start developing something correct. So then they will tell okay, that actually no and the wiki, this document, go and refer this for refer that, you know, this current company that I work for enormous documentation, they can't they can't function without documentation they have to because they have 1000s of products, and 1000s of subscribers to those products and types of subscribers also, okay. So there may be someone who's taken a three month subscription, someone who's taken a six month, so and about also the package that he's subscribed for. So not all features of your packages available for that person. Okay, if he's bought it from you. So that all has to be mentioned in a document, you can't on the fly, decide, okay, you're paying me 100 bucks. I'm giving you only this. No, that's all documented. So well, at the end, you know,

Zohra Mubeena-Mutabanna: 20:30

if you were, you know, sharing these nuggets with me, I'm thinking it's unfortunate, I suppose that you've not had the opportunity to work directly with a technical communicator. And again, I think our interaction was so brief that it almost seems like it didn't happen.

Tejasvi Patil: 20:48

It didn't happen. Right.

Zohra Mubeena-Mutabanna: 20:50

Yeah, exactly. That's what even I'm kind of trying to recollect. But you mentioned that you got you the finished documentation. Now, while you were QAing, right, so far, you've talked about how technical content has helped you with onboarding, or to learn about a product, but as a QA member, did you rely on technical content to create your test scripts? Or, you know, have you had any, any such story to share with us?

Tejasvi Patil: 21:17

Oh, yeah, definitely. So when I tell you about the cheque scanning project, that, Allergen, where we had those two applications, the way the technical document mentioned, okay, the, the proof, I would say, the Okay, and not okay, so have a check when it's being scanned, right? What should be the MICR code length be? What are the ways that it can be like it is not readable? What all ways. So we've also done that, you know, we've scribbled on the MICR code, and we've made sure that has not been reading by the check scanner and all that. So all these things were there in the document, that's where was the base for writing or, you know, forming your test, you know, your test suite also, right, because you think of more ideas later on as a QA, but the first one that comes is from the document, right? So probably, if I have five of them coming from there, I will build another 10, from my end with different combinations and different things that may not be a part of the technical document, because that's just telling you how it works. How it may fail is probably not written there, which I will do as my job. Right. Right. So yes, that has been a basis of forming my test documents and having test suites very much. I've worked for a project called IG, okay. But when I began in that project, it was in a maintenance phase. So once in maintenance phase, all that was to be done was just reading the documentation and making sure it's function that that's all. I mean, that was probably one of the easier ones that I'm telling you, because there was not a new development that was happening. But the way it has to function, because it was a big, big application, I was just making sure that it is working as per the document that is shared with me because I was new, and I had nothing to develop or nothing to write for my own. But yes, that was a basis, right where I could use it.

Zohra Mubeena-Mutabanna: 23:05

Okay. So, you know, through this conversation, I think what I'm trying to what I've probably known, and what you are validating, I suppose, is that content is key to an individual's success, to a team's success, and eventually to a company's success. So the ROI, right, the return on investment is significantly dependent on the type of content a company is creating. So definitely, right. So I want to sort of circle back to sort of bring to light why writers are content creators, right? It's not just writers, content creators are extremely important. And content has been being created at many levels. This particular episode, I think, what I would like to sort of pivot and say is, not only is technical communication important, but content creation, and focus needs to be paid there, right. Because if a good employee leaves, they take that knowledge with them. So you want to make sure that content is being created, and time is invested. And a team's success is dependent on how that content is created. Coming back to your present, I want to ask, you mentioned that you've not worked with a technical communicator. So in the current, I suppose business model, or the workflow that your team follows, do you have any insight into how the information that is being developed by your dev team is being relayed to technical communicators?

Tejasvi Patil: 24:41

I would say, my team, okay, for example, if there's a new app, or there's a new feature that he's developed on a particular app that's already in the market for them, but these people haven't yet put it on production. Okay. So what's expected out of my teams, they also write a wiki page about this, about what all is done I think this is the basis for a technical writer that further goes, right. Because if you are going to actually get your product appended with this new feature, that's, that's been done. And there, you definitely are going to add it as your technical documentation thing, right? I'm so sure that this wiki page that my team members, right when they develop something, and it's a new feature, and when they do write details about it, and that wiki page, it is not only about writing, it is reviewed about everybody on the team, so whoever is in the scrum team, who's in my team, probably 1011 members, then they all will review this document to a completeness, like, ya know, he's covering everything. And I think this must be definitely a basis for some technical writer to go ahead and, you know, take this information and make a document for the right because when he writes it, it's going to be totally with an aspect of selling this product to an end customer, right? When I write it, I'm writing it for my manager to know what I have done, or I when I say I it is my team member who's done it will write for the CEO of the product, who's actually told them what is expected out of the current feature. So definitely the wiki page that is written by my team is used by a technical writer to further make her or his own document.

Zohra Mubeena-Mutabanna: 26:07

Very interesting. I have never been in this scenario where the information is being relayed to me, I have always had that direct access to my subject matter expert, I think I've already mentioned this. But what you are telling me is that I mean, it becomes super critical, in your case for your team to prepare content, that wiki page, to such detail that the technical communicator has all the information they need to go create that because I cannot imagine being able to just write content if I don't have access to my SME. So once you mentioned that your entire team is invested in creating that wiki page, there is a review process in place. So that is sort of the first layer of the technical content being built. Yeah. Now, when that content is written, is it being written by the developers or do you have, like a business analyst, writing this content?

Tejasvi Patil: 27:01

No. So anyone who's developed that module, okay, anyone, so it could be the UI guy who's done some new feature, or it could be the backend guy who's done something, he is going to write his share of that little piece of code, which is functioning end to end and what he's usually doing. So now, probably the UI guy and this guy in the back end of what they have done, and someone who's actually deployed, okay, that must be a third person, all these three, took care of things together. It must be the basis of the actual document that the technical writer is going to actually form, right? Because for him or her, it's a complete cycle, right? It's not about just one little piece there. Right? Right. When I have 10 people working, it is got 10 little things there. But the technical writer has to take all these 10 things together and make sure that it's coming in there. So I'm so unaware of this fact, I wish I really knew but I will, I will. I will go back to my account person there. And I will really ask about how is this? Like any new thing that is done? How is it actually reaching their documentation? Or how is it happening? That is, that would be awesome. Yeah, I will go back. And I'll surely share it with you.

Zohra Mubeena-Mutabanna: 28:08

Absolutely. I would. This is the objective, right? That if you've been working a certain way to think about how is this information getting eventually to the person who's creating that content. And in many situations, there are challenges I've heard. I mean, although I've not been in that situation, where I've not had direct access to an SME, I've had SMEs who've turned me away, they haven't considered my time, or my contribution to be important enough. And I believe eventually, it is the team that suffers, right, because the product fails, and then the support calls increase, and we've had that scenario. But your team is being mindful, at least, of creating that content, and keeping in mind that somebody is going to be consuming this content. So let's be diligent about that process, which is refreshing, and which is really nice to know. So if there are service-based companies such as yours, who may not be creating that content, they should start thinking about, okay, hey, I'm writing, I'm creating this feature for a client or third party, and somebody is going to be consuming this information. So let's be diligent about it.

Tejasvi Patil: 29:10

Yeah, I would really be proud about the fact that whatever work my team delivers, and if there is something that certain I'm the first to review, or honestly, I don't let them share it with the client and decide that I know it all. But I like to, you know, probably the background that I come from, the QA thing, I always go first. So first, I will review it first. And then I tell him share it with the rest of the team or the client actually. So I take ownership on that. And I really like it that way.

Zohra Mubeena-Mutabanna: 29:40

You took it away when you said that you take ownership because just like you're delivering the product, this content is part of that deliverable. That's what I'm sort of arriving to that conclusion that, hey, it's not just product feature that's going out but it's also the deliverable, but content is part of that deliverable. And you taking ownership that is so Oh, awesome. That is fantastic. For me. That's music.

Tejasvi Patil: 30:04

Thank you.

Zohra Mubeena-Mutabanna: 30:05

Yeah, that is absolutely. You know, and again, this is also to sort of, to kind of prompt other individual contributors to think I've developed this feature, let me just not toss it over the wall, let me have some content in there, right? Because somebody is going to be looking at this feature and wondering, what did I do with it, even for the same person who's developed it, they're gonna go back to it two months later, they may not remember what this feature does. And I'm starting to do Doc as Code where I'm actually working in the code to write content. And I have seen the benefit, you know, when the content when it is commented, when the code is commented, and there is detailed information, I'm able to take that information and create my content.

Tejasvi Patil: 30:48

It's such a nice thing.

Zohra Mubeena-Mutabanna: 30:49

Exactly. So you're sort of showing the other side of it. And in your case, it's even more critical, because the technical communicator is not directly there at the table. Now, you may not have the answer to this, and that's okay. I'm still going to ask and you know, if you have any insight, that would be awesome. Do you have any idea what happens if the technical communicator has a question? Let's say the wiki has all the information, but there's some critical information missing, or they don't understand something? Do you know if the writer from your client's team has direct access to your team for information? Do you have any idea about that?

Tejasvi Patil: 31:27

So probably, I feel there must be a team because I honestly don't know how it works. But they don't have direct access to my team members, for sure. So I work for a client, right? I have a client manager. So probably the client manager is see, for every team that I am, we have client managers, I have four teams, and we I have four different client managers there. So one, so any product or any person who's having, you know, the way you said about a question about some XYZ, the technical writer is not finding it. And he needs to know, he is going to contact that client manager that he wouldn't come down to my team. After that, I am so sure that the client manager himself, they are really awesome and brilliant people and so really good. He would know it all. Just in the worst case, he is, as you know, it just about pinging on the Slack channel and asking someone Okay, I see. So I've never had a situation where a document that they prepared was incomplete or something of that kind. Okay. So, I think yeah, so you know, recently, I remember, very, very quick this, you know, this is not happening to technical documentation. This was about a piece of code, which was to be written, because, you know, there were virtual machines, which were being set up for every little test that was being run. But what happens was, nobody bothered to go and clear up that machine and set it to, you know, the base, get it to the base state, okay. So when people keep running it just, you cross and you will reach the maximum memory size, and it all collapses after that, okay. So there was a process which was put on it, okay, that before you actually start using it, this piece of code needs to come in everywhere. So this would become such a big mandate that it was announced everywhere, everyone was told that this is a mandate, you have to put this piece of code before you're using these virtual machines. And you can imagine the fun if someone misses out this what happens, I feel it's about valuing the efforts of someone who stay, you know, put in the efforts of writing certain steps or certain procedures to follow only then the system is well run, right? I feel the technical writers role is equally important, where he knows it all. And he's written it and your job is to follow it. I don't deny to a fact that it may not happen, probably sometimes, you know, a system, I would say, progresses and becomes mature, okay? When that becomes mature, your documentation may not be that important, or may not add that much value. But always remember, by the time it's new to the point that it has become mature. We are such wonderful people where each one of us is replaceable, right? Like day one, I'm here, I may not be there. But we don't need to think how well the product actually matures or your process has matured. What happens in between is always it's important as people move, right? And if the, if the key people move, you are stranded. But if you have your documentation in place, it's just about getting it to the right person there and you know, starting it may take a little time, okay, I'm not saying you have it, you're gonna read it, and you're gonna be all starting. No. But if you don't have it, imagine the plight of the person who's coming in.

Zohra Mubeena-Mutabanna: 34:32

Right, right. I think you exposed a couple of things there. One is that even if the content goes out of date, you have some basis to start with. It is better if the content is iteratively updated as the system matures, because you want your content and your product or your system to work in sync. Because then otherwise, it time is lost. Especially if it's like in your scenario. Your, if you're getting out of date technical content, then your onboarding is not going to be successful, it becomes extremely critical that the content creation is hand in hand with your product development. Now, the thing that I wanted to ask you was, you know, you said, when content, your team creates this wiki page, and you hand it off to your client manager, and everything goes off well, and then you develop a new feature. Now, let's say this feature is an enhancement to an existing feature that you developed, right? In that scenario. And this, let's say, for hypothetical reasons that this is happening after a period of time, has there been a time in probably in this current company, where you now became the consumer of the technical content of the feature that you developed?

Tejasvi Patil: 35:55

So you know, primarily, when the team was formed, it was for an automation effort, okay, they have a lot of tests. So since they have too many products, okay. Like, I believe every month, there is a monthly release that happens of these products. And if there are some enhancements or something, they have to make sure, okay, these multiple changes that are being checked in or not breaking anything that is actually there. So having all these 1000s of products run manually, someone sitting and actually installing them on variety of environments, and getting there and then failing, they had my team primarily to automate all this stuff. Okay, to primarily automate this so that there was a dashboard where it showed you all the tests and how they are running. When this was being automated, okay, there was a framework that was being developed, right, how they are writing it, what all they are doing, and this team of four had to get this document on what all they have done. Okay. So it wasn't, it wasn't an easy job, it was tough. There were a lot of accolades they got on how the performance improved, and how 14-hour test was taking now, just few hours to complete because it was automated. But, you know, like I told you, all four, I think only one girl remain. Three of them, two of them, left global itself. One of them went on maternity leave, you can imagine the plight of everyone who came and replaced them. So when other people have come, their only source, though there was an official KT, that happens, agreed, again,

Zohra Mubeena-Mutabanna: 37:25

KT is knowledge transfer..

Tejasvi Patil: 37:28

There is yes, knowledge transfer, there's so much of information, which only when you start working, comes handy to you, even if whatever I tell you on day one, day two, day three of the knowledge transfer, when you will actually be working on the job, it is what information comes. And if these people had not documented this stuff, so well. And handy for people coming in new to us, it would have been a

Zohra Mubeena-Mutabanna: 37:52

total chaos. I see. So team members that were onboarded. Were these team members only referring to content that your previous team members had developed? Or were they also accessing technical content that was created based on this wiki doc?

Tejasvi Patil: 38:08

I'm really sorry, I wouldn't 100% say I know it, but I see the information that I had was my team prepared a doc and they were referring to that. Now, indirectly, if they've ever contacted the client manager and asked for more information at the end, if he has shared this, this is something I have missed the line. I'm not sure about.

Zohra Mubeena-Mutabanna: 38:28

I see. That's fine. That's fine. But I think again, coming back to the point, content creation, making that part of your process is super important. We're all technical communicators at some level, I suppose.

Tejasvi Patil: 38:40

Of course, of course.

Zohra Mubeena-Mutabanna: 38:40

I think that's what you're showing, right?

Tejasvi Patil: 38:44

Yes.

Zohra Mubeena-Mutabanna: 38:45

And that somebody can actually transition into technical communication, actually. They will become so good at it. Can you imagine?

Tejasvi Patil: 38:50

I know people, I know people who had the love for this, and have actually left their coding jobs and move there.

Zohra Mubeena-Mutabanna: 38:57

So awesome. Hats off. Yeah, I love to hear that. I think we've sort of covered a whole bunch of things, you brought a very, very interesting dimension to this whole conversation, I think, and I really appreciate it. Is there anything that you feel you'd like to add to this conversation?

Tejasvi Patil: 39:16

I would just like, you know, like, you know, right now, in my current organization, since I'm working for a client, okay, I don't have a say about what kind of roles are there and what are they actually looking for? We are reporting to a client and the client is the decision maker. Okay, Globant is not the decision maker.

Zohra Mubeena-Mutabanna: 39:33

Oh, ok.

Tejasvi Patil: 39:34

Yes. But now I think if ever the need be like my new project that I'm going to start off with which is going to be a US client, we just yet forming the team. If time is there, maybe I would suggest or I would advise that you know, are we planning to have someone like this? Can we also start getting someone like this onboarded? That would be my this your take away from this session? Probably you know, I don't want to put a technical writer late in the game. But if you're looking for one, can we get him on? Right? When we are forming a team itself,

Zohra Mubeena-Mutabanna: 40:07

That's awesome. Because I really appreciate the fact that you've, you've seen value in this discussion, and you would like to have a technical communicator, be more actively participating on the team, and allowing for that direct collaboration rather than this information, passing through different channels, but rather, if you had the opportunity to give it firsthand, and it also allows for your team to sort of understand, Okay, we are creating this content, but maybe you may not have had feedback. But that doesn't mean that no feedback doesn't mean that it was good, right? There could be things lost in translation, or because of these, this bureaucratic chain, from what I see, you know, via the client manager. Instead, if you if your team had direct access to technical communicator, or even even exploring that opportunity, what does that look like? Even if you're not able to onboard? Even if having that direct access to the technical communicator? How can that partnership look like? Your takeaway from this discussion, prompting you to, to explore those questions is, is a win-win for me, personally, because this is what I'm interested in for each individual to start thinking about that. How do we engage with every team member? You know, as you're building cross functional teams, you start thinking about, are we having every member represented because you did mention that you have UX on the team? Right, then everybody on your team is creating content, which is great, but then eventually that content is being polished up or enhanced or developed further. And that person also needs to have direct access to your team? I believe that is critically important. I would ask for that if I were in such a situation. So I don't know what the writers on your clients team think about it. But I would definitely be.

Tejasvi Patil: 41:55

So there's one more new team that I began on, I would really ask the architect to know like, is he talking to someone is someone asking him for actually go back and ask him

Zohra Mubeena-Mutabanna: 42:04

Awesome. Yes, that would be fantastic Tejasvi. You know I would love to hear back from you. And thank you so very much for being on my show. And I know it's really late for you. So I appreciate the fact that you signed on this late at night to get on my show. So I appreciate it. And I hope my listeners will appreciate your contribution and your time.

Tejasvi Patil: 42:24

Thank you so much, Zohra. It was such a pleasure talking to you.

Zohra Mubeena-Mutabanna: 42:28

Subscribe to the podcast on your favorite app, such as Apple, Google, or Spotify. For the latest on my show, follow me on LinkedIn, Instagram, or visit us at www dot insight tech comm dot show. Catch you on another episode.