0:04

Hello,

0:04

listeners. Welcome to Inside

0:06

Tech Comm with your host Zohra

0:06

Mutabanna. In season three, we

0:12

shift our focus to shed light on

0:12

why Technical Communication is a

0:17

core business asset. In this

0:17

regard, we will speak with

0:21

guests who are our stakeholders,

0:21

such as product managers,

0:25

marketing professionals, UX

0:25

designers, QA and customer

0:30

support, who engage with writers

0:30

to create a seamless experience

0:34

for the customer, and meet

0:34

business goals together. Let's

0:38

get started. I've been away for

0:38

a while. And I've traveled

0:44

across seven seas. And I'm glad

0:44

to be back in the saddle here to

0:49

interview my latest guest,

0:49

Jennifer Savage. Jennifer is a

0:54

Texas, local. And she graduated

0:54

from the University of Texas at

0:59

Austin with a Bachelor of

0:59

journalism since having worked

1:04

in journalism jobs. She's moved

1:04

from print and transitioned into

1:07

online space. She's been a

1:07

technical writer in her past and

1:11

now currently works at FinThrive

1:11

as a Scrum Master. So Jennifer

1:15

Savage, welcome to my show.

1:18

Great. Thanks, Zohra, for having me. I appreciate it. Yeah, so as you

1:20

said, you know, you talked about

1:23

kind of where I started. And

1:23

where I moved to, I did all

1:25

sorts of writings when I came

1:25

out of college, different

1:27

business writing and

1:27

entertainment, writing and in

1:30

journalism. And I kind of fell

1:30

backwards into the tech writing

1:33

world, just through knowing

1:33

other people in the software

1:37

companies and ended up in this

1:37

role, working for a small,

1:41

relatively small company that

1:41

needed all of their software

1:44

documented. So I joined them.

1:44

Started from basically a bunch

1:48

of printed documents and put

1:48

them all into the online space

1:51

for the other online and F1

1:51

help. I did that for many years

1:55

here at FinThrive under a couple

1:55

of different business names. And

1:59

I've recently or I say recently,

1:59

it's been several years now

2:03

moved into the Scrum Master

2:03

role. But I did serve on various

2:06

delivery teams in the tech doc

2:06

role. So I kind of moved into

2:11

that space. So that's what I'm doing now.

2:13

That's

2:13

awesome. You mentioned F1 Help.

2:15

For our audience, can you share

2:15

in what context.

2:18

Yeah, context

2:18

sensitive help. So if you're on

2:21

a field or a page, and you hit

2:21

F1, and it pulls up the

2:24

information for that very

2:24

specific area on a page. And so

2:27

that's what I did is I helped

2:27

build into the software at

2:30

FinThrive when it was an early

2:30

company called, Xactimate, into

2:33

their software. So yeah, that's

2:33

all that help is there.

2:36

Yeah, that's awesome. Yeah, I mean, I have the context, is this

2:38

commonly used - F1 help?

2:42

We still do in

2:42

our web based software, my

2:45

company now yeah, we're still

2:45

using it, man, we have a lot of

2:48

work in the medical software

2:48

field. So there's a lot of very

2:50

specific fields within all of

2:50

our different software's and

2:55

pages and interfaces. And so a

2:55

lot of that, we do need a very

2:58

specific F1 for that one field

2:58

that could have 50 or 100, or

3:03

1000 different values. And so we

3:03

work with that. Yeah. So that it

3:06

is actually necessary, especially in the medical.

3:08

That's awesome. Jennifer, in the past when I have also created context

3:10

sensitive help, that's the

3:12

terminology that we have used.

3:12

So it's nostalgic.

3:16

Yes, it is.

3:17

So

3:17

you've worked as a technical

3:20

writer, and now you're doing

3:20

Scrum Master. Are there any

3:24

similarities? And if so, what

3:24

are those? ,

3:27

Oh, yeah! I definitely think so. And I think that's how I came into this role

3:29

is I worked, like I said, on

3:33

several delivery teams that were

3:33

practicing Scrum, just as a

3:36

individual contributor, as just

3:36

doing the documentation for the

3:39

different software pieces. And I

3:39

really got into that role. Once

3:42

we actually transitioned to

3:42

Agile many, many years ago at

3:46

this company, I really got into

3:46

that process-oriented way of

3:51

doing things; that software

3:51

development lifecycle. And I

3:53

think technical writers have a

3:53

lot in common with that, because

3:56

we're very process-oriented,

3:56

right? You know, whenever we're

3:58

going through and trying to

3:58

document, what does this page

4:01

do? How do you get to this point

4:01

in the software, and you're

4:04

sitting down with developers and

4:04

so Scrum Masters, or developers

4:08

and testers, but I think we can

4:08

be a little more, I guess, I

4:10

would say objective so that the

4:10

developers or testers have a

4:13

very specific, a little bit more

4:13

narrow idea. And I've actually

4:17

worked with some QAs, for

4:17

example, that it becomes Scrum

4:19

