Janis Zech: Hey, good to meet you, Nick.

Nicholas Gollop: Likewise. Nice to be here. Thank you for having me. Yeah.

Janis Zech: Thanks. I mean, you bring a wealth of experience in RevOps, started your career at Kimberly Clark, then joined Salesforce. Right? Probably some very sophisticated RevOps set ups there. Thomson Reuters, you know, you got acquired into Medallia, and you're now the VP of RevOps at CloudCall. And, also, on the side, help, you know, fellow RevOps members of the communities to become better at their craft. So, yeah, I mean, I'm super thrilled to have you and super excited to talk to you about, you know, all things RevOps. So let's jump in. Maybe let's kick off with, like, you know, I think a lot of people ask themselves, how do I build a, you know, a good RevOps team, and how would you recommend to build a RevOps function from scratch?

Nicholas Gollop: So I guess with current limitations of budgets or hiring freezes, you need to really learn how to prioritize your tasks and try to understand what it is that the company needs right now. Because most of the time it's just having to redo things that were already there and that takes time. But trying to bring in more efficiency can sometimes just completely negate the need for hiring someone, be that super senior or just a system admin. And having a planning of what it is that your current state is and the ideal state that you want to be in allows you to kind of literally design what an ideal role would look like. And for that obviously varies from size of organization, MRR, ARR, amount of employees that you have from the revenue side of things. But essentially what you need to do is design what the current state is of the company, and then try to figure out where it is that you want to be, because that will allow you a lot more leeway and understanding of the resources that are required to do specific tasks. Right? So if you have, if you're in a smaller organization and you're just starting a RevOps function, if you've never done it before, you need to first understand what it is that your skills can be better put in, right? So if you're needing a CRM overhaul and you just have, you know, a lot of data to work with or not data at all to work with, you need to understand what it is that you can do yourself versus what you're probably going to have to outsource. Because more often than not, companies try to just do a lot with the resources they have rather than hiring people with specific skill sets. And that can become a very big snowball down the road because lack of experience doing things that require experience to be done can be a double edged sword. You might be saving now, but the costs are going to start showing up down the road. Right. So what I always suggest is if you don't have a lot of budget to go with, have someone to at least manage your tech stack for you, someone with experience to manage your tech stack. And it can be senior analyst manager roles, not putting titles here necessarily, but that does usually help kind of put that frame of reference in. And so people, these people can help you kind of design what a minimum and an MVP state of a CRM and an integrations with your tech stack should look like. That is very, very important and most often underrated in that scale of importance, right? Because data is the foundation to any decision making. And if you don't have that correctly done and systems talking to each other, then you already are set up for failure, right? So that needs to be done and managed accordingly. Now, if that is being managed under on top of a correct process or not, that's a separate story. You at least need to make sense of your tech stack and everything talk to each other. With that, you can then design a process to make sure that the systems can handle and someone can actually translate that into that process, into that tech stack. So that would be my initial suggestion. If you don't have a leader, if you're wanting to get a leader, I would tend to recommend not going super senior when you're too early on, because you might get two types of people, people who are not technical enough or people who don't necessarily have that level of seniority to make the strategic calls and understand the concept of how everything fits in together. Right? So you would usually start a bit more junior just to manage the basics. And then once that is correctly set up, you would then look into potentially getting a leader. But I wouldn't necessarily recommend going mid level to start the RevOps function because you don't have enough experience there. So having someone to at least get the foundational job done, that's the first. And then someone senior to come in and say, right now that we have that done, what are the next steps? Right? Every company functions differently, of course, but ideally you need someone to kind of have that bigger picture approach. Otherwise you're just going to start piling onto the problem.

Janis Zech: In early stage companies or like small businesses, right, the reality is often that the founders, the people who start the company, the owner, whoever, whatever the title is, they are typically the ones that fill out that role initially. Do you think that's a mistake to have that with that person? Would you rather have somebody else to take that job, or do you think it's fine if the owner or founders are taking care of that initially?

