Note: I've also shared a full video version of this episode, where you can see me screen share everything I'm describing. You can find it here:

Documentation Episode - Full Video

I’m incredibly (absurdly? ridiculously?) enthusiastic about documentation.

Part of that is just my personality, but it’s also because I’ve seen what a game-changer good documentation can be.

This first hit home when I started consulting. It was incredibly stressful (in the very early days) to work on poorly documented projects. They were filled with assumptions, misunderstandings, client disappointment, and re-work.

We quickly improved our documentation game, and it was transformative. We now had a clear source of truth for what each project should be, approved by the client before we started building. It also created space to think things through in more detail.

However, each doc existed in isolation. We never had the mandate or scope to create a complete knowledge base for any one client.

Creating the Knowledge Base of My Dreams

When I started my next in-house job and we began a company-wide Confluence implementation, I finally had the chance to go beyond disconnected documentation and build a true RevOps knowledge base.

This video shares everything I’ve learned, including a screen-share walk-through of my team’s knowledge base and tips for overcoming the time deficit that every team faces when trying to create docs.

Learn More

Visit the RevOps FM Substack for our weekly newsletter:

Newsletter

Thanks to Our Sponsor

Many thanks to the sponsor of this episode - Knak.

If you don't know them (you should), Knak is an amazing email and landing page builder that integrates directly with your marketing automation platform.

You set the brand guidelines and then give your users a building experience that’s slick, modern and beautiful. When they’re done, everything goes to your MAP at the push of a button.

What's more, it supports global teams, approval workflows, and it’s got your integrations. Click the link below to get a special offer just for my listeners.

Try Knak

Justin Norris: 00:00:06

For many revenue operations teams, documentation is like

2

: 00:00:09

a guilty skeleton hiding in the closet.

3

: 00:00:12

We all know when something

isn't well-documented - oh,

4

: 00:00:15

we know it all too well.

5

: 00:00:17

But in a world filled with fire-fighting,

bug-chasing, and 37 top priority campaigns

6

: 00:00:22

with last minute deadlines, finding

the time and mental clarity to document

7

: 00:00:27

stuff seems like a distant priority.

8

: 00:00:29

And so all the undocumented things

remain, put off again for another day...

9

: 00:00:42

Well, listen, I can't find you more

time in the day but I do know that

10

: 00:00:46

documentation becomes way easier

when you have two things established.

11

: 00:00:51

Number one, a clear knowledge

base where documentation can live.

12

: 00:00:54

Number two, you need a process

that removes friction from creating

13

: 00:00:57

documentation, making it easier to get it

done in the flow of work, so it doesn't

14

: 00:01:01

end up permanently in the backlog.

15

: 00:01:04

I don't claim to have everything

figured out, but I wanted to

16

: 00:01:07

show you how we do it on my team.

17

: 00:01:09

The first thing is you need some platform

for the knowledge base to live in.

18

: 00:01:14

We use Confluence, and I like it a lot.

19

: 00:01:16

It's easy to create pages, keep

them consistent and organized, to

20

: 00:01:19

track version history, collaborate,

control access, and so on.

21

: 00:01:23

But there are other tools out

there that will do similar things.

22

: 00:01:25

Fundamentally, I think you just

need something that gives you

23

: 00:01:28

the ability to easily create

these webpages and organize them.

24

: 00:01:32

This means that you don't want to

use disconnected Google docs that

25

: 00:01:35

are hard to navigate and reference.

26

: 00:01:37

Don't get me wrong.

27

: 00:01:38

Docs are great for building.

28

: 00:01:39

I just don't think that it scales

in creating an interconnected

29

: 00:01:43

and evergreen body of knowledge.

30

: 00:01:45

This is our marketing ops

homepage in confluence.

31

: 00:01:48

It gives an overview of our

team and some quick links.

32

: 00:01:51

And underneath you can find all our

docs - about 100 pages and counting.

33

: 00:01:56

One of these is our documentation

guide, which is basically the

34

: 00:01:59

documentation for our documentation.

35

: 00:02:01

So I'm going to look at that as it

helps explain how everything works.

36

: 00:02:05

One of the main distinctions

we make is between our system

37

: 00:02:08

of knowledge - Confluence - and

our system of work - Trello.

38

: 00:02:12

The docs we put in the knowledge base

should be evergreen and a reference.

39

: 00:02:16

The ongoing work and communication takes

place in our project management system.

40

: 00:02:21

This keeps the evergreen

docs clean and easy to read.

41

: 00:02:24

So let's say you have a tool and you're

ready to create a knowledge base.

