Thank you to Sajeel Qureshi for inviting me to the RevOps 500 podcast to discuss the myths and challenges of RevOps, documentation best practices, and more.
Sajeel is CEO at Computan, and is helping marketers win at development and technology. He previously interviewed the CEO from my last role, Nicole Pereira, as well as many other expert guests.
The show covers these topics (which link down to that section of the blog):
-
Dispelling the Myth: RevOps is More Than Software Administration
- Dealing with Common Problems in RevOps
- The Learning Power of Taking Notes and Documenting Processes
Listen to the podcast below, or keep reading!
You can also listen on:
Dispelling the Myth: RevOps is More Than Software Administration
I think a common myth is that RevOps people are just software admins or tool people and that RevOps is not strategic.
In my book research, I interviewed 35 experts on RevOps, and this was a common theme, a common answer to a question I asked about problems in RevOps.
I'm also trying to help solve this problem with the RevOps bootcamp I helped make for HubSpot, where we barely talk about software. It's all about frameworks, project management, goal setting, prioritizing, overcoming objections, and other big-picture 'secrets' to success that usually aren't taught. I know there's a lot of info out there online about how to use software, from software companies, but there isn't as much info about these other skills that are harder to learn.
Sajeel agreed that was a good myth. He also hears people say that RevOps is simple in some ways and difficult in some ways. Another RevOps myth is that people think it's just for big businesses.
Teaching Strategic Skills in RevOps Bootcamps
Some of the skills we teach in bootcamp are how to prioritize projects, how to make a road map of your projects, and how to present that information so that everyone can agree that this is what you're doing. This is to help people fend off those 10,000 requests from every single department in the company that somehow RevOps ends up receiving. A lot of people don't understand what RevOps should be doing, so they think it's just our support team or tool admins.
We also teach a role play about overcoming objections, as well as career skills and hiring frameworks. We do two sessions on process mapping as documentation.
The classes are in a progressive order, and class members receive a big workbook to document their work and to show their managers that they put together a strategic plan for how their department should be moving forward.
Sajeel mentioned it was interesting that the bootcamp is training people on topics like how to use your time, which seems very general. This is a great point. Many of these topics are not specific to RevOps, other departments also need road maps and so on, but since RevOps deals with so many different departments compared to other teams, it's even more important for RevOps to follow these strategies and frameworks.
The Importance of Making Your Work Visible in RevOps
In the bootcamp, we also talk about how people can communicate their success, to prove that they're being successful and not just trudging along heads-down doing the work and never looking up.
Sajeel asked about the prerequisites fo class or for being a good RevOps person since there are a variety of backgrounds people have.
It's definitely a mixed background experience right now since there's only one level of bootcamp. So some people are going back to the basics, which maybe they never had time to set up at their company. Other people who are at the beginning of their RevOps journey are learning the basics of how to be successful from the start.
The prerequisite officially is the free, on-demand Revenue Operations certification from HubSpot Academy. That has a lot of interesting content about finance which is super helpful to understand the big picture of business operations.
Sajeel talked about platform-agnostic RevOps training. He also asked if RevOps people should have a background in data management, marketing, sales, and customer support, or could you take anybody off the street and teach them?
Many good RevOps people have experience in a wide range of functions across the business. It deals with many departments and roles across the business, but there are also bigger companies that have more specialized RevOps roles in data, for example. So a bigger team like that might be a better fit for people who have a really strong data background who want to stay in data and don't wish to expand to doing more general RevOps. We also talked about entry-level roles that may need more technical skills, such as CRM knowledge, compared to higher-level roles.
Dealing with Common Problems in RevOps
Related to learning tools and technical skills, and a new subject such as RevOps itself, it's good to remember that everyone is learning as we go. Software is changing so often that everyone is learning new things all the time, especially tools like HubSpot where new features are introduced almost every day. Teaching the exact software needed for RevOps would be difficult because of these changes as well, but as Sajeel said, the mechanics of what the software is supposed to do, the principles, should stay the same.
Sajeel compared it to an accountant's job where Quickbooks may change its features, but the generally accepted accounting principles and what to report on would stay similar, regardless of what platform you're using.
Sajeel asked about the biggest RevOps challenge I've heard in the bootcamp. I'm not great at remembering specific examples, but what I like hearing about the most is when people get jobs or get promoted, or when they get more resources for hiring more people because of what they learned in class.
The key to this is communication. You can't just be silently doing your work; you have to communicate with people about what you're doing, why it is working and is it not working, and if it's not working, then what you're going to do to iterate and improve. Making your work visible. Communication also means not just sending people spreadsheets but actually explaining the information in real human terms so people understand. In class, we talk about sending and discussing, with leaders and stakeholders, a monthly or quarterly report about how the department is doing compared to the roadmap.
The general components of a roadmap include a project name, the goal it's going to support, the stakeholders involved, what metrics you're going to use to measure success, where those metrics are at certain points in time and more.
Sajeel said how that seems like an overall business strategy in a document. Do we teach people about how to get this information? Do leaders object and say that info is above the RevOps person's clearance level?
We do talk a bit about overcoming objections when talking about process mapping, which is when people might ask why RevOps is not just doing tactical work like fixing something in the CRM. We explain how it's going to help the objecting person be more successful and the other departments that the projects affect.
Sajeel asked what are some of the problems in RevOps that really stress people out?
Fending off requests from all those different departments is a big one because RevOps interacts with so many different departments compared to roles that are not cross-functional. That can make you seem like a task taker or support for departments and not strategic.
Sajeel usually hears about bad data coming in that is messy and overwhelming, and they can't get insights off of bad data. People need that data problem solved first before any other work, but they need the help of other people, which is frustrating, or they are not given the time or resources to clean the data.
He also hears about system-related problems, systems not doing what they need, or two systems not communicating.
My Journey into RevOps and Upcoming Book
Sajeel asked where this idea of getting into RevOps came from.
It was when I started as basically employee number one at a company that originally called itself a marketing tech company because the word RevOps wasn't really circulating yet. That agency was called Remotish, it's since merged with another company. I had a variety of jobs there that started in marketing content because my background was more on the content side. Then I moved into client servicing for their HubSpot tech work, then managing the client servicing team, and then running the operations for the business. Through that time, we were seeing the word 'RevOps' more and more and realizing that's actually what we're doing because we were not just helping the marketing departments, we're also helping service/success departments, sales departments, and trying them all together using HubSpot.
I started researching RevOps and finding all kinds of conflicting information online in 2020 so that's what gave me the idea of doing this book. I asked experts the same set of about 15 questions and compared all those answers.
I'm finally trying to release that this year as a book because another life goal of mine is writing a book. It is tentatively titled, 'What is RevOps?'
I also used some of the research for that bootcamp, so that made me feel like at least the research getting used and helping people in the meantime.
Sajeel asked about the answers I received to the question about what is RevOps.
I did not have the combined definition memorized but there are three principles of people, process, and tools.
I think it is important to have a definition that's not completely different at every company because that leads to difficulty making career paths and difficulty changing companies if the definition is different at every single company. How do you hire when the skills are different at every company? How do you promote people? It causes a lot of problems.
Sajeel asked about the audience for the book.
I think one group is people curious about what RevOps is, who are at the beginning stages of their learning journey. Also, people who are looking to help elevate the profession and create career paths, helping facilitate a greater understanding of RevOps so they can share knowledge more easily, be more successful, and people understand what they're actually doing.
The Importance of Documentation in Career Development
Sajeel asked where the passion for documentation came from.
Looking back on it, I can see I've used documentation throughout my career. For example, in a lot of the jobs, I was the first person in the newly-created role. I was taking on that work from my manager. Before I left I would document everything so I could train the next person without all that work being pushed back to the manager. That's something I did for the first couple jobs I had which were in graphic design.
I also used documentation to try to get a promotion. At one corporate job, my manager changed five times in one year. Nobody knew all the work I was doing. I was young, so I didn't know that was a problem. I was helping all these departments with their requests, which sounds like RevOps, but it wasn't at the time. I had to make a case for my manager's manager about all the work I was doing on top of my regular job description, documenting that work. I didn't stick around long enough to get the promotion because it was corporate; it took too long. I left and started my own business. But that experience taught me another use of documentation.
When I started working for Nicole at Remotish, we would document a lot because we knew we would be growing the team. Also so we could repeat things without having to think about it, especially the customer onboarding and offboarding process. We were documenting things we wanted to improve because you can't improve something if you don't know what's actually happening, or if you're not running processes in a consistent way. So that started the real focus on documentation because we knew we would be expanding the team and we wanted to be efficient as a small team. When I was making all the knowledge management and documentation processes, I didn't see very many resources out there, so that's why I decided to make a course on it.
Creating User-Focused and Multi-Format Documentation
Sajeel asked about the ideal format or components of good documentation.
I would say that it is clearly written and that it's written for the user and not for yourself (unless you are the only user). Make sure you ask for feedback early and often, have peer reviews of your documentation in the early stage, and do not take a month to write this giant document and then say it's done without anyone else seeing it. It's never done, you're always going to be improving the process and the documentation for the process.
I would also say having multiple formats in important. Maybe not creating all formats at once, just start with text or video, whatever format's easiest for you to start with. Then add in text and video and screenshots and process maps because different people want to learn in different ways. Some things are also easier to understand in different formats.
See the video below for the template we discussed on the show:
How do you get people to read the documentation you've worked hard on?
I don't know if it's a magic trick, but building that culture of using documentation, a culture of communication. For example, when you're answering someone's question, you're also including the documentation as a reminder.
Another thing about good documentation is you might have anchor links within the document for the subheadings so you can direct people just to that specific part of the document. They don't have to skim the whole giant masterpiece that you talked about for their one question.
Building that culture of sharing documentation and getting people involved as editors or approvers can help you get buy-in and help them remember that it exists.
Make sure documentation is accessible, that everyone has the right permissions, and that they actually know where to go to find it. Make it easy to find and make it so they don't have to remember some weird SharePoint situation of how to get there.
Sajeel talked about when the person who is now supposed to read the document wasn't on the team when the document was made, so the permissions can be an issue. He also spoke about the art of solving the problem with the documentation and then promoting the document, like internal marketing for it, and considering accessibility like subtitles and captions. Think about the users of the documentation as your internal teams and not just users of the product if you're also responsible for customer-facing documentation about your product or services.
Think about documentation as content. It's helpful content that you want to share.
Sajeel talked about a writing class where they teach you to write to a fourth grade level audience. When writing, consider people new to the team and those who natively speak another language.
I'm very against jargon when so many people love to use abbreviations and acronyms. If someone's new to your company and see jargon, they're going to be lost, they're not going to feel like they belong, there's so many problems with jargon. Especially company-only jargon you can't use Google to figure out.
The Future of Documentation and AI
Sajeel asked about predictions for RevOps. I can't predict the future, but I hope there's an increased understanding of RevOps, an understanding that it is not just software administration. That's what I hope. I hope more people are talking about RevOps as the years go on, which would be great for everyone working in the field.
For documentation, I don't think the AI robots are going to take it over because they can't yet extract the information from your brain. AI can track where you're clicking on the screen but not the history or the context, why you did it this way, what you did before, why it wasn't working before, and all that sort of information. So I don't think the robots are quite there yet with documentation. AI can help in some ways, like making a generic draft that you can work from, or cleaning up your document, maybe making your process steps a little more clear. I don't think we're in danger of being replaced in a bad way.
Sajeel asked about meeting assistant note-taking tools and comparing those to taking notes manually. I think currently, they do a good job of taking notes, but a lot of times, the manual taking of notes is what helps you remember. The physical taking of the notes helps you remember, understand, and process the information yourself. So, if that's one of your goals, you might still want to also take your own notes.
I think that brings up another point -- if you're making a first draft of documentation using a transcript from a
tool, that can also be a good first step because something is better than nothing. Similarly, if you're not taking any meeting notes at all, then having some kind of AI transcripts or insights is definitely better than nothing.
I know there are also tools that can pull common words and patterns out of meetings, such as not just analyzing one meeting by itself but groups of meetings at once, and that seems helpful as well.
Sajeel brought up another point about if you're documenting processes and you don't know parts of it, such as parts that affect another department, that'll make you learn more about the process, communicate more with that department to learn how the process affects them, so that can also be part of a learning process in making the documentation.
We talked about how I don't have one perfect example of documentation since it was always changing and iterating, and there are other best practices I know now that I would have added in. Also, the documentation itself would evolve with the company, such as being broken up into smaller articles as new teams formed and separated, or if the process got too big to make sense in one document with all the details. We talked about interlinking these types of articles with each other and making almost like a table of contents article that said 'Start Here' in the title for people beginning to learn about the topic, which links people off in a specific order for that topic.
He asked if team members were grateful for the documentation. Yes I heard some grateful feedback. I also created an onboarding program where we taught people about documentation as part of the company culture, how to do their best work, what parts each person is responsible for, and so on. People would say they were grateful that it existed because they're new to the company, but now they can just go and self-serve answers besides asking questions. This is helpful if people aren't online at the same time, for example, it helps empower people to understand what is happening in the company no matter what time zone they're in. Sajeel said that it's pretty powerful when you know you're making life easier for people all over the world, when those documents don't exist in most companies.
My Weekly Newsletter: Sharing Valuable Resources
Sajeel asked about my weekly newsletter, where the idea came from, and why I do it. He enjoys it because there's always at least one or two links in there that are that are interesting to him.
I'm always reading and listening, consuming content, and I wanted to find a way to share that easily with people. I know a lot of people don't sign up for every single newsletter they see because they're not weirdos like me! I thought about how I'm already doing all this reading and learning from this information every day, so how can I share that with people? Even though it's not focused on one topic because I'm interested in many things, I'm sure there are other people who are interested in certain pieces of what I'm sharing, and they can just scroll through this big list of links that I share every week and see if something interests them and maybe click through to learn about it.
I think having that curated information in one place and delivered to their inbox saves people time searching for content, and I just like sharing resources. Everyone's busy, everyone's getting so many communications, maybe somebody missed certain posts they would have found valuable, or maybe the algorithm's doing weird things and not showing you people's content.
A lot of the people who I share from regularly I think are super interesting people who create great content who deserve more attention, so hopefully I can help them get recognition for their work
Even though it takes some manual work, the 'putting together' part of the newsletter every week, I think it's helpful. I get a lot of good feedback on it, I feel good doing it because I'm doing that learning work and I'm also doing the sharing of the information. That makes me feel helpful.
Sajeel talked about how sometimes you'll see content shared that is 'typical Jen,' and then there's something where you wonder, 'How'd that get in there?'
I don't know if it's ever totally random, but I'll share it if I think the content is interesting and that it could help other people, even if it's not on brand... I don't even know what exactly my brand is because I like so many different things, it's hard to really categorize anything. That's why in the newsletter, I just categorize it by type of platform or type of content, instead of trying to say that certain links are about RevOps and other links are about Learning and Development. All my interests kind of interconnect and overlap.
Sajeel mentioned seeing marketing content, accounting content, it could be anything. He said he found himself clicking on those random topics more than the usual ones. Maybe you don't sign up for news on that topic, so it's not something you normally see. So I try to help people discover it. He compared it to tuning into the radio, you don't know what you're going to get when you tuned into a station, they're all different topics but they're somehow related.
Thanks again to Sajeel Qureshi for having me on the RevOps 500 podcast!
Topics: Documentation, RevOps, Event