How to move RevOps from tactical to strategic. With Avi Ryan

Speaker A: Start thinking about how do you move from being tactical to strategic. Start thinking about how to move from being reactive, just waiting for someone to ask for a report to being proactive. You have to have a roadmap of initiatives you want to lead. All those initiatives would have impact, direct line of sight to business impact. Uh, you have to be able to interact, you have to have executive presence. Like a lot of ops people, they're just like, oh, let me just stand behind my dashboard. I run numbers and I'll ping it to you back. No, get outside your comfort zone. Interact with VPC levels, engage with them. Again, I'm talking to myself back then because you need to learn also how to be able to communicate to that level concept that are Rev Apps but in a way that would matter for them, right? That would uh, make them understand that oh, it's worth making more investment and, and worth actually having you next to the table when we talk about our next go to market, uh, strategy.

Speaker B: Hey everybody, welcome back to another edition of RevOps Unboxed. And I'm really excited to have my guest today, Avi Ryan. Um, we're going to get into it and talk about some really cool stuff. So Avi, do you want to tell us a little bit about yourself?

Speaker A: Yeah, sure thing. Uh, great to see you again as well. Uh, so my name is Avi Ryan. I, um, I'm a Rev Apps person for many years. Um, I, if you look at my career and I'm not going to walk you through my resume, but you can see that I work for a broad spectrum of companies of different sizes, different stages. From very early stage startups, uh, all the way to large scale corporates. Uh, last uh, seven uh, years or so I spent at Google at the ads business. So really was able to kind of see different flavors of RevOps and kind of understand what's right from a RevOps perspective to each size of a company. What's not right, what type of mistakes usually companies make as they try to scale in the context of revenue, um, operation. So yeah, ah, a lot has happened. I've been here living in California in the bay area for 15, uh, years now. A lot has happened since um, early days how this entire RevOps concept even started. You know, it started with sales ops and kind of graduated gradually, uh, grew, uh, uh, uh, to this Rev Op concept that has also a lot of different takes and ideas behind it. Uh, and yeah, I'm looking forward to talk more about it today.

Speaker B: I know I have so many questions to ask so I'm going to give a shout out though, to the RevOps alliance, because Avi and I actually met at one of their, um, conferences and struck up a chat and we've kept in touch ever since. So I'm really excited to kind of dive in to get more of a lot of the stuff that you've doing that you're doing currently and then what you've done in the past. So I know that you mentioned you walk, you have worked through different companies like Google and some of the things that you've seen at different scales, different maturity levels of a company. What is something at scale that you

Speaker A: absolutely shouldn't do, that you shouldn't do? Oh, wow, that's a good question. Um, I would start first with what we should do, uh, and then we'll kind of explain why sometimes it also promotes, uh, some things that you actually should not bring along with it. Right. Um, so it was very interesting when I joined Google. I joined Google after being much smaller companies and one of the things I noticed there is how the entire perception of RevOps is completely different, right. Coming, um, from smaller, uh, companies, usually RevOps is being perceived more as tactical operational. Um, immediately going to Google, you realize it's a go to market function, it's much more strategic. Um, they lead go to market in a lot of senses. Um, and as such they always optimize for scale. Right. A company like Google cannot afford mistakes like a smaller company that they can immediately pivot and correct the direction. Uh, so everything is really measured in terms of can I scale it and can it drive enough impact for the business. If not, we're not even going to go after that direction. Um, as such, Google, they always optimize for processes, they always optimize for data governance, and they always optimize for driving business impact. Um, I can talk more about that, but I want to go back to your question. The problem is that when you do all that and you put a lot of structure in place, you le, you lose some of that ability to be flexible and move faster. And sometimes, you know, when it comes to rev ups, we can identify the trend very fast, very quickly.

Speaker B: Right.

Speaker A: We're in the numbers all day. Um, and sometimes you have to react immediately, you change direction because you see you're trending in the wrong direction. But, uh, large companies like Google, uh, it takes a lot of time to drive change. And sometimes by the time you're able to drive change, actually what you try to solve is not relevant anymore.