42

: 00:02:28

Where do you start?

43

: 00:02:29

Well, I think it's super important to

have a clear information architecture.

44

: 00:02:33

This architecture defines the

different types of docs you have and

45

: 00:02:37

creates an order and structure that's

easy to navigate and to build in.

46

: 00:02:41

Our docs are structured

into five main sections.

47

: 00:02:44

About Us is primarily for

other teams at the company.

48

: 00:02:47

It gives a general guide for how we work

and links to important info like our OKRs.

49

: 00:02:53

Next we have Process Docs which explain

how we execute our marketing ops

50

: 00:02:57

internal or cross-functional processes.

51

: 00:03:00

How do we know what to make a process for?

52

: 00:03:02

I say that any repeated activity

needs a process, and any process

53

: 00:03:06

should be documented here.

54

: 00:03:08

For example, here's a doc for our trade

show list upload and follow-up process.

55

: 00:03:12

We have the process itself defined in

Google slides embedded on the page.

56

: 00:03:16

That's okay.

57

: 00:03:17

The main thing is that the

knowledge base provides context

58

: 00:03:20

and easy way to access it.

59

: 00:03:23

Our tools and platform docs are a

catalog of all the tools in our stack.

60

: 00:03:27

We don't go deep into systems

architecture or enablement here.

61

: 00:03:30

It's just a simple page that specifies

what the tool is, the MOPS owner,

62

: 00:03:34

the vendor points of contact, and

how to log in or provision users.

63

: 00:03:39

This gives a lot of

clarity around questions.

64

: 00:03:41

Like, do we use tool XYZ?

65

: 00:03:43

Or what tool do we have for ABC use case?

66

: 00:03:46

Stuff like that.

67

: 00:03:48

Enablement docs are mainly focused

on users outside of marketing ops.

68

: 00:03:52

These are our "how to" docs.

69

: 00:03:54

We mainly have these organized by tool.

70

: 00:03:57

So, for example, in the Marketo section,

we have guides and training on our

71

: 00:04:00

email templates, how to localize our

headers and footers for our different

72

: 00:04:04

markets, how to build smart lists

to create an audience, and so forth.

73

: 00:04:09

I think of these docs as answers

to frequently asked questions.

74

: 00:04:13

Creating these will have a very high

ROI when you can answer questions by

75

: 00:04:16

sharing a link to your docs, instead of

repeating the same answer multiple times.

76

: 00:04:21

And let's face it, we don't have

everything memorized either.

77

: 00:04:25

So these docs are also

valuable for operators.

78

: 00:04:27

I refer to my own docs constantly.

79

: 00:04:31

Lastly, we have system docs.

80

: 00:04:33

These are documents for significant

operational systems that our

81

: 00:04:36

team builds and supports.

82

: 00:04:38

For example, our lead flow,

lead life cycle, routing, email

83

: 00:04:42

preference center, and so on.

84

: 00:04:44

It's important to note that these

systems can involve multiple platforms.

85

: 00:04:48

For example, our lead routing system

involves Marketo Salesforce, our routing

86

: 00:04:52

tool, Distribution Engine, multiple

enrichment providers, and so on.

87

: 00:04:57

These are essentially internal

products that deliver specific

88

: 00:05:00

functionality to the business.

89

: 00:05:02

Let's look at our lead routing docs.

90

: 00:05:04

These systems can be really complicated.

91

: 00:05:06

So it's important to break up the docs to

create bit-sized pieces of knowledge that

92

: 00:05:10

can be accessible to different audiences.

93

: 00:05:13

Here, we start with some general

information about why routing

94

: 00:05:16

is important and a high level

overview of a leads journey.

95

: 00:05:19

Then we have dedicated pages

that are sources of truth for

96

: 00:05:22

core business definitions.

97

: 00:05:24

For example, our geographical

territories are different

98

: 00:05:27

routing scenarios or our SLAs.

99

: 00:05:30

By separating this knowledge out, it

makes it really easy to send a page

100

: 00:05:33

about our territory definitions to a

business user without making them go

101

: 00:05:37

through a bunch of technical detail

that they just aren't interested in.

102

: 00:05:41

But those technical

details are very important.

103

: 00:05:44

The litmus test we use for documentation

is: if our entire team disappeared

104

: 00:05:48

tomorrow and had to be replaced, would

the new team be able to take over

105

: 00:05:52

seamlessly and know how everything works?

106

: 00:05:55

This sets a pretty high standard, but it's

really important to have that clarity.

107

: 00:05:59

Otherwise systems become

impossible to manage and scale.

108

