Thank you to Claudia Cafeo for inviting me to the NoCodeOps community livestream show to discuss documentation in RevOps. We've been trying to make this event happen for over a year since this live show happens the same day and time I teach RevOps bootcamp half of the weeks in the year, so thank you to Claudia for your persistence!
NoCodeOps, now owned by Zapier, is a global community dedicated to empowering operations professionals through no-code automation tools and strategies.
|
The show covers these topics (which link down to that section of the blog): |
It's the topic that quietly powers everything else
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
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:
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.
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:
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.
(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.
Claudia and I had way too much fun talking about documentation!
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:
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.
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.
Another reason is if you’re worried about team adoption.
Or perhaps you’re worried about getting leadership buy-in.
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!
Here are some of the things I recommend you consider including in helpful documentation
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.
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.
I also recommend having visuals or multimedia in your documentation.
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 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:
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:
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:
Assign roles - spreading out responsibilities, bringing the team along
We don’t have time to get into each of these today, this slide is an entire class by itself, but I’ll link some blogs and other resources in the resource section, you can dive into if you wish.
To make that concept easier to understand, here’s a system example of what I used at the agency where I last worked.
Time management - Recurring calendar blocking with pop-up or Slack/email notifications
Task management - Teamwork for current priority tasks and recurring quarterly maintenance updates, adding document links in task templates, and more. Google Doc for wishlist of non-priority future documentation.
Communication - Slack channels for real-time updates and communication, copied into weekly internal newsletter on Fridays, and Weekly team meeting agendas on Mondays
Storage/organization; HubSpot Knowledge Base. Use something your team uses every day (or a tool that integrates into your team’s home base). We were a HubSpot agency, so our team should be in HubSpot every day, and needed to learn about this feature to teach it to clients, for multiple reasons
Roles: Users, Creators, Editors, Approvers, Knowledge Owners – some people have more than 1 role, especially at small teams like an agency. Everyone might be a user or editor for minor edits but only a few people might be creators, approvers, or knowledge owners responsible for an entire category of documentation like retainer processes for client services, sales processes for the sales manager
This is some of the change management we talked about in the culture slides.
(These were cut from the presentation due to time.)
Related resources:
Claudia talked about documenting roadblocks and the current state first, then using that to raise awareness.
There was a question about dynamic RPA tools that help better generate flowcharts where team member names can be dynamically updated.
Thanks again to Claudia for inviting me to chat on the NoCodeOps Community live stream!