S3E8 Through the Lens of a Scrum Master - Speak Up and Advocate for Yourself with Jennifer Savage

Zohra Mubeena-Mutabanna: 0:04

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. I've been away for a while. And I've traveled across seven seas. And I'm glad to be back in the saddle here to interview my latest guest, Jennifer Savage. Jennifer is a Texas, local. And she graduated from the University of Texas at Austin with a Bachelor of journalism since having worked in journalism jobs. She's moved from print and transitioned into online space. She's been a technical writer in her past and now currently works at FinThrive as a Scrum Master. So Jennifer Savage, welcome to my show.

Jennifer Savage: 1:18

Great. Thanks, Zohra, for having me. I appreciate it. Yeah, so as you said, you know, you talked about kind of where I started. And where I moved to, I did all sorts of writings when I came out of college, different business writing and entertainment, writing and in journalism. And I kind of fell backwards into the tech writing world, just through knowing other people in the software companies and ended up in this role, working for a small, relatively small company that needed all of their software documented. So I joined them. Started from basically a bunch of printed documents and put them all into the online space for the other online and F1 help. I did that for many years here at FinThrive under a couple of different business names. And I've recently or I say recently, it's been several years now moved into the Scrum Master role. But I did serve on various delivery teams in the tech doc role. So I kind of moved into that space. So that's what I'm doing now.

Zohra Mubeena-Mutabanna: 2:13

That's awesome. You mentioned F1 Help. For our audience, can you share in what context.

Jennifer Savage: 2:18

Yeah, context sensitive help. So if you're on a field or a page, and you hit F1, and it pulls up the information for that very specific area on a page. And so that's what I did is I helped build into the software at FinThrive when it was an early company called, Xactimate, into their software. So yeah, that's all that help is there.

Zohra Mubeena-Mutabanna: 2:36

Yeah, that's awesome. Yeah, I mean, I have the context, is this commonly used - F1 help?

Jennifer Savage: 2:42

We still do in our web based software, my company now yeah, we're still using it, man, we have a lot of work in the medical software field. So there's a lot of very specific fields within all of our different software's and pages and interfaces. And so a lot of that, we do need a very specific F1 for that one field that could have 50 or 100, or 1000 different values. And so we work with that. Yeah. So that it is actually necessary, especially in the medical.

Zohra Mubeena-Mutabanna: 3:08

That's awesome. Jennifer, in the past when I have also created context sensitive help, that's the terminology that we have used. So it's nostalgic.

Jennifer Savage: 3:16

Yes, it is.

Zohra Mubeena-Mutabanna: 3:17

So you've worked as a technical writer, and now you're doing Scrum Master. Are there any similarities? And if so, what are those? ,

Jennifer Savage: 3:27

Oh, yeah! I definitely think so. And I think that's how I came into this role is I worked, like I said, on several delivery teams that were practicing Scrum, just as a individual contributor, as just doing the documentation for the different software pieces. And I really got into that role. Once we actually transitioned to Agile many, many years ago at this company, I really got into that process-oriented way of doing things; that software development lifecycle. And I think technical writers have a lot in common with that, because we're very process-oriented, right? You know, whenever we're going through and trying to document, what does this page do? How do you get to this point in the software, and you're sitting down with developers and so Scrum Masters, or developers and testers, but I think we can be a little more, I guess, I would say objective so that the developers or testers have a very specific, a little bit more narrow idea. And I've actually worked with some QAs, for example, that it becomes Scrum Masters as well. I just feel like for tech doc, I think it's definitely a more similar sort of thing, like I said, because that process orientation, because, you know, everybody, you know, we're we're team players, we're sort of team agnostic as well. We can like, for example, I worked on it at one point on five different teams. And so you can kind of bounce around, you can work well with different people in the group. So you're not just kind of like I said, like a dev focus or QA focus. You can work with everybody on all the teams. And I think we are good about asking questions that may maybe some people might think, as a dev or, or QA maybe we don't want to ask though, that's a silly question. But I think documentation you know, we're going to say, hey, how does this work? You've got to show me show me from the end user person I've never seen this page before. And so I think we have a good rapport with our teams.