Nicholas Gollop: So it wouldn't be fair for me to sit here and say that it's wrong or right. Right. Every company that goes through seed round and then series A and series B, they have their own particular needs. Right. And we can't ignore that. We can't say, well, you know, you should be getting a VP of senior level person just start RevOps and all that. That's not ideal because budget wise doesn't make sense. Right. So being practical about it, I think founders and CEOs and whatnot, you guys know very well. It's not you need to do with what you have. Right? And sometimes it's not the ideal, but it's what you have. Right? And I think that is by far the most underrated thing. People say, yeah, RevOps needs to be built from the very beginning. I agree. The sooner the better. But you can't just keep on going as a roller coaster regardless. Right? So would I recommend the founders do it? I wouldn't recommend that long term because I don't think one person can do everything well. You have a specific skill set and you should target on that. But if you don't have resources and if you don't have someone to do that for you, then you have to do with what you can. Right? And that's just the reality. Is it ideal? No. Is it scalable? Also no. But it's what you have at the point at the time.

Janis Zech: Yeah. That's fair. Yeah. I've heard about that before. And yes, that's a very nice way of putting it. I'm curious at what size of the organization, at what maybe funding round stage do you typically see people hiring their first RevOps person full time or size of the revenue team? Right? Like I'm curious, what do you think makes sense?

Nicholas Gollop: Okay, so I think the first thing we need to do is define RevOps, right? And yes, we're going to go down that path again of defining RevOps because I think it's critical that people really start to understand. There are lots of different visions and different approaches to RevOps and what it should be, what it shouldn't be. But in my view, it's the optimization of the customer journey internally and externally, right? From lead to cash. It's not the tactical view of it is combination of sales ops, mark ops, CS ops, but that's just the tactical view of what it is actually. But it doesn't give you the context of what it is. Right? So to me, it's the optimization of the lead to cash process internally and externally. Right? So it's seamless internally for the people who reps, CSMs and all that, for also the customer that doesn't even notice that they're going through a buying journey. That's to me what it should be. Now, the actual function itself varies, right? Because in different levels you would have different priorities, responsibilities, and that would obviously change significantly, right? But the function itself is very much about making sure that people are enabled to do their best, be that technology wise or enablement and capabilities, and therefore you would have to kind of dose the level of responsibilities across the board, right? Be that an analyst level, be that VP level, that doesn't necessarily matter. But it's about that optimization and finding the right balance, which is really, really, really tough to do, honestly.

Janis Zech: One hundred percent. I'm curious, I mean, in your intro statement, you said that RevOps need to show more value now than maybe 2022, 2021, the heydays of crazy funding rounds. I mean, I'm curious what you mean with that and whether you have specific examples, you know, of how that can be done. Right? I think there's a big debate around strategic versus tactical in the RevOps community. And I'm curious, like, you know, how do you do that? Right?

Nicholas Gollop: Yeah. I mean, the more we lack resources, the more we have to come and show what it is that we are here to do. Right. And the more challenging it becomes because the less resources you have, the more you have to do and the more you're stretched thin across the board, which is really tricky. So you need to find a level of I need to take a step back and really understand the full situation and full picture versus I need to get shit done, right? Which is the tactical. Now, before you had an abundance of resources, an abundance of cash flowing into the companies and you could experiment a lot more. And growth was measured in head counts and growth was also kind of growth at all costs and all that. And that's fantastic for a very non scalable growth approach. But the moment you start losing track of optimization and efficiency, that's when things start falling apart pretty quickly. So having that balance of, you know, making sure that resource is not hindering you, but you're also being able to prioritize what you have to do is really tricky. So the value, in my opinion, comes through time saved, right? The amount of time that it took for you to do one thing before RevOps or before you had a proper process built to today where you do have and you can actually start showing that value. So a very clear example of that in the past that I've done was reps usually have to go through massive hurdles during the entire journey, right? So you have to talk to one hundred and fifty people, depending on the size of the company. You're going through meetings with fifty stakeholders and more than one decision makers and all that. So you have to basically bake every single need and restriction from the customer side into a negotiation and into a conversation. Right. So that eventually translates into a complex pricing logic, depending on how you go and different buying terms and specific bespoke terms and all that. So streamlining that negotiation piece of the funnel can save an enormous amount of time for reps in general. So the less they have admin on their plates to do, the better and more time they will have to actually do what it is that they need to do, which is sell. So optimizing that piece for them can already save them massive amount of time. And one of the organizations I worked for that went down from like five, six hours a week to thirty minutes for each rep. And if you add that, well, you don't even have to add that up. That's kind of obvious the amount of time saved. But even if it was from forty minutes to just thirty, if you add that ten minutes every single day, you're going to see that it's going to add up pretty significantly. So that can span across different things, right? Them not having to spend time requalifying leads or checking if the lead quality is correct, or even if they should be the ones owning the lead and not someone else, because this is a subsidiary account and not a parent account. All of this equates to time saved. So I think that's the primary thing that we need to latch on as much as we can because RevOps, unlike sales, doesn't have a quota necessarily or something that is easily quantifiable for the role. We are project based and we deliver value. And value nowadays is time, right? Because I think it's the only thing people want more of but we cannot have.