Speaker B: So, yeah, that's what I was going to say. You know, Working at Google, you lose the agility, you know, because you have so many people, so many different departments, so many people that you have to collaborate with in that revop space. So I'm going to just like kind of go off script for this question. When you were at Google and you did have to do things to scale, how were you able to successfully do that with such a large organization? Even it was for minor changes, you know, because I experience that now myself. You know, I want to make a change, but if it's at a bigger scale it takes me longer to do it. And to your point, it might not be relevant anymore because you want to fix it fast. So I want to. How did you manage to do that stuff when you were there?

Speaker A: That's a great question. First, you should know that there's no moving fast company like Google. Um, and you need to understand it takes time because if it's really a big meaningful project, it usually means there is a big cross functional component into it. Um, and just to get everybody aligned, uh, on what are the goals of the project, deliverables, timeline, uh, um, who needs to contribute what as part of the project and by when. Um, it takes a lot of time. That's why uh, at Google, before they get into the adventure of a project, usually what they're going to do is they put a lot of uh, um, uh, mechanisms, uh, to evaluate should you even start pursuing that direction. You don't want to work on a project for six months and then realize it was actually a waste of time. Right. So the evaluation I mentioned earlier, right. They always optimize for processes, data and impact the evaluation. Usually we start with impact. When you have an idea, you have a direction, the first question they're going to ask you, what's the impact you're hoping to drive? And we really try to understand is that impact worth the effort that you're looking to make. Okay, so that's number, uh, one. Uh, number two, Google, um, will usually say, okay great, let's have a proof of concept. Uh, almost every big project that we led started small. Uh, one, just to test it out faster. Two, let's, I'll give an example. You know, one of the programs I manage had footprint of 50 markets, for example, right. If you drive change in 50 markets and you do it wrong, you just broke the entire program. Right. So you want to start in the small level, you know, small markets, take kind of a sample of markets and see how it works there, optimize and then you kind of ready again. It takes more Time. But you have to be m m more careful when you approach these type of uh, uh, changes. And I think the third part, which is a big difference between big companies, small companies, is big companies, um, especially Google. I wouldn't say everybody, but big companies are very good in terms of driving change management. Where other companies. Remember I spoke about the agility. Sometimes agility can work against you, right? Because you move so fast, you implement a change you thought you drove adoption and you move on to the next one and then you realize a year later no one adopted it and then you just need to redo it. At Google, they usually, um, had a very deliberately put kind of a adoption phase. And the success metrics, they don't go immediately, oh, show me how much revenue. Show me first there's adoption and then show me that it drove the impact revenue that you were hoping to get. So the, the change management I would say at Google was done, um, one of the best ways I saw just to make sure people adapt to those things and then you measure the impact and then you kind of move forward from there.

Speaker B: I love that. So at an enterprise level, and we can kind of work backwards at an enterprise level, when you have RevOps, what did that look like? Like what did your RevOps function and department actually look like to deliver that, those kind of results at such a huge level? Like how many people, what did the part like, did you have certain functions? Because, you know, we see different robots, departments with different functions. So at that level, what is something sustainable?

Speaker A: Yeah, so first of all, Google is a huge organization and they have a, uh, go to market to every, you know, team function. It's different flavors. Right. So maybe we can talk a little bit more about the ads business. The part was there, which right now is the main driver for Google, um, over there you're going to see probably a combination of uh, three things around RevOps, um, which is the uh, operation side of the business, the strategic side of the business, and the enablement side of the business. I would say usually you're going to see those three pillars in every shape or form. Every initiative will have a flavor, some then we give you more operational, some of them going to be more strategic, um, etc. Uh, now because it's such a huge, you know, I spoke about, you know, a program with 50 markets and billions of dollars in terms of revenue. But that was one program out of many programs very similar to that in terms of footprint. Right. So usually every sales program will have kind of a dedicated, uh, go, um, to market team that will cover those three aspects, ops, strategy and enablement. Um, but they will always work cross functionally, whether it's with product strategy, whether it's with finance, on incentives and compensation and things of such. Um, there are always central teams that look across multiple programs to see, hey, do we actually have initiative? We need to do more globally and not just per program. Right. It's much more scalable. So it's. A partner said that Google, what one person in a smaller company would do at Google, it's a whole department basically of people and each one of them will take a nuance of that and just be focused on one program to make sure they're maximizing everything. Um, the last thing I would say it's important to understand. Every percent of impact at Google could be billions of dollars. Right. So it's, it's a very. That's why you can go to those nuances because squeezing 1% from a big program can mean a lot for Google. Uh, overall in terms of the impact versus small company. That would tell you all this you did for $10,000. It's not worth it. Right. So.