Zohra Mubeena-Mutabanna: 5:05

Yeah. So it sounds like you're sort of working with the same stakeholders as well.

Jennifer Savage: 5:10

Yeah. Yeah, exactly. Yeah. So you have familiarity with that group of people. And also, you know, and as well, like the end users, as well. And then like, even internal end users, we created a lot of, you know, release notes. And like I said, online documentation, so not to even kind of help out with like marketing materials, you know, things they needed to know, same deal. How was this work? You know, it'd be very base level, how does this page work? Or what this new feature we're creating? So yeah, so we worked with internal and external stake holders, and then within the team as well. And so that's very similar to the Scrum Master role. You're bouncing around a lot of different people. Oh, yeah.

Zohra Mubeena-Mutabanna: 5:44

Bouncing around. I think that's well said.

Jennifer Savage: 5:47

That's definitely my experience, for sure.

Zohra Mubeena-Mutabanna: 5:50

Right, right. And I've had a similar I mean, I have been a technical writer for a long time. But I think what you just explained that it's very similar; the process, and the engagement is very similar. Definitely, I can draw parallels there. So now that you're on the other side, where you're interacting with technical communicators, do you have technical communicators on your Scrum teams?

Jennifer Savage: 6:10

We do.

Zohra Mubeena-Mutabanna: 6:11

Okay, so I'm curious, what does that partnership look like from the other side?

Jennifer Savage: 6:15

So it's funny, I guess, back when I was was in documentation, like when I was an individual contributor, I really, you know, push for it. And my teams, who historically hadn't really had them, as part of the team got used to it not used and then they kind of started thinking themselves like, oh, yeah, what about doc? Oh, yeah. Well, you know, like, especially when we transitioned to Scrum, and now I am on, my team's where I'm the Scrum Master, that's kind of my role. I'm like, okay, guys, you know, we just test this thing out. And we've got, again, coding code review, QA, design, review all this. But what about documentation? Does this need release notes? Does this need online help update? And I think I've gotten, I have a soft spot for it. So I'm always speaking up for my documentation person on my on my teams, you know, so I always I just feel like it's, from my perspective, because I have that background, I'm more likely to bring it up, where it's some team members are like, oh, yeah, that's an that's an afterthought, or that's how it went my first experiences when we transitioned into Scrum, I feel like, and I always appreciate it when anybody especially a trainer would say, coded, tested, documented. It's part of, you know, is that the definition of done. And we actually have that in our definitions of done.

Zohra Mubeena-Mutabanna: 7:21

Oh, yeah, that was actually going to be my follow up question. Is documentation part of your definitions of done? So then there is automatically that visibility,

Jennifer Savage: 7:30

Exactly.

Zohra Mubeena-Mutabanna: 7:31

And accountability as a team for everybody to make sure that documentation has a seat at the table. But to have somebody that advocates for a technical writer, I mean, there's nothing like that.

Jennifer Savage: 7:41

Yeah.

Zohra Mubeena-Mutabanna: 7:42

In my experience, I have had product owners who are advocates of technical documentation. Have you been on a team where that's not been a priority? And if so, has that been a challenge?

Jennifer Savage: 7:56

I guess I have in the past, there were some or you're kind of they were trying to slam all the documentation to the next iterations, or two or three iterations down the line. I said, no, we need to slice this to where I can document it within each. And that's not to be said, there aren't exceptions, where there might be a huge feature, something that at the end, we will have to kind of do one big wrap up and piece it together. But for the most part, I've been very fortunate, the product management teams that I've worked with have been very much advocates and very understanding of what's entailed, what's required and keeping in not just me, but our documentation folks in the loop and keeping them in that process as well. Yeah, I've been very lucky, I think, but I haven't really run into that as much of a challenge. But I know a lot of people do.

Zohra Mubeena-Mutabanna: 8:38

Yeah, yeah, that's true. And it's good to hear that more and more companies out there are sort of adopting Agile, or some hybrid form of Agile, a flavor of Agile and making sure that each of these functions are represented and advocated for in the process itself.

Jennifer Savage: 8:57

Yep. Yeah. It's great to see, yeah, that documentation is part of the process for sure.

