Inside Tech Comm with Zohra Mutabanna

S3E6: Embrace Discomfort and Challenge the Status Quo for Advocacy and Visibility with Swapnil Ogale

June 19, 2022 Zohra Mutabanna Season 3 Episode 6
Inside Tech Comm with Zohra Mutabanna
S3E6: Embrace Discomfort and Challenge the Status Quo for Advocacy and Visibility with Swapnil Ogale
Show Notes Transcript

In this tete-a-tete, Swapnil Ogale shares with us the evolution of technical communication in Australia, especially since the pandemic. Until recently, there was little to no awareness of technical communication at many companies. Swapnil took it upon himself to become the voice of the field, create awareness, and advocate for its adoption and impact on business. 

Some interesting questions that we dove into:

  • What is the technical communication landscape look like in Australia?
  • What is a technical writer advocate?
  • How did Swapnil perform his own tech comm retrospective to elevate his role and make it visible?
  • What is the Amazon narrative, and how can someone use this narrative before starting a  project?
  • What are some strategies to raise the profile of a tech writer at a company and beyond?

These are the links I refer to in the episode: 

If you are looking for openings, Redocly has opportunities. Click here for doc roles.

Guest Bio

Swapnil has over 16 years of technical documentation experience across a range of industries in Australia and globally.
 
He currently works as a Technical Writer in the Solutions Engineering team at AWS Australia. Prior to this, he was a Technical Writer Advocate at Redocly, pursuing his passion for writing, along with advocating for the docs-as-code approach for product content.
 
He initiated the Write the Docs community in Australia in 2016 and has been organizing local meetups and the annual national conference.
 
While he is not traveling, stuck reading any book he can lay his hands on, or trying out new food, he presents at technical meetups and conferences about various things around technical writing. 

Audio Engineer - RJ Basilio

Zohra Mubeena-Mutabanna:

Hello, listeners. Welcome to Inside Tech Comm with your host Zohra Mutabanna. In season three, 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. Hello, listeners. On today's show, I have a very interesting guest all the way from Australia. Swapnil Ogale. Hi, Swapnil. How are you?

Swapnil Ogale:

Hi, Zohra. It's nice to meet you. I'm pretty good. Thank you. Yes. And

Zohra Mubeena-Mutabanna:

I'm excited to meet you too. And you're my first guest from Australia. So I'm really, really excited to be talking to you. And this is the first time I'm also seeing you face to face. So welcome on my show.

Swapnil Ogale:

Oh, thank you very much. And yeah, thanks for the opportunity. It's really nice to connect with you. I've sort of seen your work around on LinkedIn, and I think STC and stuff like that. So yeah, thank you for inviting me.

Zohra Mubeena-Mutabanna:

Thank you. It's my honor. I came across your profile on LinkedIn as well. And I know that you are pretty big on the circuit. You've done a lot of public speaking. And I know we're going to dive into that. But there was one particular podcast you are on, and I listened to you. And I was very, very impressed and intrigued. And I'm like, I have to reach out to Swapnil. So I'm so glad that you accepted my invite to be on the show,

Swapnil Ogale:

Happy to be here. Thank you.

Zohra Mubeena-Mutabanna:

All right. So Swapnil tell us a little about yourself.

Swapnil Ogale:

This question is something that I probably it's been drilled into me for a number of years. So I'm pretty okay with this. Look, I'm a career tech right eyes, I actually studied to be a tech writer. So I know a lot of people come into tech writing from different industries, different backgrounds and experiences, but actually studied to be a tech writer like writings, my like, it's my passion. Like, that's something I really like from the core of my heart. So I finished my master's in Information Systems. This is probably dating myself. But I've been working as a tech writer for over 16 years now in different industries, and you know, across a whole sort of different domains and different kinds of documentation as well. So I've worked with a number of startups recently, I've been contracting for the last few years and freelancing and working on different kinds of documentation. So I started to be a tech writer. And then when I got into it, I just sort of fell in love with it. And I'm still here, like, there's nothing else that I would rather do, I would rather be just documenting, just making sure that people are getting those delightful product experiences through documentation. So that's what brings me into this sort of field.

Zohra Mubeena-Mutabanna:

That's awesome. And it completely resonates with me, you know, how that you intentionally got into this field? So that makes the two of us.

Swapnil Ogale:

Oh, fantastic.

Zohra Mubeena-Mutabanna:

Yes, absolutely. And I'm so thrilled to hear somebody who intentionally got into this field. I got into this field intentionally, eventually. But this is not about me. It's about you. So we are going to focus on that story today. This was one of the you know, like I said, I came across your interview on this particular podcast episode, which I unfortunately forget, but I want to give them the credit. So if you can share that link with me, I will definitely make sure to add that to my show notes. But you talked about this very interesting role that you were in, and I want to dive right into it. Because I think this discussion, my intent, in this season, my goal is to elevate our profession and show the business value that we bring to a business and what you do or rather what you did in that role, I believe sort of lends itself to what I'm trying to do for our profession. And really what we're talking about is you being a tech writer advocate. I have never in my profession heard of anybody having that formal title of a technical writer advocate. Please tell me and my audience what does that role mean? Really?

Swapnil Ogale:

Yeah, that's a really good question. And I believe you're right, like I haven't, like seen or come across a lot of people with that formal title. As much as you know, a lot of other people are doing it as part of their roles. But I believe that when that role came to me, I was, I guess, pretty happy with that, because it actually talks heaps about not only the organization culture, but also about their, you know, the value that they place on documentation. And it kind of happened organically though, when I first started as a tech kind of 15 years back, you know, my sole objective or my this whole, like role was about you know, documenting and keeping, you know, improving the product experiences for customers. But over the years, I sort of learned that it was equally important to advocate for what we do both internally and externally. And look, I've been like a tech right all my life in Australia and there's still a lot of industries here. A lot of organizations that still do not know what a tech writer does, like they, they still, you know, they don't hire a tech writers actively, they don't even sort of think about having a tech writer on the team for their products. And I think I've always been vocal about this at my previous role. So wherever I've worked, I was wild, my official title might have just been a tech writer. But I've always been vocal about you know, how important it is to advocate for what we do and how we do it. And you know, how we think about products, how we think about systems and processes, and how we can improve them. So when this role actually came about, I think I was actually like I said, at Redocly was the first place where I actually got to do it officially, I was their first tech writer advocate, and I had heaps of fun doing that.

Zohra Mubeena-Mutabanna:

I do not have a good understanding of what technical writing is, like, in Australia. What does Technical Communication look like in Australia? Brilliant. And I think you rightfully said that the

Swapnil Ogale:

I think it has changed from what I've seen over the last 20 years, like when I started was a tech writer, I pandemic has changed a lot of things, it has accelerated a lot think a lot of Australia on the global scale, it's pretty small. When it comes to a lot of you know, products and software driven companies, then this is I'm talking 20 years back now things have changed. And we put a lot of startups and we've got a lot of software houses in Australia, and they're actively hire technical writers. And as a matter of fact, in the last couple of years, I've seen an explosion of roles in that particular field. And I'm really happy about that. But it wasn't always so. Like Australia has always been that sort of, you know, service driven industry where people are documenting more, there's a lot of technical writing roles that come up in government or finance or banking in you know, more sort of legislative or regulatory industries. And it's different, like a lot of companies have never worked with like a person who actually does documentation for a living, they're like documentation is probably just like a byproduct, like we do it as you know, something along with what we currently do, like I mean, focus on the role of something. That's the kind of myth that I've been trying to dispel over the last 10 years with, wherever I go, if I'm the first thing. And surprisingly, a lot of industries, a lot of companies that I've worked for in the past have never had a tech product before. So my role was dual in that sense, because I was not only documenting their products, but I was also teaching them about tech writing. And thankfully, I've had a lot of opportunities to do that where I was telling them about, you know, these are different things that you can do with the documentation. And you can you know, different ways of looking at a product, looking at a software process of whatever it might be that I'm documenting, but, and things are changed, like radically changed over the last I think since the pandemic hit, we've seen a number of roles come up where people have actually asked when, okay, can we make you know, how do we go about hiring technical writers? Like where do we find tech writers, I get reached out by people on LinkedIn and other social media asking me about, you know, where I can find good tech writers and what's involved in, you know, creating a job description for a technical writer. And that's, I guess, part of the role of not only being a tech writer, but also advocating for that profession. And things have really changed. And I'm really happy about that. Like, personally, I have, like, you know, seen a lot of changes in Australia. Like, I'm not saying things didn't happen before. But I think it's the landscape has really changed over the last couple of years. of things. And probably other countries are seeing the benefits of it. Hopefully, I know, it's been a dire experience in general for us all. But hopefully something good will come out of it. So technical writing, the way I'm my takeaway is that sort of it's, it's starting to align more with what's happening around the world. It's not just Australia is not just catching up, but pretty much aligned with what's happening. It probably in the in the Western countries where technical communication is an established field. Yeah, that's right. Yeah, I agree with that. Because what I've seen is with with the pandemic, a lot of organizations went totally remote and their teams have now in the last 10 years, a lot of teams are globally dispersed. So they get an opportunity to work with people across the globe. So they they're sort of aware of tech writers and what they do, and they've worked with some of the teams have worked with tech writers before. So they're more than happy to, you know, get them on board. So yeah, things have definitely changed. It's sort of aligning with a lot of what's happening with the pandemic, I guess,

Zohra Mubeena-Mutabanna:

I guess that's a bright spot in a not so good context, unfortunately. But yeah, we have to look at the bright spots as well, the silver lining, as I would call it. So this afternoon, I was interviewing with someone, and they were telling me this was not for my podcast, actually. But this was just a conversation. And this person said that they were talking to a VP at some company, and the VP did not even understand what documentation was. I was telling them about I run this podcast, and I'm trying to advocate for my profession. And this gentleman said, "guess what, there are people out there, especially those who are in leadership roles, who do not even understand what documentation is and why is it even needed?" And I was thinking about interview that was going to happen later. And I'm like, I have to ask you this question. I thought that advocating for my profession would be easy. But if somebody doesn't even know what documentation is, we have to take a step back, several steps back to really evaluate how are we going to position ourselves in a context in a landscape where they don't even know what documentation is? What's your take on that?

Swapnil Ogale:

Yeah, I think that's interesting. Like I said, I've worked in a number of places where I was their first tech writing hire, so they sort of brought me in, because someone else might have told them, you know, we need a tech writer on board to document something. And this was someone who's obviously worked in a technical field before, and they are sort of familiar with the tech writer. But once I went into that organization, there were people in the organization who've never heard of a tech writer, they don't know what a tech writer does. So when it came to the time of, you know, setting my KPIs or goals for a particular six months, or yearly, they had no clue like they didn't know like, how do we evaluate what a tech writer does? Is it like, you know, how many words they write how many pages they deliver, which are sort of you know metrics, but they were clueless, and I think that's where that educating part comes in. If you've worked as a tech writer before you can, you can advocate for what you do, and you know, the way you go about your processes. So while it seems like you know, sometimes tech writers are not writing and it seems, it almost feels like you know, you're not doing your job. But tech writing is more than just writing like, an actual part of my day is not even writing it's more reading. It's more gathering that information, talking to people, making sure I've got the right context, I've got the right audience rather, the right framework to actually document it and writings the easiest part, I would think so. But it's you know, it's just dispelling the myths with with management who have never worked with tech writers before. And making them understand what I've done in the past is I've documented everything like, I've documented my thought process, I've documented what I do day in day out. And when the company co founder, manager sort of reaches out to me and says, "hey, can you tell me you know, what do you do?" Instead of telling them or in presenting them, I actually show them a page that I've written up and say, this is a link, you can read it at your own leisure and tell me if there's something that doesn't resonate with you, and we can work on it. I can tell you how I can add value that way. And so when you document everything, people will immediately start taking notice of it as opposed to any actually presenting. And that's interesting, because right now, I'm like I said before, I'm not at Redocly. anymore. I work with Amazon, where this is a good example, where they have something called as narratives, and it's very public knowledge at Amazon. They use something called a Narrative. So there's no PowerPoint slides for anything like we don't use Powerpoint. Everything we do is a document. So we write everything in a document. So it actually helps us to, you know, clear our thoughts, crystallize our thoughts around what we're actually trying to do. And it doesn't have to be a tech writer, anyone who's working on any software or product or solution, they have to come up with a narrative. And that narrative is a document which you know, allows them to tell, tell people or tell internal or external audiences of what you're actually working on. And when you actually document something, it actually helps you to, you know, track back what you're working on, how would it look like when it's delivered. So it actually sort of formalizes your thoughts much better than presenting. And that's what I've done with senior managers or managers who have never worked with tech writers, I've documented everything said. Alright, here's a link, go and check it out. Tell me what do you think and if, if you disagree, we can work on it together. But once it's in there in front of them in some sort of a document, they actually begin to see the value that they begin to realize the value of the written word, if I may use it. But when they see that they actually start believing that okay, now I know what you do, I can actually use this to, you know, talk to you, it becomes like that initial part of that dialogue, Lots of thoughts going through my mind. You've given me a lot of information, very interesting facets of your contribution in terms of advocating. But I'm going to sort of try and tease those details apart so that I can process them. One of the things that you said was, when you got hired at a company where there was no awareness about the field, you would start documenting. But before I sort of go ahead with that question, I think you stole my thoughts, as you were saying, We do very little writing and everything else that you said. So it it completely resonates with me. And I do sometimes go on that guilt trip, and I haven't written a word a day. Right? So let's get that out of the way I had to I had to acknowledge that. So we're in the same boat. Now coming back to the adding value, the document that you said, you create, you write in that do you write, like what you did day to day or at a high level, in terms of what value do you bring to the business? I'm very curious about what did you put into that document that got them hooked? Because generally when you give people content they don't want to read. So what was it in your little write up that they wanted to read and you advocated for us? I really want to know that. Sure. I'll give you a couple of examples. Actually, when I say that document everything, I mean, I literally document everything, like my process of how I work through a project. So that sort of gives me an understanding of how much time it takes me to, you know, work on a project. So it becomes my own baseline for metrics in the future. But when I'm actually presenting, so at the end of every project, no one's asked me for this. But what I like to do is I like to do like my own technical writing retrospective. And I've done this in a couple of places to interesting of effects. Because I said to my manager, look, we finished this project, we've delivered documentation, the products out there, people are loving it, or whatever it might be. But from a tech writer's perspective, this is how the whole process looked like. So I'll point out the flaws in what I thought was what didn't work for me as a tech writer. So people were not forthcoming with information. Sometimes they did random decisions that affected my productivity, and deliverables. And in the larger scheme of things it might look like we did manage to deliver in product as a documentation. But it wasn't straightforward. Sometimes it was, there were bottlenecks. They were, you know, people were not forthcoming. The information was haphazard. And sometimes I found out stuff in the software, myself, and I was testing it out, I said, Look, how come none of your testers or developers have picked this out. And I'll put this in a report like some sort of a retrospective report for my manager, not only the project manager, but also my manager, and the manager about them. So what that gives them is that they get an overview of this is how projects work sometimes, you know, from one person's perspective, and I'm just again, this is my own assessment of the project, maybe I'm wrong, maybe it didn't look like that for the project manager, but as a tech, right, and that allows me to do is come up with every six months, when we have a project delivered, I can show them okay, this is the project I worked on, I pointed out the flaws, I've said, these are some improvements we could do and it I think it will definitely improve the next time we use the use the same sort of delivering a similar product, these are things that can definitely help us and also help the documentation person and also the project manager because they'll have to work less. And if they know what we want, they can streamline their own resources so that I get the information faster, we get it out delivered quicker. So I put some figures against it in terms of and I think it could have been improved by at least 15%. But if we did it that way. And then at the end, I gave them a summary of you know, what I felt during like my personal feelings of what I felt during the project. Sometimes I thought, you know, the change managers were being unrealistic. The trainers were, you know, on my back was that time because they needed to get that; use my documentation into their training material. But it all sort of was that bottleneck where I didn't get that information, so I couldn't go and help them out. So the picture that I want to paint for my managers and senior managers is it wasn't as much of a collaborative effort as you would think they were like people doing their stuff delivering in short gaps. But there are these things that we could, we could easily improve next time and then actually use that. I was surprised that the senior manager, one of the managers said, "look, I don't work with you directly, but I read your report. And I thought that was fantastic. Because no one actually comes up to me and tells us this is how that project, particularly went. So thank you for sharing that. And hopefully we can use some of those improvements next time we do that project."

Zohra Mubeena-Mutabanna:

Fascinating. Absolutely fascinating. I haven't done this in my career for almost 18 years. And I think where you are taking charge to, uh, you know, to really show how you can improve not just your life, but the life of all the other stakeholders. What I want to ask is, do you have a template? Because it seems like you've been doing this for a while? Do you have a template to share? Because I would love to share something like this in my show notes so that others can use this and apply and tweak it? Would you be willing to? Yeah, I can I can find one for you. I think this is going back a few years, but I'm pretty sure I can find something for you. It usually is in form of an email, or maybe just a conference page or some sort of a wiki internally that I've just written up and pointed out to my manager saying, look, this is what these are. My thoughts are retrospective of my personal feelings on this particular project. And I'm happy to share a template if I can find one, definitely. Sure, or even if you can't find a template or just some prompts that helped you gear your report. If I'm doing this for the first time, what would you advise since you've done this, and it has helped you and the other stakeholders? I think there's a great value in this Swapnil. I really think it would empower tech writers especially those who are lone writers at companies where they are not seen or they don't have a process. If they're not working in Agile processes where they don't have retrospectives. I love the whole idea about a tech writing retrospective., Because if you're a lone writer, you want to take that time to introspect and see how you've brought value where were the roadblocks, how did you get over those roadblocks. And like you said, there could be areas for improvement for the product, because eventually we are all working on a product and deliver that experience. Right, seamlessly. So I'm, I'm really excited about what that would look like. And because I haven't done it, it's something very novel to me. I mean, now I can see why, how, you know, you ended up probably getting steered in that direction of becoming an advocate. We've talked about you being an advocate, and you've done these different things. But what got you that formal title? I think I didn't ask you that. Probably I did. And we veered away from that conversation. But I want to come back to it. And have you share with us what brought you there?

Swapnil Ogale:

Yeah, big shout out to, to where this has got me into. But like I said, I've been tech writing. But over the last few years, Write the Docs. It's been a large part of my life, right, the docs community and I actually sort of bought the Write the Docs community down to Australia in 2016. So I started the meetups in the conferences. So I still do that regularly, I sort of run the meetups and organize annual conference. So I think that's where that advocacy part comes in is because I felt there was a need for that in the Australian market. Like we had a couple of organizations, we've got a couple of organizations here that were trying to do the same thing. But I still felt something was lacking. I was part of those organizations and like technical writing communities and societies, but I still felt you know, we were lacking that global perspective. In some cases where it still feels like very Australia specific. So I thought maybe you know, the Write the Docs community is a good way to bring the global perspective at the same time. Bring Australia out on a global map as well. And I, I feel over the last few years, we've done that in like a number of people have helped me along this, you know, the whole journey. But we've got a number, we've done over 50 or 60 events over the last five years, we've done three conferences in Australia, we've got this annual conference coming up again this year. So what I'm trying to say is that was that advocacy part, in addition to my core technical writing roles, and then when you sort of blend them together, it sort of becomes natural that I am happy to represent technical writing community. And when Adam, who's the founder of Redocly, co-founder of Redocly, and he sort of advertised this role, he reached out to me and I said, he said we want to, you know, talk about this role, you got to take writing advocate role, what we're trying to do is essentially, get someone in who can talk about technical writing within the organization like things like, you know, how do you go about doing different technical writing things like setting up documentation pages, looking at the information architecture, but also talking about technical writing, and how we do it at Redocly out to the wider community. Could be the open source community. Could be just globally: talking at conferences and meetups and other parallel events. Like it doesn't always have to be documentation. It could be an API conference where you go and talk to people about good documentation practices we follow at Redocly. And when he reached out to me, I thought this was a good way to you know, explore those opportunities, where it's it's an official title, where actually go and get to talk to people about documentation in an official capacity.

Zohra Mubeena-Mutabanna:

Interesting. First, tell me what is Redocly? I think that might help me dive a little more deeper.

Swapnil Ogale:

Sure. Redocly is the leader in API documentation and design products. So end of the day, what we do is at Redocly was what we used to do was create documentation out of your API specification. So people who actually like developers, when they write the API's, they need robust documentation to go along with it. So Redocly allows them to transfer that knowledge from those API's into document good documentation. So could be just, you know, reference documentation around API's could be a building a whole developer portal around that those API's and API products. So Redocly allows them, gives them the power to actually do this through the open API specifications and whatever other formats that they use.

Zohra Mubeena-Mutabanna:

So when Adam approached you with that formal role, do you have any idea what gap was he trying to fill there? Because no company, I think, in my experience, has hired somebody to go advocate for that role. So this is again, a very interesting perspective. And I'm curious, what gap was Adam probably trying to fill or what was your takeaway from that opportunity?

Swapnil Ogale:

Yes, I think what we were trying to do there was not only have someone in come in, do the documentation for the actual product that we created, but also get that ability to influence that documentation decisions a lot more faster. Like, when I spoke at conferences, I could tell people about, you know, these are things that we've tried to trade off here. And they work really well, from a documentation perspective. So we needed someone who had that understanding of how documentation works, and how it fits into, you know, your API products, but they're easily transferable to other things that you might be working on. So that role was fitting in that it was a hybrid role of, you know, documenting the actual product itself. But then once you got that understanding, you could actually go and talk to it about people outside about, these are things that we tried, it could be, you know, things in, we tried, we did quite a few things within the documentation. So when I started off, there was already some documentation that existed, but we bought in a lot more structure to it, we revamped the information architecture, we built in landing pages towards the documentation, we we sort of enhanced the search the navigation, there was adding all those peripheral experiences for documentation. And once we had tested it out perfectly for our own documentation site, we could then go and, you know, do that for our customers. So when Redocly was signing new customers on, we could tell them this is what's possible with your Redocly package. So when you use Redocly to create your own API, documentation, references, or even a developer portal, this is how we do it. We could show you this is what we've done. And you could do the same thing, or even go and build on that those experiences and create your own fantastic developer portraits.