Speaker B: Right, right. So let's take it back to the beginning. If we're thinking about the scrappy startup world which we've both been in, we've been the individual contributor, we've been the one that wears every single 50 million hats that we have to. We've had to do all the things. What is it from that point? What do you think tends to break first when you're going from a starty scrap up and, and you're working your way up and scaling the company as it goes? Is there, do you see a difference between scrappy startup to maybe your series A, B, C2 Enterprise or that level of like a certain thing breaks at every stage or is it the same thing that breaks every time you try to scale?

Speaker A: No, that's a great question.

Speaker B: Um,

Speaker A: I would start. It's interesting. There are different angles to take for it. But let me start with a few of these. First of all, if you think about, you know, I mentioned that in a bigger company, um, go to market is led by revenue, operations or strategy. Um, you know, but if you look at the full journey or life cycle of a company, early stage startup, the founders are going to be the ones doing go to market. They're not going to.

Speaker B: Right, Absolutely.

Speaker A: That's why they bring like someone, an analyst to just uh, or an admin for Salesforce, just.

Speaker B: All right, do the reports. We're good.

Speaker A: Exactly. Do the reports. Build some Know opportunity stages and we're good. Uh, then you know, the startup grows. You're appointed to uh, stage A, csa, B, etc. Um, they're going to hire a large sales team. Founders have other things to do than just drive to go to market and usually they're going to ask the sales team to be in charge of go to market. When it comes of course to sales. Right, Sales, uh, and marketing maybe as a combination, um, they don't always equipped with the um, tools or the understanding from a process point of view and best practices how to build for scale. They will build to sell. But what's right for you to sell right now doesn't mean it's going to be right for you in two months. And that's where I think the friction starts when sales is pushing. You're still working with those revops admin at a very junior level and sales CROs, CMOs will come to them, tell them just build this dashboard, just add another process, just put this automation, just

Speaker B: let's get this, put another checkbox in. We're good.

Speaker A: Exactly, we're good. Um, and that's where I think the biggest issue, you know and fast forward two years later they realized that they created a Frankenstein, a monster of uh, an infrastructure and processes that no one understands, no one can really drive insights from. Um, it's very hard, you know. And also in these companies people come and go. So whatever someone did two years ago, no one remembers it and they have, they're just following process that they have no idea even why. Right. I think that's the bigger, the biggest. And that period can take a while for companies right until they realize okay, we actually need people to understand go to market and then also make sure that they understand that it's actually revenue operations that can actually give you that because you need people that can combine understanding of the operational side can be, oh, let me look at the numbers, let me understand the reports. I also understand how sales processes work but then they can translate that to based on that this is my go to market plan, this is how I'm going to implement that and also be able to lead that end to end. You know, I'm just going back. One of the biggest things I also noticed at Google is that every rev Ops person had great project management skills as part of the expectation that you can lead end to end project from ideation, design, development, implementation, adoption. Like I mentioned earlier, trench management. Um, and those are things that come later when the company, either the company breaks or they understand that hey I'm not putting everything on RevOps. Right. There's a lot more people involved. But understanding, investing in RevOps, getting a strong RevOps leader, uh, that's where usually companies will start. Understand, you know, oh, a director of RevOps is not the right level to support, you know, with five people, a team of 500 sellers. And one of the things that was last thing is that Google, there was always a correlation. If the sales organization grows, RevOps grows proportionally. It's not like that in smaller companies. They usually kind of lay to understand, hey, five people cannot support 500 people. There's gotta be a better ratio there. And we have to understand also how do we restructure that. And that's where they make, they start making the shift to oh, we need the VP of revop, someone strong, that someone that has multiple experience, multiple companies with different flavors that can kind of say, hey, this is what's right for us and build a roadmap, you know, sit with leadership. These are things that usually take a long time. And that's where, you know, in between that early stage founders only to that vp Rev Ops, that's where usually things kind of uh, go all kinds of different directions. And then it's on us to come and try to fix it.