Zohra Mubeena-Mutabanna: 9:03

Right now. I mean, I guess by asking this question, I'm really making myself sound stupid. But I'm gonna go ahead and ask this. Why, in your opinion, is the content that technical writers create important for you and the business?

Jennifer Savage: 9:17

Oh, for the business? I mean, I think that's pretty like I said, with online help release notes, letting the customers know what's coming out how it works, just all of that I think the business it's like super important, right? For me personally. So as a Scrum Master, I'm also theoretically agnostic. I actually am on a product now that I worked on documentation on the previous product that I was became a Scrum Master for so I knew that product backward and forward. This one I did not. So I rely heavily on the tech writers to help me out and help me learn about this product and his things. Over the years. I've actually, you know, leaned on them to say, Hey, can you send me that draft over whenever you're done just because I've got that experience and whether or not actually give me feedback. It's more just for me to learn the draft or the help or the drafted the release notes. Our tech writer is always in our planning meetings, you know, as much as she can be. And so that helps. I'm always calling on her to say, hey, you know, just want to make sure how long do you think it'll take you to get this done? I wanna make sure you're covered, or you got enough time to finish this. So, yeah, it's definitely important to me, though, in terms of learning about the products.

Zohra Mubeena-Mutabanna: 10:19

Oh, absolutely. I think that's a valid point. And I just sort of wanted that validation from you. Because I've had other interviews with project managers who are not even based in the United States. And they end up using technical documentation as their first source of truth, to learn more about the product. And that becomes part of the training and onboarding for these external teams, for companies that are consulting, or service providers sort of. So you sort of validate that it helps you onboard, it helps you, it becomes your product knowledge. So that's good to hear. Ya, Jennifer, that's good. That's good to know that, you know, you sort of validate that there is this similar learning that happens at your company now. Tell me a little about FinThrive? And I think that would probably give me a better context. And maybe technical documentation becomes even more critical. When it's a medical related business, or however you would like to put that.

Jennifer Savage: 11:18

No, definitely. So yeah, it's been five we do, primarily just various types of medical software, everything for hospitals, like contract management, and collections management, and claims management, all of these things are worked by different people throughout the hospitals. And it's very important because everything is federally mandated. So it's all the documentation is very, very key. And we've got 1000s upon 1000s of codes, and can it be used here? Can it be used, there are things that are, it explains like what you can and can't do in terms of submitting your claims and about how to price things. And so it is it's very critical, the work that we do in documentation for the medical, all of the medical software, we have a huge portfolio now of a lot of different kinds. And it's a big deal that we have documentation to cover all of that. We've got it across all of the ones that we've recently. Our company acquired some other companies, you know, so we're trying to kind of bring all that together as well make sure everything's covered, because it is so important to this type of software and work that's using it.

Zohra Mubeena-Mutabanna: 12:21

Okay, I'm going to ask a two part question here. One is, you've been a technical writer in your past, and now you're a Scrum Master. Given that you were a technical writer, were you always part of an Agile team? That's one question. If not, if you were part of, let's say, the waterfall model, where you embedded into your development, embedded in the development team. If not, so one is that that is sort of part one of my question. And two is what are the benefits of each from your perspective?

Jennifer Savage: 12:54

So I have done both, when I first started originally, with the original company that became FinThrive, it was like a sort of fairly small company. And I was, I mean, I was embedded with the development team. But there were, I don't know, maybe 10-15 of us total of it. It was very much waterfall; I was going through huge requirements, documents, trying to call out what the developers just spent weeks working on before we did a release. There was really no you know, real cadence to any of that. Because again, small startup, we're just putting things out there, just cranking out you know, and it was a lot of a releasing things to production, you know, on a very, very quick scale. And then later on, like, so when we adopted Agile, it made a huge difference for me, like I said, because I was embedded with the teams then as well. But it was completely different. I wasn't working off some huge requirements document, I was getting those pieces in manageable chunks, just like for a coder, that's how it would be it makes a huge difference. And then that way, I theoretically would be able to complete it all in order to meet that definition of done. But definitely that was when we moved to Scrum. I mean, it was completely a life changer for me in that tech doc role completely. And that's why I think I got so into it and really, really took a big piece of that screen and gotten to the Scrum Master role. I just took a big piece of that Scrum process and, and took all that in and said, this is awesome, you know, and it to me, it just makes sense. It's just common sense about how you do the iterative work, how you do the manageable chunks. And I feel like that goes across coding, testing, documentation.