Janis Zech: I really like that and it resonates strongly with me because I think like when we started Weflow, like one of the statistics that we looked at a lot was the amount of admin work that salespeople actually spent their time on. And I think it was something I mean, it varies, obviously, by organization, but something around forty percent to fifty percent in some extreme cases. So it's a huge amount of time that people just spend on admin work and actually not selling, right? Because that's what it means. If you do admin work, you're not selling, you're not prospecting, you're not building pipeline, which is really what you should be spending your time on. Just one question to drill into that a bit deeper. So I like that idea of having just one KPI to measure success. I think it's great to, I mean, it's not easy to measure, of course, in some cases, but it's a very sales specific approach to RevOps that you're talking about. And RevOps can be much more than sales. How far would you draw that, the area of responsibility for RevOps? Or are you really more coming from that perspective of, hey, RevOps really is focused on the sales part, but less so on, let's say, customer success or marketing.

Nicholas Gollop: The example was just one that came to mind. It's not more or less important. It's just one that sprung to mind because I think that is one of the ones that you can really see the value in terms of time saved. But RevOps needs to be stretched across the board. Now, having said that, tying to the first point that we brought in, depending on how you're building RevOps and the size of your organization, if you are a lone warrior trying to go through the entire thing, you're not going to be able to focus on everything, right? You're gonna have to pick one or two at best. If you're also stretching across finance ops and also a bit of legal, then it's even worse. So eventually there is a natural bias, right? Which is depending on where you start your career. I started in sales ops, so I have a lot more sales ops experience than I do marketing operations experience, but I also have an equal amount of CS ops. So I tend to balance towards those, to bias towards those rather than mark ops. But you then need to hire dedicated resources to help you spread thin or stretch at least a bit more so that you can balance it out. But having said that, that is an example from sales. Yes. But I think you have multiple across CS as well. So for example, something that we can really bring value and something that companies are not really using is understanding your customer base, right? Who's renewing when? Who's using what? And what are their sentiment towards your product? Because usage does not necessarily equate to a sentiment, right? I can still use a lot of your product. I can still find it pretty bad. So that is the sentiment. So these three things are very key to understand adoption as a whole. And how do you do that? You translate that into metrics, right? And that is customer health score. And that's usually something that is built by RevOps people or at least enabled by the RevOps team because we understand the systems, we understand theoretically the framework and the matrix of what it is to build an actual health score and what are the criteria that you need to be looking at in order to build something a bit more robust than just clicks here and there, amount of logins and all that, which is still valid. But these are smaller things within a larger health score metric. And doing so allows you a lot more visibility into forecasting for renewals, which is a very different motion from sales forecasting. Right? Sales forecasting is maybe it comes, maybe it doesn't. Renewals, no, they have a start and an end date. They have to happen by a date. The only thing that might happen is three months prior to that or whatever your notice period is, it might not. Right. So you need to mitigate that and work with your clients to make sure it does. It's a very different motion, but the art is still the same, right? It's trying to get all the tools and the metrics at your disposal to make that a bit more predictable. And marketing is the same logic around optimizing campaigns, for example, or optimizing how leads come in. Lead scoring is the equivalent of health scoring for customer success in marketing and how to build a scoring that doesn't allow unqualified or low quality leads to go through, but making sure that you're also not over processing stuff that shouldn't. Right. And then also how you manage campaigns. So it can span across the board and you need experience in at least two of the three areas to be able to really call yourself RevOps, because it's not just a rebranded CS ops person or a salesperson or a mark ops person. Right? You need exposure in all three.

