NoCodeOps: From Chaos To Clarity: Documentation for RevOps

What is documentation?

So, to get us all on the same page, get us aligned, our favorite RevOps word or goal of alignment, I like to say:

Documentation is recording who, what, where, when, why, and how to do everything in your company or role. 

And storing that information in one place where other people can find it and use it. 

The storing part is often called knowledge management, but we’re not getting into those semantic differences today. We're keeping it simple, using human-friendly language.

Basically, documentation is any recorded information.

Information that is not only located in someone’s head. 

If you need to have a meeting in order to get access to the information you need (by verbal communication), then that info is probably not documented, or the knowledge holder missed the “sharing” step.

Documentation is sometimes referred to as Standard Operating Procedures (SOPs), Business handbooks or manuals, process playbooks…

The words process and procedures can be intimidating, especially to non-operations people when you’re trying to get other teams on board with documenting.

Let’s make it more relatable and easy to understand. 

Documentation is content. Helpful content!

Documentation is knowledge sharing!

It is eliminating knowledge gaps and knowledge silos.

Documentation also doesn’t have to be written if you hate writing.

It can be in video format to start with. It can start with a fancy tool to create step-by-step GIFs.

Start with the format easiest for you to actually do. So you actually start.

Something is better than nothing! I’ll repeat that advice later.

Moving on...

Here’s a visual example of documentation – a knowledge base article from GitLab. Many of you may know GitLab is one of the original champions of documentation and open source, open access to company information for everyone. 

Thank you, Debbie, for the kind words!

Here’s another example of a visual of a document format.

If you don’t have a fancy knowledge base, that is fine! 

Start with the writing or content storage tool that is easiest for you, and start with what you already have.

The above template is given in my classes in a Google Doc, but you can copy this template into whatever storage tool/knowledge base you’re using.

In case you’re thinking, this is NoCodeOps, so if I’m not documenting code, what am I documenting?

Here are some examples of what you might document at your company, some of the processes I documented at the agency.

Or maybe if you’re thinking, I can see all the steps in the little boxes in my workflow software, is that documentation?

Not exactly.

Does it show why each step is there? 

Can everyone who is affected by the process log in and see the process in the workflow automation software, and do they know how to interpret it? 

Does the workflow software show how it's related to or interacts with other automation, or interacts and affects larger processes, or the parts of the process that are not automated?

Probably not, or not in a way the non-technical people on the team, such as some leaders, can interpret.

My point here is that you’ll still need documentation of the more human elements of the work

Why is documentation essential for RevOps?

I like Claudia’s description of this event, which said: Documentation is the glue that holds revenue operations teams together.

Here are a few reasons why documentation is essential for RevOps:

• RevOps works with more departments at the same time, which means:
  • Cross-functional processes are more complex, and people need documentation to understand them
  • Handoffs between departments are a common area of friction to improve, and you need documentation for all sides to understand
  • Changes and errors affect more people upstream and downstream in RevOps work
    • CHANGE MANAGEMENT is a bigger part of RevOps roles compared to other roles in the company, and documentation helps change management
• RevOps is often responsible for training/enabling more new and existing team members on the changes and processes, and documentation helps there
• RevOps receives more questions and requests from more departments – this gets its own bullet point since it is a big time suck in RevOps, people in the company asking for every shiny new thing they saw someone mention online
  • It is harder to protect strategic work against new requests from many departments, and documentation can help reduce requests/questions, and prevent those fires from happening
  • Fighting fires and answering the same questions all day leaves no brain power for interesting or impactful work
  • This type of work can be very stressful when relying on memory for every task, and documentation can help reduce that stress

• So many people misunderstand what RevOps is responsible for
  • Related to the previous point, people misunderstand RevOps as an internal support department or ticket desk
  • Showing the documentation of what you actually do can help solve this issue

•  RevOps helps the company move faster, more efficiently, and effectively. These are some of the major responsibilities of RevOps.
  • You can scale with confidence using documentation, if everyone’s not guessing and remembering what is supposed to happen, or interpreting what's happening differently

Claudia added that your future self is going to thank you. They were discussing this topic today during a RevOps and GTM (go-to-market) roundtable ... sometimes RevOps could be really hands-on technical, building those processes and those systems. If you're building a process, you know that things might break, things might evolve, and they might change. So you need to have good documentation on why you built certain processes, so your future self can thank you.

Efficiency 

Doing more with less is talked about a lot these days, especially as something RevOps can help with.

Some of the ways documentation helps create and  improve efficiency are:

• Easily completing work quickly - people don't need to search everywhere or wait for information 
  • As Spekit explains, information chaos means lost time; employees waste 3-11 hours a week on average searching for knowledge and communications
• Delegating more easily without you being the bottleneck when people have questions
  • Including delegating work to AI 
  • The AI can pull answers from the documentation, so fewer people have to ask YOU that question and wait for an answer, saving both sides time
    
    