Masters as well. I just feel

4:19

like for tech doc, I think it's

4:22

definitely a more similar sort

4:22

of thing, like I said, because

4:25

that process orientation,

4:25

because, you know, everybody,

4:28

you know, we're we're team players, we're sort of team agnostic as well. We can like,

4:30

for example, I worked on it at

4:33

one point on five different

4:33

teams. And so you can kind of

4:36

bounce around, you can work well

4:36

with different people in the

4:39

group. So you're not just kind

4:39

of like I said, like a dev focus

4:42

or QA focus. You can work with

4:42

everybody on all the teams. And

4:45

I think we are good about asking

4:45

questions that may maybe some

4:49

people might think, as a dev or,

4:49

or QA maybe we don't want to ask

4:53

though, that's a silly question.

4:53

But I think documentation you

4:55

know, we're going to say, hey,

4:55

how does this work? You've got

4:57

to show me show me from the end

4:57

user person I've never seen this

5:01

page before. And so I think we

5:01

have a good rapport with our

5:04

teams.

5:05

Yeah.

5:05

So it sounds like you're sort of

5:07

working with the same

5:07

stakeholders as well.

5:10

Yeah. Yeah,

5:10

exactly. Yeah. So you have

5:13

familiarity with that group of

5:13

people. And also, you know, and

5:16

as well, like the end users, as

5:16

well. And then like, even

5:19

internal end users, we created a

5:19

lot of, you know, release notes.

5:23

And like I said, online

5:23

documentation, so not to even

5:26

kind of help out with like marketing materials, you know, things they needed to know, same

5:28

deal. How was this work? You

5:30

know, it'd be very base level,

5:30

how does this page work? Or what

5:32

this new feature we're creating?

5:32

So yeah, so we worked with

5:35

internal and external stake

5:35

holders, and then within the

5:39

team as well. And so that's very

5:39

similar to the Scrum Master

5:41

role. You're bouncing around a

5:41

lot of different people. Oh,

5:44

yeah.

5:44

Bouncing around. I think that's well said.

5:47

That's

5:47

definitely my experience, for

5:49

sure.

5:50

Right, right. And I've had a similar I mean, I have been a technical

5:52

writer for a long time. But I

5:55

think what you just explained

5:55

that it's very similar; the

5:57

process, and the engagement is

5:57

very similar. Definitely, I can

6:01

draw parallels there. So now

6:01

that you're on the other side,

6:05

where you're interacting with

6:05

technical communicators, do you

6:07

have technical communicators on

6:07

your Scrum teams?

6:10

We do.

6:11

Okay,

6:11

so I'm curious, what does that

6:13

partnership look like from the other side?

6:15

So it's funny,

6:15

I guess, back when I was was in

6:19

documentation, like when I was

6:19

an individual contributor, I

6:21

really, you know, push for it.

6:21

And my teams, who historically

6:24

hadn't really had them, as part

6:24

of the team got used to it not

6:27

used and then they kind of started thinking themselves like, oh, yeah, what about doc?

6:29

Oh, yeah. Well, you know, like,

6:32

especially when we transitioned

6:32

to Scrum, and now I am on, my

6:34

team's where I'm the Scrum

6:34

Master, that's kind of my role.

6:37

I'm like, okay, guys, you know,

6:37

we just test this thing out. And

6:40

we've got, again, coding code

6:40

review, QA, design, review all

6:45

this. But what about documentation? Does this need release notes? Does this need

6:46

online help update? And I think

6:50

I've gotten, I have a soft spot

6:50

for it. So I'm always speaking

6:53

up for my documentation person

6:53

on my on my teams, you know, so

6:56

I always I just feel like it's,

6:56

from my perspective, because I

6:58

have that background, I'm more

6:58

likely to bring it up, where

7:01

it's some team members are like,

7:01

oh, yeah, that's an that's an

7:03

afterthought, or that's how it

7:03

went my first experiences when

7:07

we transitioned into Scrum, I

7:07

feel like, and I always

7:10

appreciate it when anybody

7:10

especially a trainer would say,

7:13

coded, tested, documented. It's

7:13

part of, you know, is that the

7:17

definition of done. And we

7:17

actually have that in our

7:19

definitions of done.

7:21

Oh, yeah, that was actually going to be my follow up question. Is

7:22

documentation part of your

7:25

definitions of done? So then

7:25

there is automatically that

7:29

visibility,

7:30

Exactly.

7:31

And accountability as a team for everybody to make sure that

7:33

documentation has a seat at the

7:35

table. But to have somebody that

7:35

advocates for a technical

7:39

writer, I mean, there's nothing like that.

7:41

Yeah.

7:42

In my

7:42

experience, I have had product

7:45

owners who are advocates of

7:45

technical documentation. Have

7:50

you been on a team where that's

7:50

not been a priority? And if so,

7:54

has that been a challenge?

7:56

I guess I have

7:56

in the past, there were some or

7:59

you're kind of they were trying

7:59

to slam all the documentation to

8:02