Speaker B: Oh yeah, absolutely. And I think part of that too is figuring out, because like you said, I think in the beginning is sometimes when you're in that scrappy startup, founder led, they realize it too late, everything is already broken. You've got your Franken stack, you've got all these problems and you don't know why, because it's affecting revenue, it's affecting customers, it's doing all the things negative. At uh, what point, proactively would you say if you were to advise just whoever's listening, if you get to this point and you see this, bring somebody in now. And second part of that question, because what I found too is like scaling a RevOps team. Your company, unless they see you valuable, they can consider you admin overhead. They don't want to spend money on RevOps because you're not a seller, you're not producing revenue, you're supporting revenue, but they consider you more of that overhead, admin cost. So I do see that balance between both of those happening too.

Speaker A: Yeah, I would actually like to talk about that a little bit. Um, earlier when I talked about impact, I meant impact in the context of um, rev Ops LED initiatives. Meaning one of the things, again, I'm bringing Google because for me it's have a lot of best practices every Initiative should have demonstrated impact. You know that ideally tied into dollars amount. Right. Uh, and they were able to do it across all the RevOps initiatives. Right. It doesn't exist in a small company. And that's why to um, your point, leadership perceives Revops as overhead, as admin as you know you just, you're costing me money because I need to pay more for Salesforce. Keep telling me I need more licenses, I need more this, I need more that. Um, and those are the things that I feel like you know coming from Google to you know right now I joined Sequoia and smaller company is you know changing the mindset of uh. If you take over a team that is perceived as tactical first thing you need to more operational. First thing you need to do is to kind of think okay, what are the. How can I create a roadmap of projects that I can tie a direct line to business impact and by that one, justify more investment in RevOps. Uh two, make sure you get a seat next to the table when they talk about go to market. Right. Those are the things like I mentioned earlier, it's not a given that RevOps should be your go to market. Right. You have to prove that if you need an initiative, I will give you, I uh, will get you, you know, uh, what you need to get. But you should never forget the backbone of RevOps. You start. It's not revenue structure. It started as rev ups. You need to remember operationally you have to be excellent and on top of that build that layer of strategy. If you just stay in strategic side there's going to be a disconnect to the upside and it's not going to drive the results that you're hoping to get.

Speaker B: Yeah, I would agree. I always like to use and I, I think this is like the token word for RevOps holistic. You need to have that holistic view of everything. The holistic. You need to have skill sets that's holistic. You need to know what's going on in a business from all angles because that is the only way you can work on both sides of strategic and, and tactical to be successful. So at what point does complexity and we can tackle that definition of complexity start hurting the revenue instead of helping it in whatever stage that company is in.

Speaker A: Yeah, uh, I mean we talked earlier about you know creating a ah, Frankenstack. Uh, right. Um, when you know you Bill I will give the best example. When you go to for example your pipeline and you open one stage of opportunity and you see 200 fields there and you ask people and they have no idea what all. You know, there's no context and there's no, you know, any documentation of why we have them. That's when you know something is wrong in the interior kind of.

Speaker B: Or you're, or they're blank. No, nobody's filled them out and they've been there forever.

Speaker A: Exactly, exactly. If you run a report, it's going to be completely empty and you don't know why, uh, you have it there. Right. Um, so that's usually when you kind of try to, you need to understand, hey, um, you know, from a seller perspective specifically, you have to simplify things for them, um, as much as you can. Um, but the thing is those fields usually didn't come, um, there just because sales asked for it. Usually sales asked for less. It's more because finance need this, marketing need that, you know, uh, onboarding customer success. And when you don't have that leadership mindset of does it make sense from scalability perspective? Is it just one off field that I'm adding and no one will use it a year from now? Should we even do it? Are there better ways to do it? Um, that's where usually you need uh, uh, uh, a leader to come in and kind of make sure they do a cleanup. Um, I'll give another example. Um, over customization, right? So you know, smaller companies, it's funny, you know, I've been to companies when you have a team of 50, uh, an org of 50 and you know, each team has five people. Every team of five people get their own customized record file, um, which, which was funny especially now going to Google. And then you see Google, you have tens of thousands of people in the same organization, but different teams, different, all of them on the same processes. Because Google said no, if I need to expand to a new market, it's a copy paste. Um, I'm not gonna. Because I can't spend time on customization. Tens of thousands of people in different programs using the same infrastructure. Maybe you can allow a tweak or a tweak there, but usually the tools team is very adamant about there's gotta be scalability behind it. We cannot over customize the system in an org of tens of hundreds of thousands of people. Basically.