• Repeating work easily. Not needing to remember, which takes more time. 
• Not making mistakes, so you’re spending less time fixing errors 
• Helping you onboard new employees efficiently, to increase revenue faster
  • Not just RevOps employees, but all the revenue teams’ employees, since you’re likely the person/department who is project managing their documentation as well

• Documentation enables you to see, agree on, and improve processes, making the processes themselves more effective and efficient 
  • Including knowing what to automate, agreeing with people on the steps of the process and seeing where automation can be used to improve it
    
    
• Documenting makes iterating and experimenting more efficient - documenting what worked and didn’t, and why
  
  
• The human side of efficiency: documentation helps you feel supported and confident in your role, so you do not second guess everything or wait for answers, helping work be completed faster with LESS STRESS

I wanted to highlight this quote from ZAPLAB MASTER Claudia in the New Year, Smarter Ops livestream this year. Claudia is talking about the importance of showing your work, current and future state, documenting to gain a deeper understanding, explaining what you are doing, and showing your value.

Claudia compares this to verbally explaining, or not explaining at all, the pitfalls of heads-down working with no leadership visibility of your efforts.

Documenting helps with getting easier approvals and gathering more information to make sure your work is successful.

Live, Claudia said she has been obsessed with process mapping, and the community knows that's so crucial to start mapping your processes, even before you start approaching your build. It's such a change in your mindset. It's such a shift, and that's where the magic really happens. That's when you scale, when you have good documentation and good process mapping. That's when you can go to your stakeholders and say, "Hey, this is how we're going to go from zero to hero," Claudia said.

I interviewed Melissa McCready for a book I’m almost finished with, finally, and the above quote is what she said on this topic.

In the 35 expert RevOps research interviews I did, I asked if they considered process strategy and documentation as part of RevOps. 

No one said no. 

There were a few caveats about how RevOps doesn’t own those topics for the entire company, but the topics are a huge part of RevOps jobs. One expert even called this dynamic duo “the foundation of RevOps,” since both topics are needed in order to scale -- to hire quickly and onboard new customers quickly.

So it’s not just my experience and my knowledge, I'm sharing other people’s thoughts today.

What happens when no one takes responsibility for documenting?

(This slide was cut for timing but added back into the blog content.)

I would guess we’ve all experienced this since so few companies encourage documentation.

At this point in the presentation, you may be tired of hearing just from me, so I’m including the expertise of a few other people I interviewed for my book research.

Here’s what Mike Rizzo says about what happens when people leave the company and you lose all that knowledge, so the next person has to recreate the wheel to start from scratch:

Julia has an interesting yet morbid analogy of documentation as knowing where the bodies are buried. :) This sounds like a RevOps revenge plot!

Julia also describes the benefits of not having to talk to 100 people about a process who all give you different answers or say 'I don’t know,' if you have documentation.

Questions on the ‘what’ and ‘why’

How to identify core documentation needs

What are the most important RevOps processes to document?

What do you think?

The best answer is: it depends.  This is a classic consulting answer, especially since RevOps still looks different at every company.

But here are a few examples of RevOps processes to document:

• How leads are created and enriched
• How leads are nurtured (segmentation, ideal customer profile, events, campaigns ...)
• What is the marketing - sales handoff (service level agreements)
• How each sales call/touchpoint works
• How to receive and process payments (sales-finance handoff)
• What is the sales-customer success handoff
• How to onboard new customers
• How renewals, upsells, and cancellations work
• How reports are created, delivered, and accessed
• How to forecast, plan, and budget
• How data is maintained (hygiene/governance)
• How to research and hire vendors (agencies, software, etc.)
• Change processes (requesting changes, approval, communicating…)
• How to create and maintain documentation
• How to manage and view projects

These are broad. You’d probably break a lot of these out into more specific articles/processes, especially if you’re just starting with your own documentation for just your role.

These examples may ‘belong’ to the revenue teams, but in RevOps, you need to know how they work so you can improve them, fix problems, enable people to do these jobs better, and similar responsibilities. And those teams probably haven’t documented the processes, you might have to take the lead in that effort.

How to determine what to document first

If you’re just starting documentation in this role at this company or your first documentation ever, should you start with the most important process?

My answer to this question would be no, or not usually.

The most important process is probably too big, involves too many people to talk to to figure out one consistent process, and will put too much pressure on you for your first piece of documentation.
You likely will give up on and not complete this as an impossible task.

Instead, you’re going to want some quick wins first for motivation.

So, if you don’t usually start your documentation initiative with the most important process, where do you start?

I’d like you to think about: what has been stopping you?

Why haven’t you been working on documentation?

What is your roadblock?

Time is the most common answer and maybe what first pops into your mind.

But let’s dig deeper and identify the reason causing you to feel you don’t have time.

The biggest reason is usually overwhelm.

• It will take too much time to start, deciding where to start, and then the time to keep doing it forever

Another reason is if you’re worried about team adoption.

• You may think it won’t be worth the time if people don’t use it or maintain it

Or perhaps you’re worried about getting leadership buy-in.

• Your current leaders won’t allow their team time to complete it, or spend time to champion its use, or hold people accountable to using it