Janis Zech: I mean, having built a bunch of different companies, I think typically when you start a new function, it's great to have somebody who is really smart and driven and motivated, but rather a generalist. Right? Like, going into specialist roles too early can be really challenging. I mean, you've also experienced large RevOps organizations like Salesforce, Thomson Reuters. Right? I'm sure there were a lot of specialization in those organizations. I'm curious, like, you know, whether you could describe, you know, how does a, you know, scaled RevOps organization typically look like? And what are some of the differences to maybe, you know, starting from scratch?

Nicholas Gollop: Yeah, this I think is very interesting because one of my mentees asked me like, what should I do? Should I go into a large organization or just continue going down a path of a smaller org? Right. And there are advantages and disadvantages to both. It's really how you pace yourself. If you're someone who likes building and feeling like you're making an impact directly with your actions, you're probably more inclined to go into a smaller org just because of the magnitude and the implications of what you do on a day to day. If you go into a larger organization, you have an issue where you still going to make an impact, but you're not going to feel like your impact is as big as it could be in a smaller org just because of the hyper fragmentation and specialization of people. So at Salesforce, for example, and it's very much the same to this day, the ops team was so broad that it span across like five different leaderships, right? You have a deal desk leadership, you have an enablement leadership, which sits under a very different VP or like overarching leadership. Then you have compensation leadership. Literally, it's a thing. There's a leader for specific compensation things and disputes and all that. Techstack, for example, is not owned or managed by RevOps. It's managed by IT. And then people ask, is that the best way to do it? For a smaller org, I would say no, because you're hyper focusing and specializing and you're potentially even creating bottlenecks you don't even need. RevOps understands the tech stack enough, but we also do not understand Azure, Google Cloud Platform, the actual database. We don't have that knowledge because that's just not the extent of where it goes. But IT does. And IT can manage Salesforce from a technical side and also manage Azure or whatever your database is built on. So naturally that transition happens. And the reason this is important is because it just goes to show how very different it is in a massive organization. A day to day for sales ops is not about changing the process. It is not about creating enablement plans. That is just monitoring the organization's already built. It exists. Rather you're there or not. Right. So your task is much more minute and focused on specific things. If you're literally just in sales strategy and operations, what you're probably doing is you're building decks for QBRs with your RVPs. You are doing a lot of support tickets and management for field reps answering questions around the tech stack or even compensation disputes, which is probably like forty percent of the cases and very much like tactical support stuff. If you're obviously on leadership level, you are more of a generalist rather than a specialist. But your discussions are more around the insights that you can provide to the different leaders across the business, right? You're the people presenting the decks that your team built. And that's more how it, I wouldn't even say RevOps really, because that would be wrong. And that's also another point. If you want to grow into the RevOps overarching branch in a massive organization, first of all, it doesn't really exist. It's just sales ops leadership, customer success leadership, mark ops leadership, and they all report into probably the CMO, the chief customer officer and the chief sales officer, I guess, because it's not revenue officer, but yeah. So they even have their own silos and all that. So if you want to become and really build a concept of centralized ops, that is not the place to go, I would suggest, obviously. But that's my opinion.

Janis Zech: That is so interesting. I mean, and so different to what we typically in our community talk about. Right? And the importance of having an end to end view internally and externally from a buyer experience to create those experiences and optimize them and make them efficient and effective. Right? I think that's really interesting. I mean, you know, maybe switching gears here a bit. I know we talked a lot about change management and prioritization, you know, as one of the central pillars of RevOps. I'm curious. Let's switch back to maybe smaller orgs, right, series B to F. How do you typically approach those? What is the importance of it? You know, how do you view these points?