Speaker B: I love hearing that. Like, I almost feel like we're gonna like pin this right here, this whole part of this, because it's like most people don't understand that because they think the bigger the organization, like you said, all those different people want different things because we see it at smaller levels. Everybody has their own thing. But to know that you know a large organization like that can actually run the same process, the same stuff, the same way everybody's doing it. I mean that again goes to show like that is possible and it's being run by one of the biggest companies in the world. So that, that is actually really kind of cool to hear. Do you think? So I'm going to pivot a little bit into the topic of love that everybody loves to talk about right now is AI.

Speaker A: Two letters.

Speaker B: So how do you think AI is going to differentiate between small mid, you know, large market companies now? And I know we can go so many different angles with this.

Speaker A: Yeah, um, it's interesting because you're actually going to see bigger from my experience bigger or faster adoption of AI in smaller companies than larger companies. Right. Um, I would agree the because for small companies a the cost is, is you know kind of ah alliance with their size, um they can quickly kind of understand is their value. Yes. No. And then I'm not just not going to renew with you next year. And also they care less about, I mean I'm not saying they care less about data, they're less aware about data security than larger companies. Right. Um so Google for them every time the AI comes out they're going to check do we even want to for them to have any kind of visibility to our data. Right. That's number one. And then what's how feasible Memory. I talked about change management. Right. How many times in small companies do you implement a solution then just realize no one is using it. Again the cost is minimal. One year you're done. No one is using it. A company like Google if you try to you buy tens of thousands of licenses, you spend millions of dollars. Right. And you can't just afford. Oh okay. No one is using it. I'm just. No, because you just wrote off like millions of dollars in contract on told no one use. Right. They're much more cautious about uh those type of things. Um now going back to how can AI drive value. I um, think it's harder for bigger companies because bigger companies they're going to have an army of their own dedicated go to market and those AI tools, they say they're flexible but really this will solve workflows, this will give you gong video recordings but it's not. I'll give you another example. When I joined Google specifically for my organization uh they just uh, they had Salesforce the CRM and then it decided to move to an in house CRM. Now that CRM was terrible at the beginning. Um, but they built it around what they needed. Right. So fast forward after a few years it became kind of the much more robust and everything was calibrated around what Google needs. It's not just oh, uh, let me work with Salesforce, let me, you know, yes, you can customize it endlessly but it's not really a uh, tool that was built from the get go from the infrastructure, from the ground up thinking just Google go to market. This CRM tool probably not going to work for any other company. Right? So these are the things also important to understand that if you have such a complex organization like Google, they would expect a uh, go to market solution that only addresses their go to market needs. Right. And that's why most likely they're going to build something on their own. It's very rare for the Google, you know, especially in large organizations within Google to go to an AI solution, um, just because that lack of uh, connection, um, to what they really need.

Speaker B: Right. So what's your AI go to right now? What are some of the AI things that you're working on?

Speaker A: Um, you know the, I think the, there's not one solution that is right for everyone. Right. Um, I would start actually more with the framework that I can put place because as we all know right now there are hundreds of solutions, AI solutions, targeting sales, targeting rev ops. Right. Um, the goal here, if you remember earlier I said you have to drive business impact first is less about oh, I want a brand because it's, it's a good brand. Like GONG, for example. Right. I'm not saying GONG is great and we all need some video recording for.

Speaker B: I'm in the middle of a GONG implementation. I cannot say anything but great things about them.