Zohra Mubeena-Mutabanna:

That's fantastic. That's really good. I mean, it's brilliant. So did you also have to advocate within the company, or was it mostly outside,

Swapnil Ogale:

it was both of it. Like, we had a lot of developers who were sort of you know, who never would never worked with a tech writer. So we were showing them, this is what we can do within documentation. So this is how to actually write, like, when when I started off, it was me and another tech writer, we were doing the documentation. But by the end of it over the next 12 months, we actually had developers writing release notes for us, we had developers contributing to initial drafts of our documentation. So setting up those expectations of what tech writers do, and you know, the kinds of processes they follow. And the templates. Like when we set up templates for them of you know, this is how a documentation looks like, a particular topic looks like. They could then start providing those initial drafts, which made the whole more processing and because again, it's one of those classical scenarios where there's always more developers than writers in an organization. And that ratio always grew. So at one point, we had, like 25 developers and two tech writers. So we had to make sure we were getting enough information to make sure that the product was actually very documented as well. So it was advocating internally and then had the opportunity to actually demo Redocly to a few potential customers, tech writers who had reached out to me from other organizations saying we were trying to, you know, test out Redocly for our needs, can you help us with understanding what the product does? And then how do you actually go about using it for from a technical writing perspective. So that was a great opportunity, because I could show them what Redocly does, but also how I write documentation. And this is where that initial question came in. Because I'd already done it for my own documentation within Redocly, I could show them. Yep, this is how you set up a navigation, you can set up, you know, you can create landing pages and markdown files in such a way that you know, that this is how it looks like on a developer portal, we could show them our own stuff that was also advocating externally for this is what's possible. If you think there's anything that's missing, let us know. And we can maybe, you know, put in a feature request, and we can get that delivered for you. And we actually did that over a couple over the last 12 months. We had a number of tech writers who had provided us some specific feedback on you know, what's possible on a particular page? Can we do this? And we managed to deliver it.

Zohra Mubeena-Mutabanna:

Okay. I mean, kudos to you. That's awesome. Very rarely do I get to hear where technical writers are on the business side, trying to advocate about their profession, and also about the product itself. Because through that discussion you're trying to show this is the value that we bring to the product and to the customer or the user experience. So applause. Big applause to you, Swapnil. What I'm taking away from everything you just said was that, in a way you were trying to advocate for the product, but through that really trying to advocate for the profession itself? Would that be right?

Swapnil Ogale:

Yeah, that's right. I mean, that specific case with Redocly, because the product catered for a specific audience, which was developers who are using, you know, creating the API's, but also technical writers who would eventually go on to build the reference documentation. You know, add in more concepts or contexts around API endpoints and build a developer portal on top of that. So it was in a way advocating for the product because it catered to that audience, but also because it was a documentation product. It was easy enough to you know, go and talk to the community and tell them about this is what we've done personally, without developer portal, if you want, I can show you how I do that. And then you can build on that. So it was also, if I stepped back into their shoes, it was, you know, if I was looking at a product from a tech writing perspective, I want to talk to someone who's already done this, who is already a tech writer, and has used this so I can actually then build on it, it sort of reassures me that you know, people actually know what they're talking about. So it actually allowed me to go and talk to potential customers and not sell them, but actually tell them how we actually do something and read only from the product perspective, but also from a documentation perspective. And that helped them you know, make those hiring those buying decisions.

Zohra Mubeena-Mutabanna:

The one thing that you said about trying to sort of channel the profession through the product that you're advocating for. It's interesting, because I have been in situations where prospective customers have approached the leadership and asked for what is your documentation look like? The way I'm taking this away is your product is not separate from your documentation. And your product is not it's a deliverable. It's all a package. And right, as much as we are trying to elevate our profession, I think we are also trying to market our product, our profession as well. So the fact that you had this opportunity at Redocly is, is I think, pretty unique. We don't get that kind of an opportunity. So let's see if I'm working for a company where I don't have this opportunity. But we are in some way or another contributing to that customer experience. What would you like to recommend? How would you apply what you do day to day to that larger vision? And how can we elevate our profession?

Swapnil Ogale:

I've been in situations, like you said, pointed out, it's it's not my official title, it's not even an expectation that I would be doing that. So they've hired me only purely for tech writing. But I think the more experience you get the the more you can actually contribute to the product lifecycle and development. And one of the things I've learned is, Do not be afraid to disagree or debate or dispel common product thoughts like people come in with sometimes. People come in with wearing a one-lens view of looking at a product. But when you actually talk to them about, you know, I've worked as a tech writer for a number of industries, and I can easily show them that, you know, we've done things in the past that have actually improved the whole product experience, I'm not just talking about documentation. And we actually have a good sort of a robust discussion with them. They actually happen to understand and learn and see if they can apply it to their own products as well. So do not be afraid to disagree. So that's one thing I've strongly learned over the last few years, and I've put my hand up for things that outside my comfort zone. So I think a few years back, I very distinctly remember this example because it was not a part of what I was actually there for. So they were creating this, the development team was creating this little application or tool using Excel. So it was a very sort of a internal tool just for finding out data or something. And they said, Look, can you write some documentation around it? I said, Yeah, sure, I can do that I can write like, you know, easily write an internal wiki. But how about we actually try something unique here, because it's a very specific MS Excel tool? What if I can, you know, play around with the VBA macros and see if I can actually build that help within the product, the tool itself. So when you actually click in the tool on a specific, the Help icon or something, it'll just display what you need within the product. So you don't actually have to point out to point people out to a separate link or hosted somewhere else that documentation or deliver them to PDFs or whatever. So let's try something else. So and it works so fine. They said, Look, can we do it for all of our other tools as well? Because it's so easy. It was just, you know, making sure you knew enough. So I worked with a developer and said. Look, this is a macro I'm trying to run in, you know, and this is I'm like I said, taking again, myself again, but Microsoft Excel, putting in an application in Microsoft Excel is like before 2010 or whatever, it doesn't happen anymore. But I said, look, let's try it out. There's no harm, like I can write the same content in a Word document and easily publish it. But let's try something different, you know, see if we can make a unique experience. And it's only internal people not gonna hate it for us. But if anything, they'll actually provide more insight of you know, what they think about the help, and it actually worked like people were have really happy with the tool and the quick help that they got out of it, like embedded within the product itself. So yeah, put your hand up, I put my hand up for things like outside my comfort zone. And if you learn enough coding or help out, you know, with testing the product, and people will actually get to see what you bring to the table as a tech writer. And that's where that strong point is. It's not only just about writing, it's, we're trying to do the same thing. We're trying to improve the product experience, so a different angle. So work with us, and we'll show you how you know what we've done and how our processes sort of aligned. They might look slightly different to yours. But at the end of the day, it's all we're trying It was the same thing trying to improve the product experience for customers could be internal could be external, but different things that we bring to the table, different skills, different experiences. Yeah, different knowledge.