Zohra Mubeena-Mutabanna: 14:25

I think everything that you just said, sort of, it sounds very manageable, very doable. One, you mentioned manageable chunks, the Definition of Done, and more importantly, aligning with what the other teams are doing.

Jennifer Savage: 14:38

Yes.

Zohra Mubeena-Mutabanna: 14:39

So you're sort of working hand in hand, right?

Jennifer Savage: 14:42

Absolutely. If you're working on multiple teams staying in that cadence, like the similar iterations. Or if you're doing you know, a two week sprint or four week sprint, just making sure all the teams are aligned. So that makes it a lot easier for someone in tech doc to be able to make sure like, for example, mine I have, we have several teams we have actually Like five teams that are doing this working on this one product, and we're all putting in all these teams are putting in code and, and we're documenting and all that, but because they're all on the same cadence, we're able to kind of fit everything together at the end of that release cycle. This is okay, here, it all gets together. And here's the release notes. And here's the help.

Zohra Mubeena-Mutabanna: 15:16

And documentation sort of becomes part of the product deliverable. It's not sitting outside.

Jennifer Savage: 15:21

Absolutely. Nope, it gets released, when our deployment, our release, deployment goes out the help. And I actually originally on the product that I came on board originally to document which was our claims management software, I was the one that kind of helped create that cadence, even though we were still kind of working in waterfall, and to say, hey, this should go out with the release, it doesn't need to go out a month later, six weeks later, even though we were still in the process of moving things over from like, basically a big PDF, and then print guide, I helped them kind of move that into a more iterative fashion, even though it was just whenever we decided to release. So I just, I kind of had to make sure I stayed up to date enough with that features.

Zohra Mubeena-Mutabanna: 16:01

I think that's brilliant. I think I owe you a thank you, as one professional to another.

Jennifer Savage: 16:06

Yeah,

Zohra Mubeena-Mutabanna: 16:07

Yeah, I think it's it's important because my whole objective with this season is to sort of not only shed light on what we do, but the value that documentation brings to the bottom line. And the earlier a writer is involved in the process, the better it is for everybody. Oh, yeah. And to the bottom line and to the business at the end of the day. What does the process look like for a writer on a Scrum team?Each company, no matter what the Agile processes, I mean, you may have a template. But the process varies, right? Some writers are not involved in sprint planning, or the standups. So I just want to understand what does that process look like, on your team?

Jennifer Savage: 16:47

So we typically, for my particular teams, our tech writer, is usually in planning when she can be. And if she can't, we have ways in our tool that we use, which is Azure DevOps, how we manage our work items, we have tags, we have tasks, have a way to trigger, like, hey, there's an online help update, or hey, this needs release notes. Also, our product managers on these teams are actually really good about providing some of that content as well. And working with the tech writer to review that work and make sure it says what it needs to say, or oh, this thing changed. So we're very fortunate that we have like I said, Good PMs, that that worked with us on that and work with the the tech writer, but generally, it's just part of that process. Like I said, it's part of that definition of done where we've got our coding, testing, document tasks. And she might be the last one, you know, to close out, but not necessarily sometimes she's done it, she's just waiting on a screenshot or something like that. It's not usually we're sitting here waiting on a story on oh, you know, documentations, or anything like that. She's like, yeah, we're very lucky that we have teams, the developers, the testers that will sit with her as well and kind of run through it. To make sure everything's done

Zohra Mubeena-Mutabanna: 17:57

it sounds like a very, like a well-oiled process.

Jennifer Savage: 18:01