Speaker A: Yeah, so, so that's great also companies. Um, but the, the thing is that if you don't understand first of all as a rev Ops, uh, what your company and literature cares most about, you're just gonna, you won't be able to show the, the value and show the impact. Right. So the, the approach for me is before you go and implement RevOps, before you go and implement solutions first understand what are the things that leadership would value the most and why and then try to kind of create a few buckets and then look at all these hundreds of solutions that are out there and try to kind of say okay, what falls within those, what do not. Okay, so you know, even if it's a great brand, but if it's not within those buckets literally would prioritize right now. It's going to be much harder for you to then show the value and then justify why we even invested in all those things. Right. Uh, so that's one, um, number two and that's an advantage again in smaller companies. I mentioned earlier that Google does kind of a proof of concept, a small sample. It's a much, it's actually even easier in, in, in um, in a smaller company. Right. You can, in a matter of just a few weeks you can implement a solution in much small scale. A, make sure there's adoption, B, see if the results drive the impact, business impact terms of revenue that you were hoping for and then justify, let's buy more licenses, let's you know, scale it across all the users or not. Right. But then it's much more, you need to be much more uh, uh, risk averse in those, in terms of those things. Um, so those are so, so that's kind of the approach. And also don't go after too many things, right. Prioritize based on business needs, uh uh, test, have a few pilots maximum in parallel and have a backlog. If you need more, then bring more. But after you drill adoption for some of the ones that you already have, uh, end of the day the business, you know, every year when you do business plan they're going to come to you and say hey, let's go over all the tools you have right now, justify the cost of each one of them. Uh, you have to be ready for it. If not it's going to work against you. They're going to, you know, back to earlier in our conversation, going to perceive rev ops as you're just wasting money. You just, you know, you're money spender. I don't see the value there. So long story short wasn't a long answer. Understand the value first before you invest for your specific company. Not just because everybody's using gong go and go, you use gone.

Speaker B: Yeah, right, absolutely. And do you think that scale is actually a disadvantage to adopting AI with robots?

Speaker A: Uh meaning like is it harder for Google?

Speaker B: Yeah, like do you think. I guess. Do you think that adopting AI you kind of touched on it with that point? Because I'm feeling the pressure right now because again you know at Motorola where I am they have their whole AI segment under Motorola same similar to Google. They're driving again the security, the data and I have my own business use case in my department where I'm like I want it for this and I want to be able to use it for this. They're like well you might not be able to because it doesn't fit into their you know uh, plan. It doesn't fit into that scalable big high level plan of what they're doing. So I think that um, that scalable part versus you know, that scrappy startup, you can go get whatever AI use, whatever, ah, AI probably nobody's locking it down or blocking you and you know, you can kind of do whatever you want with it.

Speaker A: Exactly. And I would say again I know I used that framework earlier when I said you know, scalability, optimize for processes, data and impact. Let's remember that A.I. um, creates data. Right? So going back to your scale, let's say you implement Gonk for a hundred thousand people. Who's going to look for everything for those 100,000 people? How would you even measure, you know how you get those insights from 100,000 people people versus a team of 200. It's much easier to consume for leadership. Right. So a company like Google, you can't go to leadership and say hey let me show you gong results across a hundred thousand. Right? It's going to be lower level. They're going to, you're going to break it down to region things of such it's not always going to cascade to leadership and it's much harder to kind of demonstrate the value of those things. That's why scale can work against you when it comes to AI because the data is just too much right to consume at the leadership level. Um, which is and again a component you have to evaluate. If you, you're not able to get leadership buying from any tool you're eventually, if it's, it's the scale or whatever other reason is would stand your way in the longer term. Rethink about it if it's, if, if it's worth it. Because if again you can have the best brands in the world if leadership is not bought in, it's going to be very hard for you comes renewal time to even justify that.

Speaker B: Absolutely. So do you think now that we've hit a couple of these things with RevOps in general? This is more of a general question on your overview of what you're seeing in RevOps because I know I've seen so many different hey, this is what revops looked like five years ago, three years ago, last year and now I'm seeing different models pop up on LinkedIn of what does it look like with AI and seeing a lot of go to market engineer being under the RevOps bubble. What do you think Revops in itself, do you think it's becoming too complex. Do you like, what do you envision this whole RevOps thing kind of turns into over the next, I don't know, 12 months?