Zohra Mubeena-Mutabanna:

As I'm taking my notes, you said three things that I think are at least I have in my notes, do not be afraid to disagree. Yep, go outside of your comfort zone, and look for opportunities to innovate. And I think the document that we talked about at the beginning, I just want to sort of tie this all up for my own benefit actually, is the document that retrospective that report that you're creating for yourself really gives you this opportunity to reflect on all these things. It allows you to identify if there are any gaps, where you can lend value. If you're not a technical person, there are other ways you can learn value. For example, you know, where you end up testing the product, where you can improve efficiencies, probably right, sort of that retrospective allows you to examine and offer that input. So taking control becoming proactive, is such a brilliant suggestion. We all think about, okay, I can be proactive, but this is like you're nailing it, sit down with your thoughts, write what you did. And that will allow you to identify where the gaps are and where you can lend your value. Yep. And then sharing that with your leadership allows the leadership to see okay, this person is not only writing, but doing a lot more things, there are these touch points that are not even obvious. And you're trying to make those visible. Yep. So I definitely need that templates pop. Now that's what I'm saying.

Swapnil Ogale:

All right, let's get you that template.

Zohra Mubeena-Mutabanna:

If your company does not have retrospective, and you're not, you know, in an Agile process, then this actually is a great opportunity to do that self reflection, to sit down and write your notes. One thing that you also mentioned was that that report that you write, and you share with the leadership team, it allows them to sort of recognize where you can lend value. And that probably helped to bridge the communication gap, because that was my one of my questions. So did they come back to you with questions? And did that allow for a dialogue there?

Swapnil Ogale:

Yeah, it did. And like I said, Not everything's positive all the time. Like when I actually send out that email, I did put in some very strong feelings about some individuals working on a project that I strongly disagreed with. And I had like a good discussion with my manager, I said, look, let's come into a room, let me talk to you about, you know, the context behind why that happened. of you know, we had like, I went through some bad experiences on that particular project. And I clearly listed it out in an email, I said, Look, that's what I've got, I've got a, I've got the power of the written word. So everything that I'm feeling, I'm going to put it in an email, I'll send it to you, if you want to have a discussion, happy to talk more and tell you more stuff about it. And my manager said, Yes, let's do that. I'll tell you what, you know, what happened? Why did we, you know, have those individuals and the product and how they influenced the deliverables and stuff like that. And that was good, because that gave me a good understanding, you know, some of something completely not related to tech writing, or how projects get structured, or how resources or individuals get put onto a project. And I'm like, and that's fine. That's your prerogative, as a manager, you get to choose, you know, who you will, like, who works on the project. And all I'm telling you is this is one person's view of the project. And I felt if we had other people, it would have been a lot more better experience. And I'm pretty sure with that particular couple of individuals, if a lot of people felt the same way. So someone had to come up, and you know, tell our managers that it didn't work, like maybe next time, hire better people. And that's, again, the hiring is not my decision, it's your decision, you get to choose. But if you need a better experience next time, maybe try something different. And like I said, completely not related to tech writing. But that retrospective opened up that dialogue between me and my manager. And that wouldn't have been possible if I hadn't put my thoughts down in a very structured way. So that email that I send out in each end of every project, and at the end of every year is where like, I have the year end email as well, that I send out to my managers of this is what I achieved during the year, personally, and also within the projects I've contributed to this project in some fashion. In that other project, I helped out a tester, you know, test out something when he was when he didn't have the time. With this particular project. I wasn't even involved doing it, you know, end user documentation, but actually helped improve the UI text in some fashion. Like I actually made it a lot more simpler and maybe, you know, put in a little bit more effort into designing like, again, ticketing is not just about writing. At Redocly, when we were looking at our documentation, I actually drew up diagrams on a notebook and I said this is how I feel the landing pages should look like should actually look like. We then turn it over to our designer, graphic designer who actually created fantastic landing pages out of time and I like that's the thing. It's not only just about writing, when you actually look at documentation as a product, we actually get to play with different components of it. It's not only about just, you know, being able to write a how-to topic, or a procedure, or process or whatever, it's actually, you know, looking at those peripheral experiences and actually contributing to that, and, and that's that value that tech writer brings. And we need to really market for that when we are any organization, when we have, you know, get an opportunity at every opportunity to actually I wouldn't say, get an opportunity, at every opportunity. Make sure you're marketing yourself in a fashion that actually speaks about the value you bring as a tech writer. It's not only just words on a page, it's more than that.

Zohra Mubeena-Mutabanna:

You said documentation as a product, I have never heard that. That's such an interesting perspective. So that totally shifts, you know, your perspective when you start looking at documentation as a product experience. So when you approached your manager, and you had your thoughts in there, wouldn't you say that some of the observations that you had were subjective? And if you think they were, there may not be managers who are open to receiving that sort of feedback? What would you advise in that situation?

Swapnil Ogale:

Yeah, I'm glad you asked that, because, like I said, that template of, you know, sending a report at the end of every project. Remember how I said, I actually use it also use it as a baseline for my metrics. So once I've known what has worked for me in a previous project of the same complexity, or same, you know, magnitude actually use those numbers effectively. So if someone disagrees with me and says, look, that's just your opinion of how documentation should look like or how many days? So, again, a hypothetical. So once a manager said to me, I don't agree with what you've said. You're going to need 15 days to actually write that particular user guide. Can you show me how like, again, this is a hypothetical, but show me how like, why are you saying 15 days, I think it should only be done in eight days. And I'm like, Okay, I'll give you an example. We've worked on a similar project, before, we've done the same amount of documentation, from experience looking at the whole project, it might look like it was only eight days, you know, for you. But these are the steps that I did this is the amount of effort, it took me to write every whatever section of that particular user guide. And when I actually calculated it on a similar, you know, the similar magnitude of a project, it actually was closer to 13 days. So with a buffer, I'm saying it's 15 days, I could get it down to 12, if we have all the resources streamlined, but I've got the numbers to back me up. And that's what the whole thing is, yes, you might disagree. But I'll show you what I've done before, how much it actually took me and then we can build on that maybe you're saying, you know, it's only half the effort. And that's fine. I'm not saying I can't get it done in 10 days, but then the quality will be affected. And if you want to put out documentation that way, that's your decision. But I'm telling you, this is 15 days, I can get it done in 13, which I have done in the last time it maybe with more resources, I can even get it done in 10. But I'm not gonna lie to you and say it's going to be done in eight days.

Zohra Mubeena-Mutabanna:

How awesome is that? Swapnil, you are building a case for yourself, you're really backing yourself up with data. And we all in our roles, use tools to track our time. But these details are lost. Yep. And one, I think thanks for shedding light on what that that subjectivity is sort of not really subjective, but more of an objective approach here, because you're putting numbers to this. Yep. Is that right? So it's not about oh, this person just didn't work. But we are, it's not about finger pointing, or it's not a blame game. But it's more about the roadblocks that we end up facing. So in terms of sizing, if you are in a position as a writer, where you don't have that opportunity to where you're having this pushback, and I've had this pushback, too, it's just not it's just words on a page, how long does it take to write and I think you make a great case for it. Where if you have this baseline, and if the team culture does not lend itself, in your favor, tracking that in this narrative that you're creating, for yourself, would really lend itself as a valuable artifact. At a later point. I'm loving it. I'm loving it. I've never had this sort of, you know, a very productive discussion. So this is sort of teaching myself you know what I can do? I'm very fortunate to work in a company where we are given the time and the bandwidth. But there are many writers who are struggling out there. And hopefully, this allows them to pause and to think, what can you do to identify the gaps and then you always want to improve? And this is one way to improve that communication, so to speak.

Swapnil Ogale:

Yep. Yeah, I think visibility is key. At the end of the day, we've got to, like I said, it's a very niche field. So visibility is really the key. Like anything that every opportunity that you get to, you know, project what you've done in a productive fashion in terms of you know, it's not only about documentation, these are the things that we bring into play when you hire a tech writer, or, you know, as a sole tech writer, it's not only about just sitting in a room and just, you know, typing out words, it is, these are the things we also worry about. These are things we care about as documentarians. So I think that's that bringing out that bringing out that visibility is really the key.

Zohra Mubeena-Mutabanna:

I love that we care about what we care about, and where we can contribute and how we can contribute. Beautifully said, you talked about this narrative that you have at Amazon, would you share something about that? What that looks like? And I think you mentioned that it also sort of lends itself to the advocacy that we're talking about.

Swapnil Ogale:

It's a very well known thing at Amazon to actually write a narrative. So at the start of every project, they start working backwards from the customer viewpoints. And the narrative is actually a document, it's a six page document of actually listing out the whole idea before you even build it. So it's that you know, that narrative actually talks about an overview of a product or solution or process. And then it actually steps through you through the implementation maybe and some potential questions that might come out of it. So it's a very well known fact, I'll see if I can find any public resources around that I'm pretty sure there are some public resources of how things are done at Amazon, I'm pretty new here. But I'm sure there's some public resources that I can share. But that, like I said, writing something is very different to actually, you know, talking about and that's something that's very spoken about at Amazon. And again, this is public knowledge, but it's not about how you present like to sell an idea. It's about actually how you write and can you actually write it down in a fashion that it actually, you know, have you even thought about it deeply enough, have you, you know, carefully considered everything. And it's not just about a product, it could be any idea, really, but as long as you've written it down, it actually helps you crystallize your thoughts and writings. Really the key word here, it's a very powerful tool to be able to put all those thoughts together on a piece of paper.

Zohra Mubeena-Mutabanna:

Yeah, I would be interested in it. So thank you, I think it's a great exercise, I believe, to sort of, before you go and build a product to really think from a customer perspective and then work. It's almost like reverse engineering without really reverse engineering.

Swapnil Ogale:

Yeah, yeah, absolutely.

Zohra Mubeena-Mutabanna:

We've touched on a lot of good questions here. And, you know, you've shared some great feedback with us. The other question that I had was, I think you and I had talked about it, maybe touched upon it, how would you differentiate a tech writer advocate role with a dev advocate role? And I know this is just randomly being asked, but again, I've not seen a dev advocate role, either. But have you seen that? And what is the difference? In your opinion? And why is it important to differentiate between the two?