the next iterations, or two or

8:02

three iterations down the line.

8:05

I said, no, we need to slice

8:05

this to where I can document it

8:08

within each. And that's not to be said, there aren't exceptions, where there might be

8:10

a huge feature, something that

8:13

at the end, we will have to kind

8:13

of do one big wrap up and piece

8:16

it together. But for the most

8:16

part, I've been very fortunate,

8:18

the product management teams that I've worked with have been very much advocates and very

8:20

understanding of what's

8:24

entailed, what's required and

8:24

keeping in not just me, but our

8:28

documentation folks in the loop

8:28

and keeping them in that process

8:31

as well. Yeah, I've been very

8:31

lucky, I think, but I haven't

8:34

really run into that as much of

8:34

a challenge. But I know a lot of

8:37

people do.

8:38

Yeah,

8:38

yeah, that's true. And it's good

8:41

to hear that more and more

8:41

companies out there are sort of

8:44

adopting Agile, or some hybrid

8:44

form of Agile, a flavor of Agile

8:49

and making sure that each of

8:49

these functions are represented

8:54

and advocated for in the process

8:54

itself.

8:57

Yep. Yeah. It's

8:57

great to see, yeah, that

9:00

documentation is part of the

9:00

process for sure.

9:03

Right

9:03

now. I mean, I guess by asking

9:05

this question, I'm really making

9:05

myself sound stupid. But I'm

9:08

gonna go ahead and ask this.

9:08

Why, in your opinion, is the

9:11

content that technical writers

9:11

create important for you and the

9:15

business?

9:17

Oh, for the business? I mean, I think that's pretty like I said, with online

9:18

help release notes, letting the

9:21

customers know what's coming out

9:21

how it works, just all of that I

9:25

think the business it's like

9:25

super important, right? For me

9:27

personally. So as a Scrum

9:27

Master, I'm also theoretically

9:32

agnostic. I actually am on a

9:32

product now that I worked on

9:35

documentation on the previous

9:35

product that I was became a

9:38

Scrum Master for so I knew that

9:38

product backward and forward.

9:40

This one I did not. So I rely

9:40

heavily on the tech writers to

9:45

help me out and help me learn

9:45

about this product and his

9:48

things. Over the years. I've

9:48

actually, you know, leaned on

9:51

them to say, Hey, can you send

9:51

me that draft over whenever

9:53

you're done just because I've

9:53

got that experience and whether

9:56

or not actually give me feedback. It's more just for me to learn the draft or the help

9:58

or the drafted the release

10:00

notes. Our tech writer is always

10:00

in our planning meetings, you

10:04

know, as much as she can be. And

10:04

so that helps. I'm always

10:07

calling on her to say, hey, you

10:07

know, just want to make sure how

10:10

long do you think it'll take you to get this done? I wanna make sure you're covered, or you got

10:12

enough time to finish this. So,

10:15

yeah, it's definitely important

10:15

to me, though, in terms of

10:17

learning about the products.

10:19

Oh, absolutely. I think that's a valid point. And I just sort of

10:21

wanted that validation from you.

10:25

Because I've had other

10:25

interviews with project managers

10:29

who are not even based in the

10:29

United States. And they end up

10:32

using technical documentation as

10:32

their first source of truth, to

10:36

learn more about the product.

10:36

And that becomes part of the

10:39

training and onboarding for

10:39

these external teams, for

10:43

companies that are consulting,

10:43

or service providers sort of. So

10:48

you sort of validate that it

10:48

helps you onboard, it helps you,

10:51

it becomes your product

10:51

knowledge. So that's good to

10:54

hear. Ya, Jennifer, that's good.

10:54

That's good to know that, you

10:57

know, you sort of validate that

10:57

there is this similar learning

11:01

that happens at your company

11:01

now. Tell me a little about

11:04

FinThrive? And I think that

11:04

would probably give me a better

11:08

context. And maybe technical

11:08

documentation becomes even more

11:11

critical. When it's a medical

11:11

related business, or however you

11:17

would like to put that.

11:18

No, definitely.

11:18

So yeah, it's been five we do,

11:21

primarily just various types of

11:21

medical software, everything for

11:25

hospitals, like contract

11:25

management, and collections

11:28

management, and claims

11:28

management, all of these things

11:31

are worked by different people

11:31

throughout the hospitals. And

11:34

it's very important because

11:34

everything is federally

11:36

mandated. So it's all the

11:36

documentation is very, very key.

11:41

And we've got 1000s upon 1000s

11:41

of codes, and can it be used

11:45

here? Can it be used, there are

11:45

things that are, it explains

11:48

like what you can and can't do

11:48

in terms of submitting your

11:50

claims and about how to price

11:50

things. And so it is it's very

11:55

critical, the work that we do in

11:55

documentation for the medical,

11:59

all of the medical software, we

11:59

have a huge portfolio now of a

12:02

lot of different kinds. And it's

12:02

a big deal that we have

12:05

documentation to cover all of

12:05

that. We've got it across all of