Nicholas Gollop: I mean, RevOps as a whole is about change. It's about challenging the status quo and making sure that if something's working, it doesn't necessarily mean it's working to its fullest potential. Right. It can still be working, but it might be a bit more efficient or it can be doing something a bit different here and there that might bring small incremental changes, right? Like iPhones nowadays, they don't present massive leaps forward every year. But if you take a span of ten years, it's a big difference, right? So the concept of change management and prioritization comes a lot from there, right? It's small iterative changes. If you're in a scale up, then probably bigger changes that will together paint a bigger, better picture of your organization, right? And prioritization is more important in organizations where you don't have a team or you don't have very well defined functions, even in smaller areas I'm talking about. I'm not even talking about big organizations, I'm talking small. If you have a five hundred people company or two hundred people company, but you have a team of four RevOps, sales ops, CS ops, whatever, it's already pretty good. So you can already start doing some compartmentalization of tasks and assigning specific things to specific people. But all in all, what I always recommend is out of the ten things that you have to do, what are the three projects that are gonna cause eighty percent of impact? The rest can wait. And that really helps you to understand what it is that is a must have versus a nice to have and what you can also push back on leadership. Usually that's leadership who actually asks for things. How can you push back and make them understand the importance of what they're asking against the entire org? Right? Because a sales leader might ask saying, oh, I need this to happen. Great. But there's this other list of things that need to happen across org for your item to be able to provide any insight or value or even work. So presenting that bigger picture drops the silos because it teaches the people that they're not just doing their own thing. There's more to it and also allows you to throw back and say like this will happen. I'm not saying no. I'm just saying no for now. And it allows you to gauge that a lot better. Right? And the ten to eighty percent rule is very interesting because it really helped me in the past and still helps me to this day. And anything apart from that, I just say, hey, there's not enough resources for us. And it's not trying to diffuse the request. It's just creating that sense of urgency as well across the business. Right? Because people ask and ask and ask. We can do a lot of it, but we're not magicians.

Janis Zech: I think if you want to rise above the tactical level, being very strategic about what you work on, having a clear road map and a clear game plan, and then also understanding not just as the RevOps team, but as the leadership team that these are all trade offs, and you have to make trade off decisions, I think, is key. I'm curious, like, how you think about RevOps discovery. And what I mean with that is, you know, you have ten projects. So what are the three projects that, you know, have the desired impact? I mean, that needs some time to think about and some exploration around like what the impact could be. Are you having a way to calculate the ROI or think about the desired effect, whether that's efficiency, time saved or better prioritization? I'm curious how you approach that.

Nicholas Gollop: The first thing I always look at is revenue. Unfortunately, that's just how we anchor every decision we make, right? It's revenue. So a decision of a project, for example, where creating a field to standardize, I don't know, a lead attribution on a specific model sounds small and can be sometimes. But if you have on the same list fine tuning or even building a health score for your CS team, kind of easy to make the call, right? So they can still be important, but I would take that as a priority number one, building the health score, because that is going to down the road impact revenue. The lead attribution might, but in terms of priority, it's not that much. But you also have to, second rule is how long it's gonna take. Right? Sometimes changes can just take thirty seconds, like on the actual watch clock. Right? It takes thirty seconds. So if that's the case and you can get it done quickly, just do it. It's fine. You don't have to put on a massive backlog and, you know, do a sprint or anything like that. Just go do it. But if it takes a bit more time and you think you have to take a look at the process where it's going to fit different conditions and criteria, then I would say put it into the rule of ten and eighty percent. Because if it's not thirty seconds, then it's probably gonna interfere on different things. But revenue is usually my first anchor point. Like how is this decision going to impact revenue further down the line, but also immediately, right? The quoting example that I gave is another one. Lead scoring is important. Yes. But if your leads are still getting through to the right person, even though they're not perfect quality, they're still flowing, right? So it's maybe not a priority for now. The scoring might be a priority if everything is garbage and all that, that's a different story. But if they're still getting through, it's not perfect and all that, you can still fine tune it. You can focus on something else because that is not a burning issue. But if you don't have a health score as a whole, that might be. So that's usually what I do. How long it takes and is it going to impact or not in the meantime revenue.