To help simplify where to start your documentation journey, I have 3 suggestions based on three common roadblocks:

For overwhelm: start small with one of your own tasks you repeat often.

I suggest your own tasks or processes so you don’t have to investigate and interview other people, which adds complexity and stress and delays getting it done.

For fear of other people not adopting documentation: start with a process, person, or team where it is the most likely to be adopted. You likely know who will and will not like documentation. Don't make it hard on yourself by choosing people you know will resist it as your test group or pilot group, even if that seems like the most ‘important’ process to document (sales).

If you have a fear about not getting leadership support on teams creating and using documentation: start with documenting a process related to current business goals, one that you can measure the before and after metrics, to show the improvement resulting from documenting the process when you test or pilot this new process of documentation.

Most importantly, don’t overthink it!

Start taking action. If you're not sure what your roadblock is, start small, choose that one! If you're overwhelmed at which roadblock is true, or all of them are true, choose the overwhelm advice to start.

I have a blog and other free webinar to expand on this topic and help with documentation procrastination. We all do it. You are not alone in this struggle!

What should be included in good documentation?

Here are some of the things I recommend you consider including in helpful documentation

• Table of contents - efficiency! No need to scroll
• Last Updated 
• Who Updated
• Owner of article/category
• Audience
• Time the process takes
• If there is another process that you think the user may be looking for instead of this one, something commonly confused, link it up top.
• History or Context

• Process Steps 

• If there is another process or task that occurs immediately before/ after what is described here, link it at the top or bottom of the steps section.
• Related Article(s) or Resources

I’m talking a lot about writing text when there are other ways to document, which we mentioned earlier.

I often suggest starting with text/writing the process because it can be easier and more accessible for more people in the company to do that, not just ops people who might have fancy flowchart mapping software.

Editing text is easier than video editing or flowchart editing for a greater number of people.

No special software or skills are required.

Text can also be easier and faster for translation for other languages on global teams.

This practice helps with increasing adoption in creating documentation, so it is not just you making everyone’s documents.

BUT – Start with the format easiest for you, so you actually start.

• Record yourself in audio or video and transcribe it, in any tools.
• Use AI to start a draft or edit your transcription mess
• Use a fancy tool that records what your mouse is doing on screen 

If you use those methods to start, then make sure you have humans checking and adding context to the above methods. Manually add the human elements that can’t be extracted from your brain, more than just what’s happening in software, or where people are clicking.

Including visuals and multimedia in documentation

I also recommend having visuals or multimedia in your documentation.

• Flowcharts, process maps can be added to documentation
• Videos, Looms, and other software walkthroughs
• Images, screenshots
• GIFs from tools 
• The funny type of GIF, meme, if humor is part of your culture, breaks up the text
• Audio files
• Charts and Graphs
• Infographics
• Slides (embedded)
• Images
• Emojis - such as replacing bullet points with emojis. 

Don’t get scared by this giant list of possibilities! You’re not doing all of this at once, you can add more formats later after getting started in one format.

How to promote internal adoption and buy-in across teams

How can you encourage the adoption and usage of documentation?

Debbie had a great answer to this question: put your documentation in the air like you just don't care!

It can be discouraging, not motivating, if all your beautiful and hard work documenting doesn’t get used.

How do you encourage people to use it and to document themselves?

To encourage the adoption of documentation, you want to start building a culture of documentation.

A culture of transparent communication.

Building a culture requires a human touch.

Though documentation isn’t always writing, it is recording information in some format. This LinkedIn post from Wes Kao is very relevant for creating a culture. 

More specifics for building this culture that will help with adoption:

• Start small - with one person or team or topic at a time, test or pilot group
  • Setting up communication channel(s) about documentation
    • Use that channel to explain the benefits of documentation, how you want to encourage knowledge sharing and learning, benefit from efficiency, improve processes, how it helps them – create a desire to change (change management)
• Emphasize benefits such as transparent communication, equal access to information
• Behavior modeling so people can see other people doing/using documentation
• Remind people to do it and that it exists to help them, personally and through automation

You should bring your team along on the journey, like Penny Penati said in a recent livestream here. You’re working in public on documentation, communicating why, the benefits seen from it, and normalizing it.

You want to bake documentation into many aspects of work. Normalize it.

Documentation and transparent communication are not normal, average behaviors at companies. 

People are not used to it. 

So make them aware there is a better way to work, and create a desire to change.

More ways to normalize it:

• Teach new employees in onboarding 
• Add it into all trainings for all teams 
• Add it into project management and other daily work
• Celebrate and reward people who do it
• Make it easy for people – create a system to make it efficient

• • Document the system, test it, improve it, then roll it out and train everyone on it. Go through the culture and change management steps on the previous slide.

A documentation system

What I mean by system is not just one piece of software where you store the documents.

I mean the people and processes, and also the many different tools you use the build this culture.

The common components of that system:

• Time management - reserving time to do it - time can be the biggest roadblock or objection
• Task/project management - knowing what to do and when
• Communication methods - change management
• Storage and organization - where does it live?