12:08

the ones that we've recently.

12:08

Our company acquired some other

12:11

companies, you know, so we're

12:11

trying to kind of bring all that

12:13

together as well make sure

12:13

everything's covered, because it

12:16

is so important to this type of

12:16

software and work that's using

12:20

it.

12:21

Okay,

12:21

I'm going to ask a two part

12:23

question here. One is, you've

12:23

been a technical writer in your

12:27

past, and now you're a Scrum

12:27

Master. Given that you were a

12:31

technical writer, were you

12:31

always part of an Agile team?

12:34

That's one question. If not, if

12:34

you were part of, let's say, the

12:38

waterfall model, where you

12:38

embedded into your development,

12:43

embedded in the development

12:43

team. If not, so one is that

12:48

that is sort of part one of my

12:48

question. And two is what are

12:51

the benefits of each from your

12:51

perspective?

12:54

So I have done

12:54

both, when I first started

12:57

originally, with the original

12:57

company that became FinThrive,

13:00

it was like a sort of fairly

13:00

small company. And I was, I

13:03

mean, I was embedded with the development team. But there were, I don't know, maybe 10-15

13:05

of us total of it. It was very

13:08

much waterfall; I was going

13:08

through huge requirements,

13:11

documents, trying to call out

13:11

what the developers just spent

13:15

weeks working on before we did a

13:15

release. There was really no you

13:19

know, real cadence to any of

13:19

that. Because again, small

13:22

startup, we're just putting

13:22

things out there, just cranking

13:24

out you know, and it was a lot

13:24

of a releasing things to

13:27

production, you know, on a very,

13:27

very quick scale. And then later

13:31

on, like, so when we adopted

13:31

Agile, it made a huge difference

13:34

for me, like I said, because I

13:34

was embedded with the teams then

13:38

as well. But it was completely

13:38

different. I wasn't working off

13:40

some huge requirements document,

13:40

I was getting those pieces in

13:45

manageable chunks, just like for

13:45

a coder, that's how it would be

13:48

it makes a huge difference. And

13:48

then that way, I theoretically

13:51

would be able to complete it all

13:51

in order to meet that definition

13:53

of done. But definitely that was

13:53

when we moved to Scrum. I mean,

13:58

it was completely a life changer

13:58

for me in that tech doc role

14:02

completely. And that's why I

14:02

think I got so into it and

14:05

really, really took a big piece

14:05

of that screen and gotten to the

14:08

Scrum Master role. I just took a

14:08

big piece of that Scrum process

14:11

and, and took all that in and

14:11

said, this is awesome, you know,

14:13

and it to me, it just makes

14:13

sense. It's just common sense

14:16

about how you do the iterative

14:16

work, how you do the manageable

14:19

chunks. And I feel like that

14:19

goes across coding, testing,

14:24

documentation.

14:25

I think everything that you just said, sort of, it sounds very

14:27

manageable, very doable. One,

14:31

you mentioned manageable chunks,

14:31

the Definition of Done, and more

14:35

importantly, aligning with what

14:35

the other teams are doing.

14:38

Yes.

14:39

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

14:42

Absolutely. If

14:42

you're working on multiple teams

14:44

staying in that cadence, like

14:44

the similar iterations. Or if

14:47

you're doing you know, a two

14:47

week sprint or four week sprint,

14:50

just making sure all the teams

14:50

are aligned. So that makes it a

14:53

lot easier for someone in tech

14:53

doc to be able to make sure

14:57

like, for example, mine I have,

14:57

we have several teams we have

14:59

actually Like five teams that

14:59

are doing this working on this

15:02

one product, and we're all

15:02

putting in all these teams are

15:05

putting in code and, and we're

15:05

documenting and all that, but

15:07

because they're all on the same

15:07

cadence, we're able to kind of

15:10

fit everything together at the

15:10

end of that release cycle. This

15:13

is okay, here, it all gets

15:13

together. And here's the release

15:15

notes. And here's the help.

15:16

And

15:16

documentation sort of becomes

15:19

part of the product deliverable.

15:19

It's not sitting outside.

15:21

Absolutely.

15:21

Nope, it gets released, when our

15:24

deployment, our release,

15:24

deployment goes out the help.

15:26

And I actually originally on the

15:26

product that I came on board

15:30

originally to document which was

15:30

our claims management software,

15:33

I was the one that kind of

15:33

helped create that cadence, even

15:35

though we were still kind of

15:35

working in waterfall, and to

15:37

say, hey, this should go out

15:37

with the release, it doesn't

15:40

need to go out a month later,

15:40

six weeks later, even though we

15:43

were still in the process of

15:43

moving things over from like,

15:46

basically a big PDF, and then

15:46

print guide, I helped them kind

15:50

of move that into a more

15:50

iterative fashion, even though

15:54

it was just whenever we decided

15:54

to release. So I just, I kind of

15:57

had to make sure I stayed up to

15:57

date enough with that features.

16:01

I think

16:01

that's brilliant. I think I owe