Janis Zech: I think it's like a really ongoing theme in a lot of different jobs and roles, right? Like you always have like this switch between strategic, tactical. Everybody complains about it, oh, I want to be more strategic because they are always feeling like they're stuck in the tactical work. But I think the reality, this is actually true for nearly all job functions that you have, maybe less so in sales, I would argue. But for product, for sure, marketing, definitely. And yeah, just curious, do you see in your long career, I think fair to say, in revenue operations and also, I think you're a certified Salesforce admin and consultant, which is also crazy and I think quite special in your case. Like, have you seen any specific cycles that RevOps goes through within a year, sort of like a theme, like a certain seasonality that you always have, some kind of like topics of projects that need to take care of?

Nicholas Gollop: Yeah, I think what you need to do is do the thirty, sixty, ninety day plan, right? I think the biggest impact of RevOps is going to be felt within the first three to six months in an organization. That's when we're doing the entire discovery. Like I actually do this myself. I sit down with all my reps and I shadow everybody or as much as I can. I then shadow marketing team, different areas of the marketing team, shadow the CS team, finance team especially, legal as well to get a bigger picture from their point of view, not from mine, from theirs. Because they will then in the meantime give you pain points and give inefficiencies, suggestions on things that can be better, and so forth. So it will help you build the ideal state of the process and cycle you through a lot more efficiently right through the role. And it will also help you build the list of priorities that you have. So the cycles are usually kind of like come in, listen, learn, and then start doing a whiteboarding session and trying to understand a lot more of that, right? Because if you start to, you know, run, you're going to get into massive problems in the future, because if you just start to prove value immediately, as in like the first two weeks or so, you're gonna probably step on your own toes. So I would say take a breather, right? It's better to do it once correctly than having to come back and do it multiple times. So that is critical, and the people who keep saying like, I want to be more strategic versus tactical. Okay, great. What does strategic mean for you then? Because if it is just sitting in a boardroom and discussing strategy around the company, we don't do that. I don't think you guys do that either. It is not that. You do a lot of the tactical stuff, and sometimes the tactical drives strategy, a lot of it. Right? It is not just that you guys are really, like, hands on trying to get to the point where the board can just be a conversation. But from there, you're also going to come out of the session having to discuss how are we going to do everything that we just said. Right. So it's going to be super tactical. So I wouldn't necessarily see the tactical versus strategic as being so negative. I think tactical got me where I am today. I started as a system admin and eventually grew into like mark ops, CS ops, and started gaining that traction. So I think the blend between having the technical skills versus the strategic is as equally important. And actually, if I was to hire a director, for example, today, I would need someone to be tactical. I wouldn't just go with someone who knows all the things like from a conceptual perspective and not having ever done it tactically, because what good does that make me? I mean, I need someone to help me actually get the job done, not just talk about it.

Janis Zech: I love this. This resonates so well with me. I always say the devil is in the detail, and it's very important to actually get shit done. Of course, you need to step back again and again and think about how to level up the game, but then it's just often a lot of work. And so being able to switch between the two is crucial if you wanna become, like, a successful leader in my point of view. But a lot of leaders actually miss the nitty gritty detail part, and I find that really frustrating, to be honest. And I think the best leaders actually combine the two. So, hey. I mean, I think we could go into many different directions, and maybe we just have to invite you back. But just wanna ask you our closing question. I mean, if you were to start your career now, right, and knowing what you know now, what would you do differently?

Nicholas Gollop: I guess attention to detail. I cannot stress enough how important that is. And I think the moment you start realizing that I, as a leader today, don't care if you do something that I asked faster. If I still have to review it and I pick up issues and incorrect mistakes, kind of pointless, right? I'd have to do it again. So I could have just done it in the first place. So attention to detail is by far the most underrated thing ever. You need to be able to have confidence in what you're doing and give confidence to the person you're delivering that to so that it's just a pass and is not having to go down and pick up mistakes and having to iterate on that. Quality over quantity, that is paramount, especially in ops.

Janis Zech: I love it. Nick, thank you so much for joining us. Really, really enjoyed the session.

Nicholas Gollop: Yeah. Thank you. My pleasure. Thank you, guys.