Speaker A: Um, it's a great question. Um, and I don't think it's only a RevOps. I think every function need to understand the role of AI, uh, within their function. Um, that being said, you also need to um, uh, make sure you understand if something, you know, you mentioned go to market engineer is really a new concept that changes the entire industry. I'm not saying go to market engineers or not, but. Or is it just a buzzword or repackaging of something just to be able to sell more because the company decided,

Speaker B: oh, let's a rev Ops person, that's great at AI.

Speaker A: Yeah. Right. And um, I think that's where companies need to lean more on, um, more tenured people that been around end of the day. Um, understand that the main, for me, right, the main role of RevOps is um, to be the bridge between sales to everybody else. Right? The if you lose that ability to translate sales to the outside world and translate that award to sales, doesn't matter if you have AI, if you run reports, there's going to be a disconnect and you lose your ability, uh, uh, to influence an impact and also perceive, like I said, as a go to market function, not just as a tactical report running. So as such, um, I would take that understanding of where rev apps should play and kind of say, okay, are these tools really help me to be better, uh, doing that within a given company or not? And that's how I'm going to evaluate, uh, those things. Um, and again, I do think though that it's important and you know, that's how I got to the RevOps alliance and you know, go to other networking events. It's important for us to also be very much engaged in all kinds of forums, uh, to learn about the best and you know, new shiny things that are coming in, but also leverage your experience to kind of understand. Is it really something that m, you know, drives impact? Uh, is it really something that drives scale? Or is it just, you know, another company that looks to make revenue and just repackage it and created a new concept of a new function that should sit under RevOps? Yeah, that's my thing.

Speaker B: That's a very good point. Yeah, yeah, that's a really good point because I kind of do feel that way. It's like you're still going to keep doing what you've been doing in this role, no matter what you're just learning more skills, you're upskilling yourself. You're continuing to evolve and grow just like the roles does. But it doesn't necessarily change the ultimate function of RevOps.

Speaker A: Exactly, exactly.

Speaker B: Awesome insights. Okay, so now my off topic total question is what are some parting words? Like words of wisdom, things that you live by, advice, anything like that that you would want to share.

Speaker A: Wow. Um, so I'll go back to, you know, my, my word advice is usually for me 10 years ago, right before Google I would say, um, myself back then was someone that just thought my role starts and ends with, you know, reports ops, optimization of processes, CRM, admin tools and things of such. Um, and my advice to them is that that's actually the biggest trap. You don't even if you feel like you got it all, everybody loves you because you run great dashboards. Uh, longer term the value won't be there. Uh, because to your point, someone can come and create better dashboard. Someone could come and ran faster. Right. Your experience could only be valued if you translate that into go to market strategic level that drives business impact. That's only when leadership really perceive the value of the rev ops function in general and yourself within it. Okay, so I would say start thinking about how do you move from being tactical to strategic. Start thinking about how to move from being reactive, just waiting for someone to ask for a report to being proactive. You have to have a roadmap of initiatives you want to lead. All those initiatives would have impact, direct line of site to business impact. Uh, you have to be able to interact. You have to have executive presence. Like a lot of ops people, they're just like, oh, let me just stand behind my dashboard. I run numbers and I'll ping it to your back. No, get outside your comfort zone, interact with VPC levels, engage with them. And again I'm talking to myself back then because you need to learn also how to be able to communicate to that level concept that are rev ops but in a way that would matter for them. Right. That would uh, make them understand that oh, it's worth making more investment and worth actually having you next to the table when we talk about our next go to market, uh, strategy. Um, so those are the things I would probably kind of think especially for those people that been in RevOps five to eight years and. But don't didn't see kind of a best practices in a large company that uh, where actually RevOps should be positioned within a company.

Speaker B: Yeah, I love that. That's great advice. So uh, you know, I think that's great advice for anybody getting started in Revops, still moving through their career in Revops. Definitely. Stuff that we always talk about all the time. So thank you so much for joining me today. And I'm super excited that I was your first podcast.

Speaker A: Thank you.

Speaker B: I want to thank you for taking the time. It was great chatting with you again. Always great catching up. That's another episode of Revops Unboxed. It's with me, your host, Tana Jackson. Click subscribe like. And all of the good things on YouTube, Spotify and Apple. Thank you. Bye.