16:04

you a thank you, as one

16:04

professional to another.

16:06

Yeah,

16:07

Yeah, I think it's it's important because my whole objective with

16:08

this season is to sort of not

16:14

only shed light on what we do,

16:14

but the value that documentation

16:17

brings to the bottom line. And

16:17

the earlier a writer is involved

16:22

in the process, the better it is

16:22

for everybody. Oh, yeah. And to

16:26

the bottom line and to the business at the end of the day. What does the process look like

16:29

for a writer on a Scrum

16:32

team?Each company, no matter

16:32

what the Agile processes, I

16:36

mean, you may have a template.

16:36

But the process varies, right?

16:39

Some writers are not involved in

16:39

sprint planning, or the

16:42

standups. So I just want to

16:42

understand what does that

16:45

process look like, on your team?

16:47

So we

16:47

typically, for my particular

16:50

teams, our tech writer, is

16:50

usually in planning when she can

16:53

be. And if she can't, we have

16:53

ways in our tool that we use,

16:57

which is Azure DevOps, how we

16:57

manage our work items, we have

17:01

tags, we have tasks, have a way

17:01

to trigger, like, hey, there's

17:05

an online help update, or hey,

17:05

this needs release notes. Also,

17:08

our product managers on these

17:08

teams are actually really good

17:11

about providing some of that

17:11

content as well. And working

17:15

with the tech writer to review

17:15

that work and make sure it says

17:18

what it needs to say, or oh,

17:18

this thing changed. So we're

17:21

very fortunate that we have like

17:21

I said, Good PMs, that that

17:24

worked with us on that and work

17:24

with the the tech writer, but

17:28

generally, it's just part of

17:28

that process. Like I said, it's

17:30

part of that definition of done

17:30

where we've got our coding,

17:33

testing, document tasks. And she

17:33

might be the last one, you know,

17:36

to close out, but not

17:36

necessarily sometimes she's done

17:39

it, she's just waiting on a

17:39

screenshot or something like

17:41

that. It's not usually we're

17:41

sitting here waiting on a story

17:44

on oh, you know, documentations,

17:44

or anything like that. She's

17:48

like, yeah, we're very lucky

17:48

that we have teams, the

17:51

developers, the testers that

17:51

will sit with her as well and

17:54

kind of run through it. To make

17:54

sure everything's done

17:57

it

17:57

sounds like a very, like a

17:59

well-oiled process.

18:01

And we actually, we've been fortunate to just I know, you know, Ron

18:02

Gardner. He's the lead over

18:06

these particular tech writers.

18:06

And so they've got a great

18:08

process in place across all of

18:08

the teams. So not, it's not

18:12

unique to mine, he's, you know,

18:12

he's helped out trying to

18:14

solidify and standardize that

18:14

process across all of our

18:17

organization. And that makes a

18:17

huge difference. And it's not to

18:20

say that everybody has to do the

18:20

same thing all the time. But if

18:23

you generally have these

18:23

parameters, this is roughly

18:25

where the teams are, you know,

18:25

these are the standardized

18:28

things that we're going to do

18:28

across all the teams, that makes

18:30

a huge difference, having

18:30

somebody who buys into that, and

18:34

even from our upper management

18:34

as well, people who buy into

18:36

documentation being worthwhile,

18:36

and valuable is a huge thing.

18:40

And we just, we've been very

18:40

lucky at this company that they

18:42

always have.

18:44

That's awesome. That's awesome. I mean, it's like music to my ears to

18:46

listen, to hear that the upper

18:50

management has bought into

18:50

documentation, and the other

18:54

related fields like probably I

18:54

hope, of course, Ron and I are

18:58

great friends, and I'm so happy,

18:58

you know, you just brought a

19:00

smile to my face when you mentioned Ron.

19:02

Yeah, Ron's great.

19:05

Just sort of know that, you know, not only are writers just providing

19:06

documentation, but also sort of

19:10

enabling the process. And...

19:13

Absolutely,

19:13

yeah. You know, moving forward,

19:15

and now we've gotten to a point

19:15

where we have, you know, support

19:19

or implementation going - Hey,

19:19

where are those release notes?

19:21

We need to know, you know,

19:21

what's going on? And hey, do you

19:24

haven't paid for this new

19:24

feature, you know, and they're

19:26

dependent on it at this point,

19:26

and because we've been giving

19:29

them such great content, always,

19:29

now they know. And so they're

19:33

expecting it. Yeah, we kind of

19:33

set that expectation, which I

19:35

think is great. You know, like I

19:35

said, we've been very fortunate

19:38

here, that we have a good support.

19:39

So that's, that's awesome. That's really fantastic. Now, you know,

19:41

you sort of took me through what

19:45

the process looks like for a

19:45

technical writer. So you

19:49

mentioned that they are not part

19:49

of the sprint planning process.

19:51

And I think I understand why

19:51

because if you are on five

19:54

different teams, and if all of

19:54

them have the sprint starting at

19:58

the same time, yeah. then it's

