Thank you to Mark Lerner for inviting me to the RevAmp podcast to talk about the importance of documentation in revenue operations.
The show covers these topics (which link down to that section of the blog):
Listen to the podcast below, find the entire transcript here, or keep reading!
How I got into the world of revenue operations and met Mark
- After finishing my MBA in order to change careers into marketing and business. I got a job with Nicole Pereira at her previous agency, Remotish. I started as one of the first employees, doing mostly marketing and marketing tech at the beginning.
- After growing the team, we realized we were really doing revenue operations, as that term became more popular, helping more teams than just marketing teams.
- As I advanced from that first job to serving clients, to managing the client servicing team, to being the operations manager of the company, our agency got more and more into RevOps.
- I started researching RevOps more because all the information online was contradicting itself. I decided to structure that research of interviewing people as a book, which I’m finally finishing this year. Writing a book is a life goal, so it seemed like a good opportunity to combine goals and interests.
- Mark remembered that's when we first got in touch. He was at a previous company in the same space and curated a daily newsletter which was very helpful. I was an early subscriber, and Mark reached out.
- After we recorded this podcast, we also met in person at RevOps Co-op's RevOpsAF conference in San Diego!
What is documentation, and why or how did I get interested in it?
- Documentation is recording who, why, and how to do everything in your company or your role. And then storing that information in one place where everyone can find it. (The knowledge management side -- you can’t really do one well without the other.)
- Information that’s not only located in someone’s head -- if you need to have a meeting to extract that information from someone, it’s probably not documented or not shared.
- I was doing documentation throughout my creative careers in graphic design and photography. I was often the first person hired into a role, and so my job was being split off from my boss’s job. When I left, I wanted to document so I could train the next person and my boss wouldn’t have to take on all that work again.
- I got really into documentation at Remotish because I knew that we were going to hire and train people to do what I was currently doing. Also so we could easily improve the processes and make them efficient as we gained more clients.
What are the primary benefits of a thorough documentation process within a RevOps role and across the company?
- Having context for the past, because if you’re going to make changes, you need to know what you are changing and what that is going to affect upstream or downstream
- Also for efficiency, another big goal in ops, doing more with less. You don’t want to make the same mistakes that you made last time or mistakes that someone else already made. Having it documented helps you prevent that.
- You can’t scale or grow without documentation -- for training in general, or if people leave, you have to start their training and processes from scratch without documentation.
- You can’t make predictable, repeatable processes or forecast anything accurately if everyone’s doing work differently and if it’s not consistent.
- You can’t improve anything if you don’t know what’s going on.
Here's a clip of this segment:
What do you think is the driving force of that increase in the need for change and adaptability?
- The economy is a big factor right now. It's changing the way companies get investments. It's harder to get new investments and to get a return on investment now, from what I've read, though I'm not an expert here. This makes companies panic and try all kinds of different things, making many changes at the same time. This is not great because if you’re changing everything instead of having one variable changing, it’s really hard to tell what is actually working.
- Mark said the way companies are being measured by the market or by venture capital is no longer the 'growth at all cost' model, but efficient, scalable growth. It's no longer focused on net new acquisition but on lower churn and an increase the customer lifetime value.
In this rapidly evolving environment for go-to-market teams, how do documentation and good documentation support that ability to make those changes? And what are the negatives of not having good and thorough documentation in that kind of environment?
- Documentation helps with those changes because you can see what was done in the past if you have that documentation: what worked, what didn’t work, why it didn’t work, and why it might work now. This could help you discuss with the leaders who are requesting constant changes like, 'Hey, we already tried this, and this was the outcome. Are you sure you want to do it again?' Maybe the leader is new and wasn't aware it was tried before since there’s so much employee churn right now. If you have good documentation, everyone will have the information to see if that tactic or strategy may work now, may still not work, or may be worth the time and money to try,
- Documentation gives you repeatable processes, making work easier and efficient. You don’t have to think about those established processes. You can spend all your brainpower and time on new work, or on processes that you want to change instead of spending that concentration power on day-to-day recurring work.
- Without documentation, people are going to get burnt out because they’re going to be doing things that have already been done that didn’t work before. They’ll make errors that could be prevented by documentation. People may also feel like they can’t take any time off, which is going to contribute to more burnout because no one else can do their job if there’s no documentation.
Where do you start documentation? How do you change the way you think about it?
- Changing the way you think about it would be thinking of it as living documentation, always improving, not static. It doesn't need to be perfect on the first draft; any amount of semi-accurate documentation is going to be helpful, especially if you’re just getting into the habit of creating documentation.
- My first class of the documentation course is just about prioritizing where to start. People may be overwhelmed, or they don’t think anyone’s going to use it, or they can’t get leadership buy-in. I advise people just to start small and start with their own tasks. Start building that muscle of doing/improving documentation on a daily basis.
- Then get peer input about whether this documentation draft is useful. Don’t write a document for weeks before getting input from someone else. Is it clear? Does it need to be longer? Does it need to be shorter? Treat it like a continuous improvement project.
How do you take the next step after you've gotten started in documentation?
- After starting writing documentation, you can create a template that works for you, and then also create a system to keep doing it and keep updating it.
- That system includes communication methods such as a Slack channel with a name that people might pay attention to (not 'documentation'). Send messages in that channel, not about just the documentation itself, but the benefits that you’re seeing starting to see when you're completing and using documentation, to get that communication flowing.
- Put the documentation tasks into a project management system so you keep doing it, and other people can see what’s happening and what’s going to be documented.
- Don’t start with tool research; that’s really just procrastination. Use the tools you have to start.
- After you have that system set up for yourself, you test it for a while, then you can start rolling it out to the other people in the company.
- Start with getting more users involved, getting more feedback from more users, and then bring in editors, creators, and approvers. Some people might have all of these roles, and there’s also a role called a knowledge manager who owns a certain category of documentation.
- Split up all those categories of processes across the company, so the system is not reliant on one person documenting everything. A system dependent on one person is more likely to fail.
Was the product launch approach to documentation deliberate?
- It wasn’t deliberate at the beginning, though I've noticed those parallels as well.
- Similar to product management, which deals a lot with new or improved/changed products, there’s a lot of change management involved in documentation.
- Creating and using documentation may be a brand-new way of working for many people.
- Introducing a documentation practice is not a change like replacing one tool with another tool that does kind of the same thing. It’s a new behavior that was not a previous habit; it was not in people's daily flow of work before this initiative. And so that’s going to take time, a lot of communication, and a lot of seeing good examples to help people along the way.
Beyond getting started, what are other common challenges you see in documentation?
- Getting leadership buy-in, not just peer buy-in, on the time it takes to set up this whole documentation system and then the maintenance afterward. It can be hard to attribute profits or billable work hours directly to documentation, despite the huge lists of benefits that we’ve been talking about.
- On the flip sidde, there are leaders who have taken my course, who say they didn't realize that other leaders wouldn’t encourage this behavior because they can clearly see the benefits.
- Another time challenge is taking the time to complete and improve documentation. So I give a lot of advice about calendar blocking, email or pop-up reminders that get in front of you, creating specific tasks and not just general documentation reminders so you don’t have to go search around and spend that whole hour deciding what to work on next. Having your system set up so it’s easy to make yourself spend the time to make progress.
Additional content I prepped about why people don't do documentation:
- It's a new behavior for most people, most people haven't done it or seen good examples at past jobs
- It's not built into the company culture, which makes anything hard to do, if you're going against norms
- It's not easy to start because of not knowing where to start
- There is not much information online about how to do it well, only information about what tools to buy.
- One reason why it's hard to find helpful resources about process documentation is that it has so many different names. It may be difficult to choose the right words to use in your search.
Examples and current challenges of using AI in documentation
- I don't love talking about AI but an example I've heard is someone who has made a chatbot based on their knowledge base, where the team can ask it a question, and it will pull from the knowledge base. In theory that would reduce the number of questions sent via email, Slack, in meetings, etc.
- But you first have to have a knowledge base with accurate documentation, the AI is not going to extract it from your head.
- AI might help you write a first draft or documentation or clean up your work, but, again, it’s not going to extract the process information from your head.
- It can maybe track the clicks around the screen and software use information, but more of the context and history of why the process is done this way, what's done before, what processes are connected, etc., is going to be hard for AI to extract.
Models, systems, and templates in documentation
- A fear of the blank page can be a blocker to starting dcumenation, so filling in a template can be easier for people to do.
- I do have a suggested template to customize, which includes:
- The title
- A table of contents, where it has links down to the different sections of the document.
- When someone is finished training on the process, they’ve already read the whole document, they might need to refer to just one part in the future, so the link prevents spending time scrolling.
- That helps bring people back to documentation again because it is easy to get the information they need.
- Some tools also let you link people to one specific part of the document when you send a Slack or email to answer their questions
- Administrative details like the date that it was modified, who changed it, who owns this, and who people ask questions on this process so people can trust that it’s up to date.
- History or context section that explains what you’ve tried before. Why is this important for their job? Why is this important for the company? So you don’t keep getting a lot of the same questions about trying 'new' things in the process
- The process steps, broken down into subsections either depending on the role or depending on the stage of the process
- Recommended next readings, related links, if people’s questions were not answered.
The "What is RevOps' book in progress
- The book started as maybe profiles of all these people in RevOps (RevOps Rock Stars) and their answers to these 15 standard questions I asked everybody.
- Then I thought I should try to make it more cohesive instead of just publishing everyone’s interviews into a book
- It is currently called 'What is RevOps?' which you would think, after four years since I did the research, that it wouldn’t still be a question. It is still a question for much of the world outside of the small group of people who have been deep in the industry for a long time.
- The second premise of the book is that it doesn’t have to be my definition, but if we can agree on A definition, then RevOps can get a better understanding, and better career paths, it would be easier to get resources for teams, everybody will be respected more. There won't be as many people thinking it’s sales ops or just having no idea what it is,
- I interviewed 35 people, some with phone interviews and some of them replied with email answers
- I collated their responses, tried to categorize them, and tie them together into a book. It’s been super interesting to see the similarities and differences between some of the answers to all these questions.
- I discovered that this is a very hard way to write. It is the opposite of my usual writing, which is starting with organizing my thoughts, and then finding research to either support or go against those thoughts.
- Mark was interested if there are changes in the way people answered those questions four years ago compared to today. Though I did all the interviews over the same few months, then cut myself off from research to have any hope of putting it together (I love researching and could do it forever but then not publish!) But from what I've seen and heard online since then about these particular questions, there haven’t been a lot of changes. People have wanted to change the name of RevOps, but not the whole message. And the name is not really the key point.
- Mark agreed that we don’t really have a shared model. Unfortunately, some people are given RevOps titles but they’re treated as glorified CRM admins. They don’t have the strategic influence that they should have. He and I both hope the work I'm doing will bring more clarity and power to those folks.
- I focused some of my questions on the people side of RevOps because I saw a lot of tools and tech conversations, likely because it was mostly software companies writing about RevOps, and it served them to say RevOps was technology-based. So I saw missing content online about the people side and the process side of revenue operations.
Thanks again to Mark Lerner for having me on the RevAmp podcast, which you can read and watch here!