And we actually, we've been fortunate to just I know, you know, Ron Gardner. He's the lead over these particular tech writers. And so they've got a great process in place across all of the teams. So not, it's not unique to mine, he's, you know, he's helped out trying to solidify and standardize that process across all of our organization. And that makes a huge difference. And it's not to say that everybody has to do the same thing all the time. But if you generally have these parameters, this is roughly where the teams are, you know, these are the standardized things that we're going to do across all the teams, that makes a huge difference, having somebody who buys into that, and even from our upper management as well, people who buy into documentation being worthwhile, and valuable is a huge thing. And we just, we've been very lucky at this company that they always have.

Zohra Mubeena-Mutabanna: 18:44

That's awesome. That's awesome. I mean, it's like music to my ears to listen, to hear that the upper management has bought into documentation, and the other related fields like probably I hope, of course, Ron and I are great friends, and I'm so happy, you know, you just brought a smile to my face when you mentioned Ron.

Jennifer Savage: 19:02

Yeah, Ron's great.

Zohra Mubeena-Mutabanna: 19:05

Just sort of know that, you know, not only are writers just providing documentation, but also sort of enabling the process. And...

Jennifer Savage: 19:13

Absolutely, yeah. You know, moving forward, and now we've gotten to a point where we have, you know, support or implementation going - Hey, where are those release notes? We need to know, you know, what's going on? And hey, do you haven't paid for this new feature, you know, and they're dependent on it at this point, and because we've been giving them such great content, always, now they know. And so they're expecting it. Yeah, we kind of set that expectation, which I think is great. You know, like I said, we've been very fortunate here, that we have a good support.

Zohra Mubeena-Mutabanna: 19:39

So that's, that's awesome. That's really fantastic. Now, you know, you sort of took me through what the process looks like for a technical writer. So you mentioned that they are not part of the sprint planning process. And I think I understand why because if you are on five different teams, and if all of them have the sprint starting at the same time, yeah. then it's very hard to be there.

Jennifer Savage: 20:02

And we try, like when they can they attend, right. But it's just they may not be able to attend, we basically stagger out, we have a beginning and end, you know, they're within a day or two of each other, but they attend, you know when they can, but if they can't, then like I said, the team is very aware. And again, a lot of times, I kind of am the reminder that, hey, we need to add a task for her because she is gonna have to come back and do this, or the PM will say, hey, you know, I think we're gonna need to update this page for this. And we'll just we'll just let her know. But I think it's about 50-50. She's there as much as she can be. But again, being spread across multiple teams, which I did as well. Right? You're there when you can be and then the rest of the team just asked us to stick up for them and help make sure that gets covered.

Zohra Mubeena-Mutabanna: 20:43

Yeah, I think, quote, unquote, stick up for the technical writer, I think that's such a wonderful thing. Because then the technical writer knows that even if they are not at that meeting, the entire team is looking out for them. And yeah, the product manager, yourself, the Scrum Master, and probably developers, QA, all of them are aware that this is the definition of done. So the writer isn't forgotten. Technically, right?

Jennifer Savage: 21:08

Yeah. And that's another good example is yeah, QA often will be like, hey, isn't this gonna change? This is going to look different? Or this is going to have different fields, don't we? Do we need to update the Help Page? Like everybody, I think is very just aware of that, because I think they will check on that as well, you know, when they're testing, and again, we're very fortunate we have a great writer on our team, who, sometimes she catches stuff that she like, hey, guys, you know, did these new release notes I wasn't able to get to planning, you know, and we're like, oh, yeah, that's my point being is we may miss some still. But it's, it's at least there we're thinking about it. And again, our PMs are good about thinking about that as well. So yeah.

Zohra Mubeena-Mutabanna: 21:39

That's fantastic. Now, I know I keep coming back to this question. So since they're not attending the sprint planning, are there any other Scrum ceremonies that they do attend and that the writers benefit from, and then the Scrum team benefits from?

Jennifer Savage: 21:53