19:58

very hard to be there.

20:02

And we try,

20:02

like when they can they attend,

20:06

right. But it's just they may

20:06

not be able to attend, we

20:08

basically stagger out, we have a

20:08

beginning and end, you know,

20:11

they're within a day or two of

20:11

each other, but they attend, you

20:15

know when they can, but if they

20:15

can't, then like I said, the

20:17

team is very aware. And again, a

20:17

lot of times, I kind of am the

20:21

reminder that, hey, we need to

20:21

add a task for her because she

20:24

is gonna have to come back and do this, or the PM will say, hey, you know, I think we're

20:25

gonna need to update this page

20:28

for this. And we'll just we'll

20:28

just let her know. But I think

20:30

it's about 50-50. She's there as

20:30

much as she can be. But again,

20:33

being spread across multiple

20:33

teams, which I did as well.

20:36

Right? You're there when you can

20:36

be and then the rest of the team

20:40

just asked us to stick up for

20:40

them and help make sure that

20:43

gets covered.

20:43

Yeah, I

20:43

think, quote, unquote, stick up

20:46

for the technical writer, I

20:46

think that's such a wonderful

20:49

thing. Because then the

20:49

technical writer knows that even

20:51

if they are not at that meeting,

20:51

the entire team is looking out

20:55

for them. And yeah, the product

20:55

manager, yourself, the Scrum

20:58

Master, and probably developers,

20:58

QA, all of them are aware that

21:03

this is the definition of done.

21:03

So the writer isn't forgotten.

21:07

Technically, right?

21:08

Yeah. And that's another good example is yeah, QA often will be like,

21:10

hey, isn't this gonna change?

21:12

This is going to look different? Or this is going to have different fields, don't we? Do

21:14

we need to update the Help Page?

21:16

Like everybody, I think is very just aware of that, because I think they will check on that as

21:18

well, you know, when they're testing, and again, we're very

21:20

fortunate we have a great writer

21:23

on our team, who, sometimes she

21:23

catches stuff that she like,

21:26

hey, guys, you know, did these

21:26

new release notes I wasn't able

21:29

to get to planning, you know,

21:29

and we're like, oh, yeah, that's

21:32

my point being is we may miss

21:32

some still. But it's, it's at

21:35

least there we're thinking about

21:35

it. And again, our PMs are good

21:37

about thinking about that as well. So yeah.

21:39

That's

21:39

fantastic. Now, I know I keep

21:42

coming back to this question. So

21:42

since they're not attending the

21:44

sprint planning, are there any

21:44

other Scrum ceremonies that they

21:48

do attend and that the writers

21:48

benefit from, and then the Scrum

21:51

team benefits from?

21:53

So

21:53

occasionally, you know, she'll

21:55

come to our refinement meeting,

21:55

as well. We'll return to like

21:58

story time, where we talk about

21:58

stories coming up. I think the

22:00

planning is more valuable,

22:00

usually, because it's actually

22:03

ones that we've honed in on, it

22:03

would be great if every tech

22:06

writer could be a process of

22:06

that whole design review and all

22:08

that it's just not realistic, right? Especially when you're across multiple teams. I think

22:10

for her, the next most valuable

22:14

thing is probably the demo, our

22:14

sprint report, our demo that we

22:18

do every two weeks at the end of

22:18

a sprint. Again, she can't

22:20

always attend that. And I know that's the same across all of our tech writers, they can't

22:22

always be there. Same deal.

22:24

You've got, you know, multiple

22:24

teams, multiple meetings, but we

22:27

always make sure to record it, I

22:27

always make sure to post it out

22:30

there. In fact, she'll catch me

22:30

occasionally say, hey, did you

22:32

put it out there? Yeah. You

22:32

know, because that's their way

22:34

to catch up and see the things

22:34

that have been completed,

22:37

because they're not necessarily

22:37

everyday and stand up, or, you

22:40

know, in every planning or so

22:40

that way they can catch up. And

22:43

it gives them an overview,

22:43

especially of the end-user

22:47

facing that might affect the

22:47

online help or the release

22:50

notes. Yeah. So I know, that's a

22:50

really big one, I think, for

22:53

them to make sure we have that

22:53

recorded and ready for them.

22:56

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

22:58

make that? So?

23:01

Oh, absolutely.

23:02

I think that's all good stuff. And that's how the process is for me

23:03

as well. It's very similar,

23:06

because I am assigned to

23:06

multiple teams. So I'm not able

23:10

to be there for everything. And

23:10

our process sort of is very

23:14

similar to with the process that

23:14

you have. And we have leaders

23:16

that advocate for us and have

23:16

bought into the process. So it

23:20

sounds like a good, great place

23:20

to be at.

23:22

Yeah, I think

23:22

no, it is it's a thing for this

23:24

role. Especially I mean,

23:24

honestly, just in my over the

23:28

years, I feel like places were

23:28

taking documentation for

23:32

granted. For lack of a better

23:32

description, I feel like it's

23:35