Swapnil Ogale:

Yep. I think there's a terrific big community of people who who are developer advocates. And what they do essentially is the same thing, they actually advocate for developer functions or developer processes and how they're working on things and bring out what developers are creating end of the day, look at the value. So tech writer advocate, in that fashion, when I look at it as a differentiation viewpoint is the value that technical writers are bringing into the whole whole process or the whole product itself. So slightly different audiences. So technical writers have a very different way of thinking, developers have a very, you know, logic-driven things of you know, this is a problem. We take writing, it's not obviously sometimes that straightforward, like you have a problem. But the solutions, like the answer is not straightforward. A or B, it's sort of how we're going around, finding out stuff, making sure it actually fits different, at least addresses 80% of the audiences. So making sure we've got that context properly. So that tech writing advocating role is then becomes your differentiation factor is that you're writing first, like you're you actually advocating for a slightly different discipline. There are a lot of similarities too like, with, like, a lot of developer advocates, will this do the same thing, you know, go and talk at conferences about developer experiences, developer processes, tech writer advocate, like I said, that was probably fortunate enough to be like one of the first tech writer advocates ever. But when I spoke at conferences, it was very much from a documentation perspective, like very heavily documentation. But the conferences that I spoke at last year, they were not necessarily all like, you know, technical writing conferences, there was a couple that I spoke about, were very API driven. So mine was the only documentation related talk in the whole conference of over 60 talks. So good experience, because I could actually talk to people who have never worked with tech writers before or not as much as I would like to. So that role gave me an opportunity to go and advocate for documentation perspective and to developer conference. So how good is that?

Zohra Mubeena-Mutabanna:

How good is that? And I think I get it now that you've shared what the difference is like. I have been at events where there are dev advocates, I just didn't know that. Or at least I didn't think of it in that manner. So it's again, thinking of it in this context of advocacy. That's brilliant that, you know, there are things that align and things that do not align. But what you said about it's not a straightforward path. And what you're doing is sort of formalizing this role, which is, I think more companies should pay attention to this, especially companies that have a tech writing department or a documentation department to sort of, and if they see the value, they should advocate, they should support their writers to go advocate. I was fortunate, again, at a company where I got that opportunity to advocate, we were improving the help experience. If you find an opportunity, please do make yourself visible and talk about what you do and the value that you bring. I think the value add component is super important. Would you agree?

Swapnil Ogale:

Yeah, absolutely. It's just, you know, looking beyond just writing, like I said, it's just while the role itself. And sometimes that gets a bit tricky, like people hiring for tech writer thinking that the role is about writing, but it's not about writing, it's a lot of research, there's a lot of you know thinking about different audiences and who you're writing for. So it's like, it's not a straightforward thing where you've got a problem, you solve it through a line of code, it's more than that.

Zohra Mubeena-Mutabanna:

It's also from, from a hiring perspective, if companies are trying to hire tech writers, I think that's a great insight as to what do you look for. The soft skills are as important as the hard skills. And writing is a very small component of that. You're definitely looking at research skills and their aptitude for collaboration, their aptitude for that, what value add can they bring to this role is something that one should think about if you're hiring for a tech writer, and then once that role is filled, what does that journey look like for the overall product experience?

Swapnil Ogale:

Yeah, yeah, absolutely.

Zohra Mubeena-Mutabanna:

Is there anything that we may have missed and you'd like to add?

Swapnil Ogale:

No, I think I spoke about it a little bit in terms of, you're gonna put your hand up for things that outside your comfort zone, but also be aware of opportunities, like I said, with, with tech writing, it's often tricky, because people expect you to just be writing. But there are other opportunities. Like, like I said, technical writers come from all sorts of different experiences and backgrounds. So if you've got, you know, a graphic design background, maybe you're also good at drawing, and maybe you can actually illustrate something with visuals in your documentation. So you know, you can put your hand up and try and do that as part of your role. Add that to your, you know, your skill set. Other things also, like, you know, be aware of what's happening around in the, in the industry, like a lot of open source communities now, like, actively hire technical writers, they want technical writers. So if you want to, you know, contribute to open source documentation that they've got, if you've never worked as a tech writer before, those are some great starting places you can write for open source products and get that experience. But I know a lot of open source communities that have you know, worked with technical writers voluntarily, but they were so impressed, they've actually hired them as full time tech writers. And, you know, you get those opportunities, and you take them because they are different different products and different experiences than your own skill set. So step outside that comfort zone, put your hand up for things. And number one thing, again, is do not be afraid to disagree, like every single thing that you come across, challenge it, question it, because that will make you a better writer as well. Like personally, I've always felt, if you actually ask why. And I'm not afraid, like I've asked number of whys to different people and have come up with different answers. So that has probably made me a better writer. And that has probably also made our documentation a little bit better, because you then understand the context behind things like when you ask different people lie. So do not be afraid to disagree, debate, or dispel those common product. Thoughts. Yeah, I've got nothing else to add to that.

Zohra Mubeena-Mutabanna:

Thank you. Swapnil. You know, I think with everything that you've shared, my take away personally, is, even if I'm not in a formal advocacy role, I can advocate with the smallest contribution at any time. It doesn't have to be on a big scale. And you've shared how you can do that throughout this conversation. Fantastic. Thank you so much. Swapnil. This has been a fantastic conversation. And thank you for your time. I really enjoyed this.

Swapnil Ogale:

No worries. Thank you again for inviting me.

Zohra Mubeena-Mutabanna:

Thank you and have a lovely day.

Swapnil Ogale:

No worries. Thank you.

Zohra Mubeena-Mutabanna:

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