So occasionally, you know, she'll come to our refinement meeting, as well. We'll return to like story time, where we talk about stories coming up. I think the planning is more valuable, usually, because it's actually ones that we've honed in on, it would be great if every tech writer could be a process of that whole design review and all that it's just not realistic, right? Especially when you're across multiple teams. I think for her, the next most valuable thing is probably the demo, our sprint report, our demo that we do every two weeks at the end of a sprint. Again, she can't always attend that. And I know that's the same across all of our tech writers, they can't always be there. Same deal. You've got, you know, multiple teams, multiple meetings, but we always make sure to record it, I always make sure to post it out there. In fact, she'll catch me occasionally say, hey, did you put it out there? Yeah. You know, because that's their way to catch up and see the things that have been completed, because they're not necessarily everyday and stand up, or, you know, in every planning or so that way they can catch up. And it gives them an overview, especially of the end-user facing that might affect the online help or the release notes. Yeah. So I know, that's a really big one, I think, for them to make sure we have that recorded and ready for them.

Zohra Mubeena-Mutabanna: 22:56

Right. So when you have the technology available, why not record it and make that? So?

Jennifer Savage: 23:01

Oh, absolutely.

Zohra Mubeena-Mutabanna: 23:02

I think that's all good stuff. And that's how the process is for me as well. It's very similar, because I am assigned to multiple teams. So I'm not able to be there for everything. And our process sort of is very similar to with the process that you have. And we have leaders that advocate for us and have bought into the process. So it sounds like a good, great place to be at.

Jennifer Savage: 23:22

Yeah, I think no, it is it's a thing for this role. Especially I mean, honestly, just in my over the years, I feel like places were taking documentation for granted. For lack of a better description, I feel like it's been more kind of pushed off to the side or was and I feel like we're kind of coming back around. Again, it's kind of cyclical, and but we've been very fortunate here that that they have always really valued it. And we've had this department and we've kept it and they realize the value. So I think that's huge.

Zohra Mubeena-Mutabanna: 23:49

Yeah, I mean, like you said, you know, there are companies, there are many companies that I have heard of and been part of where documentation is on the sidelines, and sometimes non existential. Yep. And the writers have to really, really advocate for themselves, and then even then the needle doesn't move much on it. Yes. And that really has sort of been an impetus for me, to sort of surface, we are really hidden. If you're not visible, how do we become visible? And what is it that we do on a day-to-day basis, like you said, you mentioned, writers catch stuff, and that has happened so often when we end up testing, or even I will share this, the company that I work at right now sometimes we are part of the discovery process. And I get to sit in on it. The product managers invite us and where we are getting the opportunity to directly engage with our customers. So we end up wondering, yeah, I know this is not possible at every company. But let's say at your company, your product manager is interacting with customers. But because the relationship is there for the writers, they have that access to the product manager. They sort of get that firsthand information directly from the Product Manager. This is what the customer wants, this is what the terminology may be. This is what the use case may be, this is what it's going to look like. So there is you're sort of closer to the customer more than as it should be. So looks like your process, even though I'm guessing writers probably do not sit in on Discovery, right? Yeah, yeah. But it has given me so many opportunities where I have gotten to ask questions directly to the customer and get some direction. And if we've had inconsistencies with terminology or disagreements there, there are a lot of benefits and this sort of, over the long term, it ends up becoming so important, because then content becomes your ally, content becomes your strength. So all good stuff, Jennifer, so far, I think we've covered quite a bit of your content here. And as I'm realizing we're almost close to the hour, since we started talking, and you were worried about content, looking how much content you provided me with. So thank you for that. I think the one question that comes to my mind is, since you've been a technical writer, and our Scrum Master, are there any suggestions you can share for tech writers that are entering the industry, on how they can elevate their value or better engage with the stakeholders?

Jennifer Savage: 26:09

Sure, I think a lot of it goes back to some of the things we've talked about as being a member of, especially if you're in Scrum, or even if you're doing Waterfall, just being a member of that team. And speaking up for yourself advocating for yourself. I mean, obviously, we'd love for the team members to do that I'm in the unique position that they do. But as we discussed a few minutes ago, I don't know that that's always the case at every company. So I would say get in there advocate for yourself, kind of prove that value and quality, point out the help or the release notes or whatever type of documentation you're creating, and make it great and make it valuable and people will lean on it. That's what we've found, like I think I mentioned is that are some of our stakeholders. Now, the first thing I look for, so you do have to advocate for yourself a little bit. But especially if you're in a process like Scrum, you can easily say, hey, can we make my piece a definition of done? If it's not, it's possible a lot of places don't have that technical documentation as part of the completion of a user story or bug, but speak up, say, hey, I think we should, you know, suggest that that's part of a team and working agreement, and you know, all of those pieces, and you're a team member.