been more kind of pushed off to

23:35

the side or was and I feel like

23:38

we're kind of coming back around. Again, it's kind of cyclical, and but we've been

23:40

very fortunate here that that

23:42

they have always really valued it. And we've had this department and we've kept it and

23:44

they realize the value. So I

23:48

think that's huge.

23:49

Yeah, I mean, like you said, you know, there are companies, there are

23:51

many companies that I have heard

23:54

of and been part of where

23:54

documentation is on the

23:58

sidelines, and sometimes non

23:58

existential. Yep. And the

24:02

writers have to really, really

24:02

advocate for themselves, and

24:05

then even then the needle

24:05

doesn't move much on it. Yes.

24:08

And that really has sort of been

24:08

an impetus for me, to sort of

24:12

surface, we are really hidden.

24:12

If you're not visible, how do we

24:16

become visible? And what is it

24:16

that we do on a day-to-day

24:19

basis, like you said, you

24:19

mentioned, writers catch stuff,

24:22

and that has happened so often

24:22

when we end up testing, or even

24:27

I will share this, the company

24:27

that I work at right now

24:29

sometimes we are part of the

24:29

discovery process. And I get to

24:33

sit in on it. The product

24:33

managers invite us and where we

24:36

are getting the opportunity to

24:36

directly engage with our

24:39

customers. So we end up

24:39

wondering, yeah, I know this is

24:43

not possible at every company.

24:43

But let's say at your company,

24:47

your product manager is

24:47

interacting with customers. But

24:51

because the relationship is

24:51

there for the writers, they have

24:53

that access to the product

24:53

manager. They sort of get that

24:57

firsthand information directly

24:57

from the Product Manager. This

24:59

is what the customer wants, this

24:59

is what the terminology may be.

25:02

This is what the use case may

25:02

be, this is what it's going to

25:04

look like. So there is you're

25:04

sort of closer to the customer

25:07

more than as it should be. So

25:07

looks like your process, even

25:11

though I'm guessing writers

25:11

probably do not sit in on

25:14

Discovery, right? Yeah, yeah.

25:14

But it has given me so many

25:18

opportunities where I have

25:18

gotten to ask questions directly

25:22

to the customer and get some

25:22

direction. And if we've had

25:26

inconsistencies with terminology

25:26

or disagreements there, there

25:29

are a lot of benefits and this

25:29

sort of, over the long term, it

25:33

ends up becoming so important,

25:33

because then content becomes

25:36

your ally, content becomes your

25:36

strength. So all good stuff,

25:40

Jennifer, so far, I think we've

25:40

covered quite a bit of your

25:43

content here. And as I'm

25:43

realizing we're almost close to

25:46

the hour, since we started

25:46

talking, and you were worried

25:49

about content, looking how much

25:49

content you provided me with. So

25:52

thank you for that. I think the

25:52

one question that comes to my

25:55

mind is, since you've been a

25:55

technical writer, and our Scrum

25:58

Master, are there any

25:58

suggestions you can share for

26:02

tech writers that are entering

26:02

the industry, on how they can

26:06

elevate their value or better

26:06

engage with the stakeholders?

26:09

Sure, I think a

26:09

lot of it goes back to some of

26:12

the things we've talked about as

26:12

being a member of, especially if

26:15

you're in Scrum, or even if you're doing Waterfall, just being a member of that team. And

26:17

speaking up for yourself

26:21

advocating for yourself. I mean,

26:21

obviously, we'd love for the

26:23

team members to do that I'm in

26:23

the unique position that they

26:26

do. But as we discussed a few

26:26

minutes ago, I don't know that

26:29

that's always the case at every

26:29

company. So I would say get in

26:31

there advocate for yourself,

26:31

kind of prove that value and

26:34

quality, point out the help or

26:34

the release notes or whatever

26:38

type of documentation you're

26:38

creating, and make it great and

26:42

make it valuable and people will

26:42

lean on it. That's what we've

26:45

found, like I think I mentioned

26:45

is that are some of our

26:47

stakeholders. Now, the first

26:47

thing I look for, so you do have

26:50

to advocate for yourself a little bit. But especially if you're in a process like Scrum,

26:52

you can easily say, hey, can we

26:56

make my piece a definition of

26:56

done? If it's not, it's possible

26:59

a lot of places don't have that

26:59

technical documentation as part

27:02

of the completion of a user

27:02

story or bug, but speak up, say,

27:05

hey, I think we should, you

27:05

know, suggest that that's part

27:07

of a team and working agreement,

27:07

and you know, all of those

27:10

pieces, and you're a team

27:10

member.

27:12

So fantastic. That is awesome. I think I completely agree with

27:12

you on that. I completely agree that if there is no process, you

27:14

want to embed yourself? Yes,

27:16

with that, within the

27:16

appropriate one, how to create

27:25

one exactly really advocate, and

27:25

advocating can happen in so many

27:28

ways, like you say in small ways

27:28

and big ways. So look for those

27:32

small opportunities to start

27:32

