Lean RevOps with Global, Contractor-Driven Teams and AI Acceleration

Outline Summary: Lean RevOps with Global, Contractor-Driven Teams and AI Acceleration

Intro This transcript centers on Steve Denner, VP of RevOps at owner.com, and a host exploring how to build a high-output RevOps function with minimal in-house admins/developers. The conversation covers lean structure, agile foundations, remote-work advantages, contractor and agency leverage, and AI as a force multiplier. The takeaway is a blueprint for modular, scalable RevOps that blends in-house leadership with external specialists, all while maintaining accountability and clarity of purpose.

Center

• Lean definition and structure

  • Lean is reframed from disorganization to purposeful agility.

  • Right-sized, agile execution with increasing structure as needed.

  • High-leverage in-house roles are prioritized; external talent fills delivery gaps.

• Remote work and talent access

  • Global teams across Eastern, Mountain, Pacific, and Asia-Pacific time zones function like a distributed company.

  • Remote work expands talent pools and enables quarterly resets in capabilities.

• Key implementation mechanics

  • Agile mindset adopted eight months prior, emphasizing fast impact and clear documentation.

  • In-house hires focus on strategic roles; contractors/developers handle execution with clear handoffs.

  • Documentation, onboarding packs, and a central repository streamline contractor integration.

• Onboarding and course for contractors

  • A structured onboarding course accelerates productivity from day one.

  • Pack contents include stack, ownership, processes, sprint cadence, definitions of done, and roadmaps.

• Evaluation and partnership model

  • A robust hiring scorecard and project-management-led interviews are used for contractors.

  • Standups and transparent communication reveal fit and accountability early.

  • In-house product owners lead functional domains; data/analytics and enablement accompany them in pods.

• Roles that stay in-house vs. outsourced

  • In-house emphasis on product owners for four customer-journey verticals, plus a dedicated compensation/quotas lead and a project manager.

  • Outsourced specialists and agencies fill specialized skills, with a framework to integrate them into the core RevOps function.

• Artificial intelligence as a force multiplier

  • AI is still in early yet rapidly expanding stages for RevOps.

  • Beyond enterprise tools, AI-native capabilities and external tools (e.g., LLMs) enable data cleaning, list building, and faster user-story/QA script generation.

  • AI can automate mundane tasks, optimize quota setting, and improve regression testing by better story design.

• Strategic leadership and growth mindset

  • RevOps leaders must own the growth model, align with company goals, and articulate value to stakeholders.

  • The most valuable RevOps leaders connect high-level objectives to day-to-day roadmaps, ensuring leadership cannot be outsourced.

  • Building a durable, scalable function requires continuous leadership, governance, and cross-functional alignment.

• Career trajectory and philosophy

  • RevOps often emerges from diverse backgrounds; leadership hinges on building a function, not just delivering work.

  • The path to senior leadership involves defining must-be-true company priorities and championing them cross-functionally.

Outro Steve and the host conclude by affirming that lean RevOps is about intentional staffing, scalable processes, and disciplined use of AI. The model centers on in-house leadership around product ownership, supported by agile, well-documented external resources. The vision is a resilient, high-output revenue engine that scales with contractor networks while maintaining accountability and strategic focus. The conversation ends with mutual anticipation for future updates, benchmarks, and continued collaboration.

• Key takeaways: prioritize product-owner-led structure, invest in onboarding rigor for contractors, embrace AI to remove bottlenecks, and treat RevOps as a strategic, accountable, growth-focused function rather than a cost center.

• Final note: the journey toward a lean, scalable RevOps organization hinges on disciplined governance, continuous improvement, and a willingness to adapt with technology and talent.

Full Transcript