: 00:06:02

We forget why we have things set up in

certain ways, and it creates a lot more

109

: 00:06:05

risk of stepping on rakes by making

changes and accidentally breaking things.

110

: 00:06:10

So the technical details cover all the

system design and configuration elements.

111

: 00:06:15

These pages are geared towards technical

users and other ops professionals.

112

: 00:06:20

In writing the documentation itself,

aim for clear and simple language and

113

: 00:06:24

an organized and appealing layout.

114

: 00:06:26

This makes it easy to

understand and to maintain.

115

: 00:06:29

Formatting is super important here.

116

: 00:06:31

Things like headings, bulleted

lists, data tables, or embedding

117

: 00:06:34

a spreadsheet where you have more

rules than can clearly fit on a page.

118

: 00:06:38

I just want to close now with some

information about the process for

119

: 00:06:41

creating documentation and how to

remove friction and make it easier.

120

: 00:06:46

First of all, don't let yourself

get overwhelmed if you're deep in

121

: 00:06:49

documentation debt, meaning you've got

a lot of stuff that's undocumented.

122

: 00:06:53

Docs are never finished

and are always changing.

123

: 00:06:56

Get your structure in place

and then just start somewhere.

124

: 00:07:00

Also make sure you don't let the

desire for perfect documentation be

125

: 00:07:03

a blocker for creating something.

126

: 00:07:05

Get a starting point in place that

captures the basics and then you can

127

: 00:07:08

always go back and improve on it.

128

: 00:07:10

The other main blocker for creating

documentation is finding time,

129

: 00:07:13

but that gets a lot easier if you

can create docs in the flow of

130

: 00:07:16

work that you'll already be doing.

131

: 00:07:18

For example, if someone asks a question

and that knowledge is important,

132

: 00:07:21

probably takes only a few minutes

longer to create a doc versus simply

133

: 00:07:24

writing an email or a Slack message.

134

: 00:07:26

So invest the extra few minutes

each time, and your knowledge

135

: 00:07:29

base is going to grow quickly.

136

: 00:07:32

Another key factor is to make the

documentation part of the design and

137

: 00:07:35

enablement stages for any new initiatives.

138

: 00:07:38

This means you document as you

go, or very soon after you build

139

: 00:07:41

something, and don't consider a project

complete, unless it's documented.

140

: 00:07:45

You can also be opportunistic

with documenting legacy systems.

141

: 00:07:49

Let's say, you need to make

a change in your lead scoring

142

: 00:07:51

model and want to document it.

143

: 00:07:53

While you're in that head space,

you can also document the model as a

144

: 00:07:56

whole because the big picture is clear

and sharp for you at that moment.

145

: 00:08:00

Lastly, if there are some important

docs that just need to be tackled, you

146

: 00:08:03

can organize a documentation blitz with

your team to make sure it gets done.

147

: 00:08:07

Just like a call blitz and a sales team,

this is a time where everyone can block

148

: 00:08:11

an hour or two on their calendar, pick

an important topic, and just go for it.

149

: 00:08:15

This creates momentum and

accountability, and you'll find

150

: 00:08:19

a lot gets done in a short time.

151

: 00:08:21

One final note: documentation shouldn't

live only in your knowledge base.

152

: 00:08:26

Sometimes the most valuable documentation

exists inside the platforms themselves

153

: 00:08:31

where users are already working.

154

: 00:08:33

I think as a general policy

system description should always

155

: 00:08:36

be populated with a brief note.

156

: 00:08:38

That adds context and

clarity for the user.

157

: 00:08:41

You can then add a link to either a

task request or a more substantive

158

: 00:08:44

documentation for the user to learn more.

159

: 00:08:46

These description fields are also a great

place for change logs that help note

160

: 00:08:50

significant updates that have been made.

161

: 00:08:52

Well, I think you can see that I'm

probably unusually passionate about

162

: 00:08:56

documentation and knowledge management.

163

: 00:08:58

But whether you love

it or find it a chore,

164

: 00:09:00

the key thing to remember is that

a knowledge base is not a luxury

165

: 00:09:03

or just a matter of hygiene.

166

: 00:09:05

It's mission critical.

167

: 00:09:07

You simply can't grow an ops team

based on tribal knowledge . It's going

168

: 00:09:10

to lead to chaos and frustration.

169

: 00:09:13

It's also an unacceptable risk for

any growth stage business to rely

170

: 00:09:16

on knowledge in someone's head

just "being there" when needed.

171

: 00:09:20

So when in doubt, write it down.

172

: 00:09:23

Thanks for listening.