Zohra Mubeena-Mutabanna: 27:12

So fantastic. That is awesome. I think I completely agree with you on that. I completely agree that if there is no process, you want to embed yourself? Yes, with that, within the appropriate one, how to create one exactly really advocate, and advocating can happen in so many ways, like you say in small ways and big ways. So look for those small opportunities to start with. And if you already have the lead on that, then try and look for bigger opportunities where you can really make an impact. Mmm, yes, bringing quality to the table, I think makes a big, big difference. So there is that onus on us to make sure that the documentation that we're creating is of quality. So awesome, awesome pointers there. I think this probably will be my last question for the evening. What are your takeaways or highlights from interacting with writers as a Scrum Master and the content that the writers create?

Jennifer Savage: 28:06

Well, it's been very rewarding. I mean, especially moving from that role into this one and being able to work together to make sure that they are part of the process, for them to be to want to be a part of the process, and actually really collaborate with the team and see the interaction between them. I think that's been the best thing to see is it again, it's, it's a team atmosphere. And so it's not just these though, you know, the QA documentation, it's all one group, including the PM, including the Scrum Master. It's been great from an Agile perspective to see them embedded with the teams and work as a, like, I always call myself an individual contributor. But the more I worked on Scrum teams, I feel like okay, no, I was just part of the team. I was just another, you know, I was just in a, you know, and some people think they're just a cog, a cog in the wheel. But it's not even that same deal where it's all part of a process. And we've got developers helping documentation and documentation helping QA or helping PMs, you know, or vice versa. So it's really awesome to see, I think that's been my biggest takeaway is watching them really grow into these great collaborative team members, you know, along with the other the other folks, I say all this, it's funny, because I know this is a, we're a tech writer-centric group, but with this podcast, but it's like, I've been very lucky to work with great developers, testers, documentation, product managers across my career. So that makes a huge difference to when you have, you know, a great collaborative team like this, right?

Zohra Mubeena-Mutabanna: 29:27

Absolutely. I mean, as much as yes, this podcast is focused on technical communication, but we cannot work in a silo. Right?

Jennifer Savage: 29:37

Exactly.

Zohra Mubeena-Mutabanna: 29:37

We need the support.

Jennifer Savage: 29:38

Absolutely.

Zohra Mubeena-Mutabanna: 29:39

And all the members, all the actors that you mentioned, are sort of our biggest, you know, they're cheering for us from the sidelines, and they are the ones that really us help us move forward. Absolutely. We cannot do this by ourselves. So it is it's important that developers and QA and UX are working with us, and that partnership and that collaboration is what helps the team move forward, and to delight the customers at the end of the day. So, like you said, I've been fortunate, and I hope more writers entering the field, have this positive experience. And we also have to take some responsibility to bring that positivity. It's not all on others. It's also on us to absolutely to advocate for ourselves. Because without that, we cannot. If we are not visible, then you're like you said, we are sort of like a cog in the wheel, as some people may call it. And and we want to sort of change the dynamics change that perspective of us. So all awesome pointers here, Jennifer, I've really enjoyed having this conversation with you. Lots of good nuggets in there.

Jennifer Savage: 30:42

Yeah, there's been a lot of fun just chatting about it. I love talking about this.

Zohra Mubeena-Mutabanna: 30:46

Yes, me too.

Jennifer Savage: 30:47

Tech doc or Scrum, or, uh, yeah, it's been really enjoyable.

Zohra Mubeena-Mutabanna: 30:50

Yeah, it's been an enjoyable conversation. And thank you for bringing this valuable conversation to us. And to my audience, we really appreciate it. Is there anything that you would like to add? Yep, I think I think I'm good. Awesome. Appreciate it. Yeah. Thank you. I appreciate it, too. I want to thank you, and have a lovely evening, Jennifer, this has been fantastic.

Jennifer Savage: 31:11

Great talking to you. Great talking to you to

Zohra Mubeena-Mutabanna: 31:14

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 inside tech comm dot show. Catch you on another episode.