[Music] Today we have Steve Denner, VP of RevOps at owner.com. Steve, really excited to have you here because you're diving deep on something we at lean scale are really excited and passionate about, and that's building your RevOps team in the leanest way possible while still maximizing quality and output. And I think you've started this with something really interesting that you have a team of zero admins and developers that are FTEES in-house yet you are still building a high octane revenue function at owner.com as you guys have been scaling like crazy. Yeah. Um it's been an interesting 12 months uh for sure and uh I c I certainly wasn't in a position to be able to build my team in this way at this time last year. Um but I've definitely found uh that there's a big difference between what a lot of us say when we're starting out when we're on small scrappy RevOps teams and we say we're lean, we actually mean that we're pretty disorganized. uh we don't have a lot of great structure. Um and so the definition of lean has definitely changed for me in the past year. Uh really adopting agile, you know, right sized for where we're at in our journey and then just continuing to ratchet up the structure as needed. And that's really what kind of opened my eyes to the fact that for the FTE hires that I need to make, want to make, want to ask the business for, um, they're best spent on the most high lever strategic roles. And actually, it's the structure of my team and the way that we run it that allows me to go find the best Salesforce developer talent anywhere. um and make it really easy so that you know they're having high quality stories that they can execute on and we can put out the best work possible and really like multiply the output compared to the headcount that we have. Absolutely. I think the older way and I'll use myself as an example. Um before starting Lean Scale, I ran RevOps at three fast growing tech companies and I had in-house admins, in-house developers, deal in-house analysts, like you name it. I had um really really big teams. And I think at the time I didn't really have a lot of options. At least it felt like during then there there weren't a lot of agencies around at the time. um it was a little bit more difficult for uh me to find like contractors that were good. So I think things have changed a lot. I think a big proponent of that is remote work. I know it's kind of old news, but I do think we're still seeing the impact that remote work is having in the labor economy. And I think some of the acceleration in technology too, it's really really hard for one person to keep up with things. So finding the best talent that can change on like a quarterto quarter basis. Yeah. I mean, even believing it was possible to, you know, run a a welloiled machine with people in all various time zones or all not in even in one city not coming into the office every day. like it was pretty hard to imagine at one point. So, um you know, I almost like have taken for granted and forgotten to some degree like the the impact of remote work on my current situation. Like I have people in I have people in Eastern Mountain Pacific, Asia Pacific, like I'm I'm all over the place. And so we actually function like a like a global company in a lot of ways. and and that that does just have such a huge impact on it. The the belief in the possible I guess came from the rise in remote work and we're definitely taking full advantage of that. No, it makes a ton of sense and I think there are things you do have to have in place like to have people in different time zones. You're not in the same room communicating and talking every single day. I do think it requires a level of structure. Um, so before someone thinks like, oh, I can just outsource so many things or bring on this global team, what are some things that you've implemented that have enabled you to operate in this way? Yeah. Um, this is when I really get into my hardcore belief in agile, which is only eight months old for for us at at owner. But um you know I've I've hired one Salesforce admin developer off of Upwork and I've brought in you know uh a like pretty high-powered Salesforce consultancy. And the thing that the two of them have in common is that like the ability for them to come in and make an impact quickly and the quality of work really depends on what I give them to start with. Like what documentation do I have? what system do I have? What process do I have? How do I teach them how to communicate with us? How do I teach them what's important in the business? Like there's vastly different degrees of uh you know cost to you, but it really comes back to that same thing. And I had a situation uh around this time last year where I was being the old kind of lean where I was just, you know, running as fast as I can, pretty disorganized. Some people call that just under staffed and underresourced, but there's a difference. Some people do call it that. Yeah. No, I think there is because mentally um like if we were to if we were to be at a conference with a hundred of our peers, there'd be some people that learn to take pride in that, right? that they just kind of go as fast as they can, ship as much as they can, and uh almost just because it's hard to figure out how to deliver for the business and build these systems. Like that's really hard to do to not lose a step and to not have pe have prying eyes kind of asking you, hold on, you're building what and why? Like what's that going to do for, you know, the delivery schedule that you promised us and the goals of the business? Like that's really hard. I think a lot of people end up like falsely taking pride in the fact that they just kind of run a million miles an hour and ship whatever they can even if they are underst staffed or under structured to do so, right? And I think that was me like last year and bringing in uh you know I brought in some consultants to help with some very specific work actually like they were supposed to work on one thing very specifically. when they asked me what my project management structure was, I kind of said nothing that I'm like very proud of or like really want to share with you. And um it's a long to but like I just didn't I just didn't like I was like is it even worth me telling you cuz like I know it's not going to be good enough for what you want to do here. Um and they just sort of said hey like are you willing to just implement agile? And I was like, "Yeah, I'll do it absolutely boiler boilerplate." Like I just submitted to it completely. And um that was a huge eye opener because my engagement with them ended up getting the work done that needed to get done. But actually the largest amount of value was changing how my team works. And now I'm kind of like obsessed with being ahead of the curve, with being with being able to deliver or or have my team operate at a further level of maturity than I probably would otherwise need to, but not because just for the sake of it, for the bureaucracy, but actually because we find better ways to do it. I kind of just try to look down the road and and find that next thing. Um, and that's really like what now has me in a position where I could structure the team in such a way where if I need to bring on two extra Salesforce devs, like I have a way to do that. That is a known thing that my team does. You're like, okay, assign them that course for how you onboard RevOps at owner. Um, here's the home base with all the what good looks like documents. Here's the board. Here's the documentation repository. take a few days, get comfortable with that. You start on QAS on Friday and next sprint you're in. Um, and I think that it kind of like whether it's bringing on like a couple individual developers or like if you were going to bring on an actual agency and like go and do like a very important engagement. Um, it really starts with like how you're organized and seeing that as a strategic lever for yourself. uh not and like being able to carve the time out for that versus just like really just only being able to think about the next thing that you got to deliver for the business. Can I go back to something that you said because sure since the beginning of lean scale till now I have never had one of our engagements give us a course of how to onboard your agency internally and load us up with a bunch of organized documentation. Like normally we're begging for those things like, "Hey, we know we need context. We don't want to waste a bunch of time with you guys scoping. Like, let us do homework. Let us do homework before we even get started." Um, that's pretty incredible that you have it organized to that level, knowing, hey, my strategy is I'm going to need to rotate in specialists and high quality contractors and agencies to keep iterating and grow to where.com needs to grow. Um, but to have that level of foresight of how to onboard them in is really powerful. What for somebody, I'm going to send this to all of our clients, by the way. What would you um recommend putting in that course? Like what's in that pack to get somebody up to speed on owner.com and make sure, hey, this contractor's productive day one. You know, I think like if you go through and you write out the subheadings of what sections that course should have, it's going to pretty quickly tell you where your deficiencies are as a RevOps group. Like if you imagine yourself walking in day one and needing to be productive as fast as possible because they're spending your money learning otherwise, um it's really going to like it'll tell you, but um you know it's it's the basics. It's the things that are that you don't want to burn cycles with your high leverage uh you know folks that you're bringing in to help you with something very important on like so you're you're going to want to be telling about tech stack you know all the personalities within the business who owns what who to go to for what. Um even just like a copy of the most recent version of your agile working contract. When do we meet? How do we meet? what are our definitions of done and ready and everything like that. Um, as much detail as you can provide about your system, uh, where work gets done, what your road maps look like, just literally everything you can provide. And if you like any anyone of your customers could start reaming off these subheadings and then it would be pretty evident which ones you needed to um, round out prior to bringing in the the the experts. But I mean, that's really what it's about, right? Like you're bringing in somebody to do something very specific that has a very like tangible value for you and your business. You know, if you can lop off the first number of hours getting started, which you're paying for anyway, then that's like a no-brainer. No, it makes a ton of sense. And I think a lot of companies, they're going to be built this way. And I don't know there's a lot of other other industries where this is relevant like the whole the company doesn't in-house everything. They're very used to like building strategic partnerships to build components of the company as they grow and scale. Tech I feel like has historically done a lot just in house. Um, yeah. And I think since remote work, there have been there's been a massive increase in how many agencies have popped up. And I'll tell you personally why because I could not have built Lean Scale if I was in an office. I had to take some client calls because I did it on the side when I was, you know, working full-time somewhere. And I wouldn't have I wouldn't have even had the courage to like go build it um if I wasn't working remotely. So, I do think there's a lot of people out there who are still like maybe thinking about doing that, building an agency around really specialized skill sets. Um, so I think it's going to pop up more and more. But what it also means is as a lean startup when you're thinking about, hey, our north star is probably revenue per FTE. Like how efficiently can we grow this company? What has to be inhouse? And I'm going to ask you that in a second. like what are the roles that we really want to make sure are in-house. It's really tough to outsource leadership. It's really tough to outsource accountability. Like you can't ask an agency to do that part for you and give guidance and advice but not make the decision. So what do I do to build the other needs I have on execution? And I really like the foresight you have to say like, hey, this is going to be part of our strategy. We're going to be onboarding people a lot and to have the infrastructure to do it is is really strong. Yeah. Like one thing that like kind of strikes me about what you just said is revops can mean so many things in so many different places, right? And anytime that I am interviewing for an FT role, like you have to level set and say like, okay, what does this what how did this fit into your organizational design? Um, but that also provides like a really interesting opportunity which is like you have a lot of different types of organizations to learn from because there's no real blueprint for how yours is supposed to look. So if you're going to think about, you know, who's the most effective at using specialized talent and agencies and things like that in your typical org, it's going to be your marketing group, right? So go learn that from them. and then look at an IT group that's way bigger than like my company but um go look at how an IT group organizes itself like what can I learn from them okay so I'm going to pull help desk from there I'm going to pull specialized agency from marketing I'm going to pull agile from you know product let's say um there's a lot of opportunity to just sort of like look around and make the rev ops function what you think it should be based off of your needs not necessarily like there isn't a blueprint as much because of how different it is and how it fits into every organization, right? No. And and some of those things like in marketing, they'd have a brand and style guide that they would give to somebody they're bringing like, "Hey, this is these are the colors, the fonts. You don't have to like have them guessing about what that type of stuff is." So, as a RevOps organization, we should be organizing what that means for us. So, when we onboard people, um, we can do it efficiently. Steve, what type of roles do you think have to be in house and where do you invest your FTE dollars versus bringing on agencies and contractors? Yeah, like I would I will spend uh or I will go out and fight have gone out and fought for uh you know product owner type roles in agile speak. So if I picture the customer journey of our entire business um you know starting at growth marketing brand marketing all the way through this customer success and support uh I'm going to divide that vertically into four categories and I want a product owner for each one which um amounts to somebody who literally owns that piece of that that um map that flowchart, that process is theirs. And obsessing over how to make that better for customers, the company, and the employees that work within it. Obsessing over that every single day is their job. And figuring out where we can get a half point of efficiency here and there to, you know, map towards our company strategic goals. That's exactly where I spend have spent the majority of my headcount um in the past eight months and I think it's really the way to go. It seems early for a company of our size probably because normally I think what you'd end up doing is having somebody who's um you know hiring more generalists trying to find people who could sort of do it all but I get to focus on just finding people who are excellent at this process and strategy piece. um and their ownership over that piece of the customer journey and partnership with the project management group and the development group is really like the the biggest unlock that I've had. The other piece is not to ignore all of the other things that it takes to make a RevOps or run. Um every single day somebody's going to be asking questions uh like your your end users. Yep. um every quarter or every month or whatever your period is uh there's going to be a commission cycle. You probably own some element of that whether it's end to end or partnered with finance. Um, and so really what I've been working with my team and it's it's been really amazing to work with them and uh start to instill this mindset of like when we come to work every day, our job is not to like do the work as much as it is to create systems that provide that value. Um, so I have one person who's solely focused on um, you know, compensation, helping me with quota setting, uh, and running an IT an IT style help desk. And we use some contractors for that as well. Um, but it really starts to stitch together the entire charter of the RevOps group because um, you're not in you don't have your head in the sand about these things that are going to happen that would normally start to distract and uh, pull away your developers, admins from what you want them working on, which is the road map. it kind of insulates them from that while also servicing your uh your team. So, it's that help desk comp planning person. It's the project manager who's full-time and in-house and then it's the product owners. Are you able to share a little bit more specifically on the product owners? I I think Sure. tip standard ways we've seen RevOps orgs built they kind of pick functional so like hey you're over all the technology you're over all the data you're over all this or they take department so your sales ops your marketing ops your CS ops are you saying something a little bit different like owning a specific part of the life cycle or owning other things that may be different than those two setups? Yeah. No, I I think it is pretty close to the functional one that you described there. But the way that I describe it to them because those things all need to work together. There's not really much sense in acting like the handoff from sales to onboarding isn't important or that the onboarding to CS handoff isn't important. And so there's plenty of times where they need to work hand inand. So I I like to think about it as like you own this piece of that customer journey and uh the borders are a little fuzzy and some pieces you have to own with somebody else. And we have basically these pods where we have a revops person, a data and analytics person and a uh and an enablement person for each one of those functions. Um, and so you can kind of see the natural progression from like insight to uh solution design to roll out to to the team. So they're they're pretty much in that functional structure that you described. Got it. No, makes sense. I think I like that one too because it pushes accountability for what the goals of those departments are too. Like hey, marketing, they're there trying to create pipeline and create opportunities to enhance the brand. like how can we support their main goals? Um yeah, I think it drives a lot of alignment. One um one thing especially if somebody's newer in a management role in RevOps is where to even find these relationships. I I mean I you have great partners, you have great talent that you found and vetted out. I've also heard absolute horror stories and have been on the receiving end of bringing on agencies that were just terrible. Um, which make it sometimes it just makes it hard for anyone to even like think about outsourcing some of this stuff. Um, but how do you find the right agency partner, find the right contractor talent, and then how do you vet them before you bring them on? Uh, that is very much a million-dollar question. I think that I've been exceptionally lucky in this. Um, yeah, a lot of these relationships I kind of like had or or at least were introduced secondhand to somebody who uh who somebody I knew trusted. But I think ultimately there is an amount there is like a risk tolerance that you need to have and you need to be able to put people in a position to succeed and show kind of their true colors and also be ready I think to move on quickly if it doesn't work. Mhm. I can't really like I mean other than name dropping some some of my folks. Um I don't really know exactly how to help with like finding the right types of agencies or partners or sourcing methods. Um, but we do definitely bring on or sorry have a um have a hiring guide and we run a full interview process and I have my project manager run it and I have him use a scorecard around you know technical ability uh ownership, willingness to speak up and uh and and just sort of like how they interact with others, the communication standards. So whatever honestly your your existing hiring scorecard looks like is is one that I would use at the individual level when I bring people on because a lot of what we do is is find contractors and then bring them into the team. Uh which is in my opinion kind of the only way it works. You can't have people that are kind of on the on the periphery and and not included um and expect that that that type of work. So you have to create that environment. And also in that environment, if you're saying, "Hey, standup is every day." And if you're going to miss stand up, then you post in the post in the channel, it's going to be evident to you pretty quickly like who is on board because I I'm I pretty firmly believe that a lot of these horror stories are less so about um you know, you got bamboozled and that person didn't have the skill. It's more about whether or not they were investing the time that they said that they were, whether they were, you know, giving you their full attention to detail and and holding up their end of the bargain. And I think if your system is strong enough, you end up seeing that pretty early. So, I guess I don't have a great question other than treat them like or evaluate them like you would any other full-time hire. Uh, but just have a little bit more of a a higher risk threshold and an ability to not waste weeks and months before you actually know what the quality of the work and quality of their character is. No, I think that makes a ton of sense. I think that's a good framework and proxy to think about. You know, whatever you would use to interview an internal person is great. Um, I don't know if you do this for your team. We do it before we hire anyone at Lean Scale. We always have them do a technical assessment. So, before we bring someone on that we're thinking, hey, we're going to put in front of clients at some point, um, we want to make sure they're legit. So, uh, we have a small project that they can do. And also before we get engaged with any companies, we always do some form of audit or something something for free. So, I would just say, hey, if you're about to engage with an agency, um, I love that. Like, put them through the standard questions. You would ask them what their skills are, how they learned them, and then also, uh, get some type of sample work out of them, too, if you can. Yeah, for sure. Agency. Yeah, the the criteria for agency would certainly be different. And, you know, the majority of what I'm doing is actually like bringing in individuals. Um although I do work with agencies as well, I just have uh kind of the one or two relationships established already. So awesome. I I know we talked about how remote work is a macro um environmental impact to being able to build revops organizations this way. Something else that I think is creating a lot of tailwind as well for keeping your team lean is leveraging AI. Um, how do you see AI being leveraged in a RevOps context and how does AI make your team more efficient and more effective? I think uh I think the story is really in the opening chapters for RevOps even though it might seem like it's absolutely everywhere already. Um, at least people are talking about it everywhere. Yeah, there is a tendency to certainly over verbalize anything to do with it. I think that obviously the first wave uh of AI for revops was whatever enterprise softwares you are using, they went and plugged it in right away and said, "Oh, here it is." And so there's that element to it. then you probably started to acquire either some like AI native tools or some some other tools that had AI built into them as part of your regular software acquisition process. Um, and then now we're kind of in this third step I think where uh companies I guess that like probably would not have been able to do as sophisticated things especially with regards to um you know how they're building their lists and cleaning their data and uh prioritizing and and building their outreach and sales and everything like that. there the tools that like you know something like a clay or whatever have have really put that in a lot of people's reach where you would have needed somebody pretty awesome on the data engineering side probably to achieve a lot of that in the past even though it was achievable and I think it's going to be really interesting over the next little while because you know even Salesforce you know has only really started to dribble than uh a few of these AI features and they're mostly customerf facing or or interfacing with the actual development within the software. Uh you know, we're still waiting for that release to be able to kind of prompt to flow and things like that. And so as a RevOps org, I think you have to look outside of the enterprise software where you develop at, you know, so like other software development and and things like that, like your product team for instance, and see how they've been impacted and imagine that that's sort of coming your way. Um, I've personally become a thousand times more dangerous because my journey into RevOps uh was not one where I ever had like a IC role. I I inherited the department while I was running a BDR or um so I've never been as skilled as my team members at really any aspect of let's say like Salesforce development or writing SQL or any of that type of stuff even just like basic formulas uh in Salesforce like that's not where I excel but now right like it it unlocks that piece for everybody um if you know how to ask for the right stuff where I'm looking at uh trying to find ways to like by orders of magnitude increase my team's efficiency is starting to think about um how can I have it how can I have an LLM kind of ingest all of the metadata from the last release that we did and all of the metadata from you know my automations my custom fields my my my flows and just say hey I'm thinking about writing a user story that does this this and this write a list of all all the dependencies that a dev would need to check into prior to creating a solution for this. As I was talking about earlier, trying to be like a step ahead on the maturity ladder um relative to the size of my team, you know, you start to think about, okay, we have a QA step, we have a UAT step. Are they just stages in my camp combon board? Maybe. like are are people just kind of going through them? Like are there standards for how the QA script is written? Are there standards for how the the UAT script is written? Do we really have true regression testing? Well, that all might be true. So, can this LLM actually write me a better QA script? And can it prevent regression testing errors at the development stage rather than you know maturing to the point where you're adding this like very lengthy very chunky testing step which really you you don't want you don't want to implement regression testing and have it catch a bunch of things that are wrong. You want to write better stories so that you don't make those mistakes in the first place. So, how can I just like avoid certain steps along the journey here is is the way that I'm thinking about it from like a development standpoint. And how can I have my team sort of start making lists of the less valuable tasks that they do every day that um you know prevent them from executing on things that we actually think strategically help the business. And how do we automate this? because there are so many ways to connect uh your data sources and your LLMs together um that weren't even possible six months ago. Um we're really looking at trying to do as much as we can to maximize the value of uh using those to keep the road clear, so to speak, for the most strategic tasks that we don't think that an LLM can do. Um but even something like like setting quotas like grab a bunch of your data from the past few months on ops and close one and attainment and quotas and throw that in into an 03 chat and you'll be astounded with what it comes up with. Obviously, like you're going to want to like fine-tune these things and tell them what their um you know, what their objectives are and and what the output that you want is, but ultimately like those are the type of things that can take something that would burn you know a day or two of your month if you're me and you do monthly quotas um and reduce it down to a few hours and as like those those type of things compound. So, it's it's impacting the customer journey anywhere you possibly can. Like, there's AI all through our stack. There's custom AI in some of our, you know, outbound lead targeting, uh, lead targeting stuff. Let's we'll keep it a little bit secret. Um, but I really see the development side of the house as something that is about to be basically overrun by this. We've just started to use a GitHub repository to store all of our most recent releases. And so that's where I was playing with having an LLM be able to be queried for that for the purposes of writing better user stories and writing better test scripts and like just you know that the platforms themselves like anthropic and Google and open AAI are going to essentially accidentally create these things just by improving their base platforms. So you have to imagine a world where all of this is available to everybody and you are going to be expected to be 10 times more uh more efficient and so your team should be reflected as such and your the way that you ask them to operate needs to be that way. Uh we're already seeing that in product groups like you can read Toby from Shopify's letter that's coming for RevOps. So are you structured to be able to take advantage of it? are you, you know, well, uh, well educated in in what can be done today because it's about to be even more front and center in all of your workflows. That's, I guess, the message. I I agree with you. I think um, it's started to come in a little bit and and I think some of the platforms like Swan Tide and Sweep and Sonar are like bringing some of those capabilities to Salesforce development. Um I do think RevOps is becoming I'd say before was like hey RevOps kind of meant 80% is like Salesforce. Um but the tech stack is getting so much more broad. Um so even at at le scale like we're not necessarily looking for Salesforce admins or Salesforce developers. We need like proper developers because if you're going to connect that with like whatever AI or LLM like our customers are using plus leverage clay plus leverage like everything else that they're bringing into the stack, you need to kind of have a broader systems management and systems thinking approach. Um yeah, but I I agree. I think a lot of the benefits that we've seen on like development will come behind the enterprise application soon. I think people should also be thinking about it similar to like if you were around in like say like 2015 and you know enough companies had adopted Salesforce and that was like using a cloud CRM was maybe not like brand new. They're over the chasm on that. But it became clear that they weren't going to create like an excellent dialing solution at that time. So you see sales loft and outreach pop up and then it becomes clear that well they're probably not going to create conversation intelligence. It's so gong and chorus pop up and you start to see this kind of accordion effect where like a million tools that are not trying to be a CRM but are firmly surrounding them or orbiting the CRM. um they all come up and then within what the last six or seven years then the accordion starts to crash together again and the category winners or category leaders in a lot of those spaces start to go vertical still outside of the CRM and you end up with a few really huge players who do everything and then AI comes into the picture and it's almost like a a new a new layer outside of that has come that is completely fractured. And um as a RevOps person, you have to sit there and think about um and you know, if you were around back then and kind of like remember what it was like to have this super fractured tech stack and you know, you got Chili Piper on meetings and you got sales loft on calls and and emails and like you know what I mean? Like just a million different things. um you've got to contend with like this new fracturing and weigh the value of it and figure out which pieces are going to be the highest leveraged ones and which ones are going to end up as category winners um and which ones give you an edge against the competition really right I wholeheartedly agree it's going to follow a similar trend I think it'll be a little bit more uh accelerated because even like I don't know if it was clear that that consolidation would happen um around 2015 2016 when like that started happening. I don't know if it was like okay clearly Gong is now gonna probably do forecasting and sequencing and all this other stuff. Um right but now since I think we've seen that and also I think the adoption of AI has gone a lot faster than adoption of cloud because all right we've seen this movie before. I better get like going quickly or I'm going to get left behind. Um and I think that's going to happen too fractured very segmented um ecosystem and then absolutely there will be consolidation in the space. Yeah 100%. Steve I think something that's really interesting for just our audience the people who listen to these podcasts a lot of them are in revops right now looking for that you know VP uh progression of their career. Um, I always find it super interesting because nobody went to school for RevOps. You know, everybody was an accidental RevOps person, myself included. Um, I was forced into it against my will, but I'm so happy I was. But I really would love to hear just your story, even if there was some like interests in like early childhood or anything that you feel like were tangential, but how you got to where you are today. I don't know what in in my childhood or anything like that necessarily would have pointed my me here. My my dad would say he's not surprised. I think uh if he uh if you were to ask him, but I think you know I ended up in a second line leadership position prior to even having my first job in RevOps. I I ended up as a BDR director running multiple BDR teams and uh RevOps Salesforce I guess in and of itself became like a way for me to be better at being a BDR manager and being a BDR director. Um because I just found it was so powerful that I could h trust in the fact that we're hiring great people who really want to be the best and therefore if I like create this new metric and put it on a dashboard that's stack ranked people are going to look at it and be like I want to be on the top of that and it was just such like a huge impactful thing that you could do. Um and I've just I guess always had a I've just always been sort of like drawn to that type of broad impact. So, um, yeah, I get into it through the BDR world and my first RevOps job was, uh, running RevOps in addition to running the BDR or so. So, it's a pretty interesting path. Uh, it's a stressful combo. It is, but you also then really are your own stakeholder for a lot of the most important things. So, you can really get through some cycles pretty quickly. Um, but yeah, in terms of getting into RevOps, I think you do have like there is no one way once you're there. Uh, and I have this conversation with people all the time. Um, getting to the next level is definitely the challenge. I think you can end up in RevOps like one of a million different ways, but once you're in there and once that title is on you, um getting into like a higher level of leadership within the revenue team, within the company, um is definitely uh a challenge because in RevOps, you're constantly torn between being the person who says yes too much and being the person who says no too much or, you know, being the person who overpromises or being the person who's underpromising is maybe another way to look at it. Um, and I think like to really really see the role correctly and have others people's not see you as a cost center but actually like a value driver. Um, it comes down to being able to build a function. Not so much like, you know, a little bit of a broken record here, but building a function, building a system. Um, being able to communicate the value of your of your team and of your function. Um, and being able to tell you tell people exactly why it's aligned with the highest level company goals. Like at my company and at anyone who's in this similar position, like you should be the person that is pointing to and most often bringing up the company's annual goals that are trying to be hit. and being able to tie every single thing that you're doing to them and having these conversations out in the open. I think that that's like the clearest way to uh advance your career in RevOps. It's, you know, with if you consider the high high value and high quality work being table stakes. Like that's the piece of it that I think is is really hard to grasp because it's so far outside of a lot of people's comfort zone if and it's so far outside of the um other pieces of the job that you think make you great which would be like being great technically or you know being able to deliver a lot of work uh in a short amount of time with probably less resources than you want. Um there is this whole other piece that takes a leap of faith which is being able to organize yourself and the people on your team and really double and triple down on leadership uh leadership and things that build a function that can operate um you know without you controlling every single aspect of it. That's like what's going to move you forward. I think it makes a ton of sense. Systems thinking outcome driven. Um, and I think what you were describing, we coin as the growth model of the company, I found when I was owning the growth model in RevOps, when I was reporting to the targets in the growth model, fully segmented, knowing the scoreboard of every single way you could cut the business up, that was when I gained an incredible amount of strategic leverage to be in the room, be in those conversations. I got brought to the board meetings because they're like, "Hey, if a number comes up that the board wants to know about, Anony's going to know it. So, we better have him in there." And yeah, owning the owning that growth model in RevOps, which you should, it's between you or the CFO. And normally the CFO wouldn't mind kicking some of it down because you have all the go to market data that they're always looking for. So I think if you can own the go to market performance to plan um that's going to really help you get to that next level and if you're building of course in the way that you're describing systems thinking outcomes driven you're not there to do the work but build the system that can maybe help you not need to work as much. Well there's always more system building to be done. So yeah, allegedly uh doesn't end up working out that way. But yeah, even even like if you have like I do a counterpart VP of data business operations and analytics like somebody who's dedicated to those numbers, there are still company initiatives that we are we call our must be trus, right? So we have this list of must be true things. Um, and I like I consider myself to be the person or I want myself to be the person who is most frequently bringing those things up crossf functionally to say this is why we're doing what we're doing and also to try and kind of like make sure that we're keeping everybody else on board. like there's an element of um you know aspiring to really make sure that if we believe these things as a company you know that we're continuing to believe them we're keeping them in front of mind. Um and there's a million other people that we have to uh you know work with and have aligned road maps with as well and so we should all be believing in them. So even as simple as just like knowing the top five must be true things for your company uh and surfacing them anytime that you're sharing a doc or presenting your w your road map or rationalizing why you're working on one thing and that's a priority zero versus another thing that is a priority one. Um I think it's just even that simple just this relentless focus on the most important things for the company. um because ultimately you're going to be the one of the broadest support functions in your business. Um and so it's as important or more important for you to be the champion of those things than anything else. I totally agree and I going back to something we mentioned in um the beginning, you can't outsource leadership, you can't outsource accountability. And I think those are some of the ways that that those show up and like you know that's how you're going to grow, that's how you're going to win. We've all decided on it. Let's have some fun with it. Let's keep it at at top of mind and uh shout it from the rooftops. And internally, I think that has a ton of value. It does. It does. Steve, this has been super insightful. I really appreciate you bringing this. I I think you're doing things in a really modern way, intentional way, and thoughtful way. Um, you know, the way RevOps is built and structured is going to, I believe, look a lot more like your model than what we've seen in the past couple years where you're keeping the team lean. That doesn't mean understaffed. That doesn't mean underresourced. Lean means intentional about who's doing what and structured in what you're doing and making sure that the time people are spending on things are optimized. I love that you're building a network of specialized contractors, agencies, thinking of ways to systematically enable them and onboard them into owner.com and making sure that they can hit the ground running. And I think you have the eye on the ball in a really meaningful way of how to leverage AI. And as soon as some of those capabilities come out, which we know they're coming, it sounds like you're going to have the team, the process, the systems, the resources, agile methodology to start taking that and just supercharging the efficiency and effectiveness you have of your team. Yeah, thank you very much. I'm hoping so. And it's going to be really exciting one way or another. Either way, it's going to be a good story. So, I um I appreciate you joining. Really excited to follow everything you're doing at owner.com and follow your career. And as things progress, we'd love to have you back. Of course. It's an honor to be on. Thank you so much for having me. And uh yeah, we'll definitely talk again soon. Thank you, Steve. [Music]