with. And if you already have

27:36

the lead on that, then try and

27:36

look for bigger opportunities

27:38

where you can really make an

27:38

impact. Mmm, yes, bringing

27:42

quality to the table, I think

27:42

makes a big, big difference. So

27:45

there is that onus on us to make

27:45

sure that the documentation that

27:48

we're creating is of quality. So

27:48

awesome, awesome pointers there.

27:53

I think this probably will be my

27:53

last question for the evening.

27:57

What are your takeaways or

27:57

highlights from interacting with

28:00

writers as a Scrum Master and

28:00

the content that the writers

28:04

create?

28:06

Well, it's been very rewarding. I mean, especially moving from that role

28:08

into this one and being able to

28:10

work together to make sure that

28:10

they are part of the process,

28:13

for them to be to want to be a

28:13

part of the process, and

28:16

actually really collaborate with

28:16

the team and see the interaction

28:19

between them. I think that's

28:19

been the best thing to see is it

28:23

again, it's, it's a team

28:23

atmosphere. And so it's not just

28:27

these though, you know, the QA

28:27

documentation, it's all one

28:30

group, including the PM,

28:30

including the Scrum Master. It's

28:33

been great from an Agile

28:33

perspective to see them embedded

28:36

with the teams and work as a,

28:36

like, I always call myself an

28:40

individual contributor. But the

28:40

more I worked on Scrum teams, I

28:44

feel like okay, no, I was just

28:44

part of the team. I was just

28:46

another, you know, I was just in

28:46

a, you know, and some people

28:48

think they're just a cog, a cog

28:48

in the wheel. But it's not even

28:51

that same deal where it's all

28:51

part of a process. And we've got

28:55

developers helping documentation

28:55

and documentation helping QA or

29:00

helping PMs, you know, or vice

29:00

versa. So it's really awesome to

29:03

see, I think that's been my

29:03

biggest takeaway is watching

29:05

them really grow into these

29:05

great collaborative team

29:08

members, you know, along with

29:08

the other the other folks, I say

29:11

all this, it's funny, because I

29:11

know this is a, we're a tech

29:13

writer-centric group, but with

29:13

this podcast, but it's like,

29:16

I've been very lucky to work

29:16

with great developers, testers,

29:19

documentation, product managers

29:19

across my career. So that makes

29:23

a huge difference to when you

29:23

have, you know, a great

29:25

collaborative team like this, right?

29:27

Absolutely.

29:27

I mean, as much as yes, this

29:29

podcast is focused on technical

29:29

communication, but we cannot

29:35

work in a silo. Right?

29:37

Exactly.

29:37

We need the support.

29:38

Absolutely.

29:39

And all

29:39

the members, all the actors that

29:42

you mentioned, are sort of our

29:42

biggest, you know, they're

29:45

cheering for us from the

29:45

sidelines, and they are the ones

29:47

that really us help us move

29:47

forward. Absolutely. We cannot

29:50

do this by ourselves. So it is

29:50

it's important that developers

29:53

and QA and UX are working with

29:53

us, and that partnership and

29:58

that collaboration is what helps

29:58

the team move forward, and to

30:01

delight the customers at the end

30:01

of the day. So, like you said,

30:05

I've been fortunate, and I hope

30:05

more writers entering the field,

30:09

have this positive experience.

30:09

And we also have to take some

30:13

responsibility to bring that

30:13

positivity. It's not all on

30:17

others. It's also on us to

30:17

absolutely to advocate for

30:20

ourselves. Because without that,

30:20

we cannot. If we are not

30:23

visible, then you're like you

30:23

said, we are sort of like a cog

30:27

in the wheel, as some people may

30:27

call it. And and we want to sort

30:30

of change the dynamics change

30:30

that perspective of us. So all

30:35

awesome pointers here, Jennifer,

30:35

I've really enjoyed having this

30:38

conversation with you. Lots of

30:38

good nuggets in there.

30:42

Yeah, there's

30:42

been a lot of fun just chatting

30:44

about it. I love talking about this.

30:46

Yes, me too.

30:47

Tech doc or

30:47

Scrum, or, uh, yeah, it's been

30:49

really enjoyable.

30:50

Yeah, it's been an enjoyable conversation. And thank you for

30:51

bringing this valuable

30:54

conversation to us. And to my

30:54

audience, we really appreciate

30:57

it. Is there anything that you

30:57

would like to add?

31:00

Yep, I think I think I'm good.

31:00

Awesome. Appreciate it.

31:04

Yeah. Thank you. I appreciate

31:04

it, too. I want to thank you,

31:07

and have a lovely evening, Jennifer, this has been fantastic.

31:11

Great talking

31:11

to you. Great talking to you to

31:14

Subscribe

31:14

to the podcast on your favorite

31:16

app, such as Apple, Google, or

31:16

Spotify. For the latest on my

31:21

show, follow me on LinkedIn,

31:21

Instagram, or visit us at www

31:28

dot inside tech comm dot show.

31:28

Catch you on another episode.