---
title: "Why Structure (Not Headcount) Builds Great RevOps"
episode: 41
podcast: "The LeanScale Podcast"
publisher: "LeanScale"
guest: "Steve Dinner"
guest_title: "VP of Revenue Operations, Owner.com"
date_published: 2025-10-29
date_modified: 2026-07-22
duration: 00:48:32
word_count: 7954
topics: ["revenue-operations", "ai-in-gtm", "gtm-strategy", "sales-leadership"]
canonical_url: https://leanscale-knowledge-hub.netlify.app/podcast/steve-dinner-structure-not-headcount-revops/
source: "LeanScale Podcast Knowledge Hub — https://leanscale-knowledge-hub.netlify.app"
license: "Free to quote and cite with attribution to The LeanScale Podcast."
---

# Why Structure (Not Headcount) Builds Great RevOps — Full Transcript

> Episode 41 of The LeanScale Podcast, with Steve Dinner.
> Published October 29, 2025 · 00:48:32 · 7,954 words.
> Machine-transcribed and **not diarized** — speaker attribution is inferred, so verify
> attribution against the audio before quoting a specific person.
> Structured breakdown: https://leanscale-knowledge-hub.netlify.app/podcast/steve-dinner-structure-not-headcount-revops/

## 00:00 — A RevOps team with zero in-house admins or devs

**[0:00]** Today we have Steve Dinner, VP of RevOps at Owner.com. Steve, really excited to have you here because you're diving deep on something we at LeanScale 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 FTEs in-house, yet you are still building a high octane revenue function at Owner.com as you guys have been scaling like crazy.

## 00:49 — Redefining 'lean': structured, not disorganized

**[0:49]** Yeah, it's been an interesting 12 months, for sure, and I certainly wasn't in a position to be able to build my team in this way at this time last year. But I've definitely found 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, we don't have a lot of great structure. And so the definition of lean has definitely changed for me in the past year, really adopting agile, right size for where we're at in our journey, and then just continuing to ratchet up the structure as needed.

**[1:36]** 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 their best spent on the most high leverage strategic roles, and actually it's the structure of my team, and the way I run it, that allows me to go find the best Salesforce developer talent anywhere, 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.

**[2:14]** Absolutely. I think the older way, and I'll use myself as an example, before starting LeanScale, I ran RevOps at three fast growing tech companies, and I had in house admins, in house developers, the old desk, in house analysts, like, you name it, I had 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 weren't a lot of agencies around at the time, it was a little bit more difficult for me to find like contractors that were good.

## 02:53 — How remote work enabled a global specialist team

**[2:53]** 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 and 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 quarter to quarter basis. Yeah, I mean, even believing it was possible to, you know, run a well oiled machine with people in all various time zones or all not in even in one city not coming into the office every day.

**[3:36]** Like it was pretty hard to imagine at one point so, 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. Eastern Mountain Pacific, Asia Pacific like 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 it 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.

**[4:14]** 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. 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.

## 04:41 — Adopting agile — the consultant who changed everything

**[4:41]** Yeah, this is what I really get into my hardcore belief in agile which is only eight months old for for asset at owner but you know I've, I've hired one Salesforce admin developer off of Upwork, and I've brought in, you know, 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.

**[5:27]** Like, there's vastly different degrees of, you know, cost to you, but it really comes back to that same thing. And I had a situation 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 understaffed and under resourced but there's a difference right people do call it that. Yeah, no, I think there is because mentally, like if we were to, if we were to be at a conference with 100 of our peers, there'd be some people that learn to take pride

**[6:05]** in that, right, that they just kind of go as fast as they can ship as much as they can. And 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 people 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

**[6:35]** 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 understaffed or under structured to do so right. So I think that was me like last year, and bringing in, 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 it's a long to do.

**[7:06]** But like I just didn't, I just didn't like, I was like, is it even worth me telling you because like I know it's not going to be good enough for what you want to do here. 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 boilerplate boilerplate like I just submitted to it completely. And 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.

## 07:37 — The contractor onboarding course (and what it reveals)

**[7:37]** And that's how I'm kind of like obsessed with being ahead of the curve with being with being able to deliver or have my team operate at a further level of maturity, then 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. 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 to extra Salesforce devs like I have a way to do that that is a known thing that my team does.

**[8:20]** You're like okay assign them that course for how you onboard RevOps at owner. 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 QA's on QA and next for it you're in. And I think that it kind of like, whether it's bringing on like a couple individual developers or like if you're going to bring on an actual agency and like go and do like a very important engagement.

**[8:52]** It really starts with like how you're organized and seeing that as a strategic lever for yourself, 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've 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

**[9:24]** 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's do homework before we even get started. 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 specialist and high quality contractors and agencies to keep iterating and grow to where owner.com needs to grow. But to have that level of foresight of how to onboard them in is really powerful.

**[9:55]** What for somebody I'm going to send this to all of our clients, by the way, what would you recommend putting in that course like what's in that pack to get somebody up to speed on owner.com and make sure it is contractors productive day one. You know, I think like, if you go through and you write out the sub headings of what sections that course should have, it's going to pretty quickly tell you where your deficiencies are as a rev ops group. Like, if you're imagining yourself walking in day one and needing to be productive as fast as possible because they're spending your money learning otherwise.

**[10:32]** It's really going to like it'll tell you, but, 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. You know, folks that you're bringing in to help you with something very important on like, so 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. 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.

**[11:10]** As much detail as you can provide about your system, where work gets done, what your roadmaps look like. It's literally everything you can provide and if you like any, any one of your customers could start reaming off these subheadings and then it would be pretty evident which ones you needed to round out prior to bringing in the experts but I mean that's really what it's about right now, bringing in somebody to do something very specific that has a very 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.

**[11:55]** It's kind 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 under 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 in scale tech I feel like has historically done a lot, just in house. 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.

**[12:33]** When 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. 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. 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 in house, and I'm going to ask you that in a second.

## 13:13 — What you can't outsource: leadership and accountability

**[13:13]** 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.

## 13:46 — No blueprint: borrowing org models from marketing, IT, product

**[13:46]** Yeah, like one thing that like kind of strikes me to about what you just said is rev ops can mean so many things in so many different places right. And anytime that I am interviewing for an FTE role, like you have to level set and say like, Okay, what is this, what, how, how did this fit into your organizational design. 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

**[14:20]** organization agencies and things like that in your typical org, it's gonna 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 go look at how an IT group organizes itself, like what can I learn from that. Okay, so I'm going to pull help desk from there, I'm going to pull specialized agency for marketing. I'm going to pull agile from, you know, product, let's say, there's a lot of opportunity to just sort of like look around and make the rev ops

**[14:49]** 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 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 rev ops organization, we should be organizing what that means for us. So when we onboard people, we can do it

## 15:22 — Product owners over the customer journey

**[15:22]** 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, or I will go out and fight have gone out and fought for, you know, product owner type roles in agile speak. So if I picture the customer journey of our entire business, you know, starting at growth marketing, brand marketing, all

**[16:01]** the way through this customer success and support. I'm going to divide that vertically into four categories, and I want a product owner for each one, which amounts to somebody who literally owns that piece of that, that 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

**[16:41]** our company's strategic goals. That's exactly where I spend, have spent the majority of my headcount 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, 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.

## 17:13 — Insulating developers with a help-desk and comp role

**[17:13]** 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 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 org run. Every single day, somebody's going to be asking questions, like your end users. Every quarter or every month or whatever your period is, 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.

**[17:55]** And so really what I've been working with my team and it's been really amazing to work with them and 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. So I have one person who's solely focused on, you know, compensation, helping with quota setting and running an IT style help desk. And we use some contractors for that as well.

**[18:30]** But it really starts to stitch together the entire charter of the RevOps group because you don't have your head in the sand about these things that are going to happen that would normally start to distract and pull away your developers admins from what you want them working on, which is the roadmap. It kind of insulates them from that while also servicing 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.

**[19:12]** Are you able to share a little bit more specifically on the product owners? I think, standard ways we've seen RevOps orgs built, they kind of pick functional like, hey, you're overall the technology, you're overall the data, you're overall 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?

**[19:47]** Yeah, no, 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. So there's plenty of times where they need to work hand in hand. So I, I like to think about it as like, you own this piece of that customer journey. And the borders are a little fuzzy, and some pieces you have to own with somebody else.

**[20:20]** And we have basically these pods where you have a RevOps person, a data and analytics person, and a, and an enablement person for each one of those functions. And so you can kind of see the natural progression from like insight to 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 to like, hey, marketing, they're they're trying to create pipeline and create opportunities to enhance the brand, like, how can we support their main goals.

## 21:03 — Finding and vetting the right contractors and agencies

**[21:03]** Yeah, I think it drives a lot of alignment. One, one thing, especially if somebody's newer in a management role in RevOps is where to even find these relationships. 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, which make it sometimes it just makes it hard for anyone to even like think about outsourcing some of this stuff. 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?

**[21:45]** That is very much a million dollar question. I think that I've been exceptionally lucky in this. Yeah, a lot of these relationships I kind of like had or or at least were introduced second hand to somebody who, 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.

**[22:21]** I can't really like, I mean, other than name dropping some, some of my folks. I don't really know exactly how to help with like finding the right types of agencies or partners or sourcing methods. But we do definitely bring on or sorry have a have a hiring guide and we've 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, ownership, willingness to speak up and

**[22:58]** and just sort of like how they interact with others the communication standards so whatever, honestly, your, your existing hiring scorecard looks like 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, 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 not included 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, stand up is every day.

**[23:34]** And if you're going to miss stand up then you post in the post in the channel. It's gonna be evident to you pretty quickly like who is on board, because I'm pretty firmly believe that a lot of these horror stories are less so about, 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 holding up their end of the bargain.

**[24:05]** 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 higher, but just have a little bit more of 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.

**[24:38]** 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, we want to make sure they're legit. So 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.

**[25:06]** So I would just say, hey, if you're about to engage with an agency, 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 get some type of sample work out of them, too, if you can. Yeah, for sure. Agency. Yeah, the criteria for agency would certainly be different. And, you know, the majority of what I'm doing is actually like bringing in individuals. Although I do work with agencies as well. I just have kind of the one or two relationships established already.

## 25:44 — AI in RevOps: the opening chapters

**[25:44]** Awesome. I know we talked about how remote work is a macro 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. 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 the story is really in the opening chapters for RevOps, even though it might seem like it's absolutely everywhere already. At least people are talking about it everywhere. Yeah, there is a tendency to certainly over-verbalize anything to do with it.

**[26:37]** I think that obviously the first wave of AI for RevOps was whatever enterprise software 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 other tools that had AI built into them as part of your regular software acquisition process. And then now we're kind of in this third step, I think, where companies, I guess, that probably would not have been able to do as sophisticated things,

**[27:20]** especially with regards to how they're building their lists and cleaning their data and prioritizing and building their outreach and sales and everything like that. The tools that something like a clay or whatever 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.

**[27:48]** And I think it's going to be really interesting over the next little while because even Salesforce has only really started to dribble in a few of these AI features and they're mostly customer facing or interfacing with the actual development within the software. 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 that, you know, like other software development and things like that,

## 28:27 — Becoming 'a thousand times more dangerous' with LLMs

**[28:27]** like your product team, for instance, and see how they've been impacted and imagine that that's sort of coming your way. I've personally become a thousand times more dangerous because my journey into RevOps was not one where I ever had like an IC role. I inherited the department while I was running a BDR work. So I've never been as skilled as my team members at really any aspect of let's say like Salesforce development or writing sequel or any of that type of stuff, even just like basic formulas in Salesforce like that's not where I excel.

**[29:05]** Now, right, like it unlocks that piece for everybody. If you know how to ask for the right stuff, where I'm looking at trying to find ways to like, by orders of magnitude increase my team's efficiency is starting to think about 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 flows, and just say, Hey, I'm thinking about writing a user story that does this,

**[29:42]** this and this, write a list of 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, relative to the size of my team. Now you start to think about, okay, we have a QA step, we have a UAT step. Are they just stages in my camp comp on board. Maybe, like, are people just kind of going through them like are their standards for how the QA script is written are their standards

**[30:18]** for how 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 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

**[30:54]** those mistakes in the first place. So how can I just like avoid certain steps along the journey here 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 we do every day that, 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 your data sources and your LLMs together that weren't even

## 31:29 — Setting quotas with AI and automating low-value work

**[31:29]** six months ago. We're really looking at trying to do as much as we can to maximize the value of 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. 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 into an O3 chat, and you'll be astounded with what it comes up with obviously like you're going to want

**[32:03]** to be able to fine tune these things and tell them what their, 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 company and you do monthly quotas, 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 lead targeting stuff let's keep it a little bit secret.

**[32:48]** 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 do 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 AI are going to essentially accidentally create these things, just by improving their base platforms.

## 33:25 — The 10x team and Shopify's Tobi letter

**[33:25]** 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, more efficient, and so your team should be reflected as such and you're the way that you asked them to operate needs to be that way. We're already seeing that in product groups like you can read Toby from Shopify's letter. That's coming for rev ops, so are you structured to be able to take advantage of it. Are you, you know, well, well educated and 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.

**[34:06]** I agree with you. I think it started to come in a little bit, and I think some of the platforms like swan tide and sweep and so on are like bringing some of those capabilities to Salesforce development. I do think rev ops is becoming, I'd say before is like a rev ops kind of meant 80% is like Salesforce, but the tech stack is getting so much more broad.

**[34:35]** So even at at lean 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 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. Yeah, but I agree. I think a lot of the benefits that we've seen on like development will come behind the enterprise application soon.

## 35:15 — The accordion effect: fragmentation and consolidation

**[35:15]** I think people should also be thinking about it similar to like if you're 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.

**[35:39]** So you see sales lofted outreach pop up and then it becomes clear that well, they're probably not going to create conversation intelligence. It's gone and chorus pop up and you start to see this kind of accordion effect where I like a million tools that are not trying to be a CRM but are firmly surrounding them or orbiting the CRMs. 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.

**[36:21]** And then AI comes into the picture and it's almost like a new layer outside of that has come that is completely fractured and as a RevOps person, you have to sit there and think about. And, you know, if you were around back then kind of like remember what it was like to have this super fractured tech stock and, you know, you got chili Piper on meetings and you got sales loft on calls and emails and like, you know what I mean?

**[36:51]** Just a million different things. 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 leverage ones and which ones are going to end up as category winners and which ones give you an edge against the competition, really. Great. I wholeheartedly agree. It's going to follow a similar trend. I think it'll be a little bit more accelerated because even like I don't know if it was clear that that consolidation would happen around 2015 2016 when like that started happening.

**[37:25]** I don't know if it was like, okay, clearly Gong is now going to probably do forecasting and sequencing and all this other stuff. 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 and I think that's going to happen to fractured very segmented ecosystem and then absolutely there will be consolidation in the space.

## 38:02 — The accidental RevOps career path

**[38:02]** Yeah, 100%. See, if I think something that's really interesting or just our audience and people who listen to these podcasts, a lot of them are in rev ops right now looking for that, you know, VP progression of their career. I always find it super interesting because nobody went to school for rev ops, you know, everybody was an accidental rev ops person myself included. I was forced into it against my will, but I'm so happy I was. But I really would love to hear history story. Even if there was some like interest in like early childhood or anything that you feel like we're tangential but how you got to where you are today.

**[38:45]** I don't know what 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 if he, 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 rev ops, I ended up as a br director running multiple br teams and rev ops Salesforce, I guess, in and of itself became like a way for me to be better at being a br manager and being a br director, because I just found it was so powerful that I could trust in the fact that we're

**[39:30]** 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 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. And I've just I guess always had a just always been sort of like drawn to that type of broad impact so yeah I get into it through the BDR world and my first rev ops job was running rev ops in addition to running the BDR org so it's a pretty interesting path.

**[40:03]** It is, but you also then really are your own stakeholder for a lot of the most important things you can really get through some cycles pretty quickly. But yeah, in terms of getting into rev ops I think you do have like there is no one way. Once you're there, and I have this conversation with people all the time. Getting to the next level is definitely the challenge I think you can end up in rev ops like one of a million different ways but once you're in there and once that title is on you.

## 40:40 — Cost center to value driver: advancing in RevOps

**[40:40]** Getting into like a higher level of leadership within the revenue team within the company is definitely a challenge because in rev ops 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 over promises or being the person who's under promising is maybe another way to look at it.

**[41:06]** 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. 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 and building a system, being able to communicate the value of your, of your team and of your function, and being able to tell you tell people exactly why it's aligned with the highest level company goals.

**[41:44]** 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 and having these conversations out in the open. I think that that's like the clearest way to advance your career and rev ops is, 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

**[42:21]** 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 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 in a short amount of time with probably less resources than you want. 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, leadership

**[42:54]** and things that build a function that can operate, 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. 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 and read ops, 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.

## 43:30 — Owning the growth model and the 'must-be-true' list

**[43:30]** 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 Anthony's going to know it. So we better have him in there and owning the owning that growth model in rev ops, 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, that's going to really help you get to that next level.

**[44:09]** 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. There's always more system building to be done. So yeah, that 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

**[44:42]** company initiatives that we are we call our must be true. Right. So we have this list of must be true things. 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 cross 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, 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

**[45:24]** keeping them in front of mind. And there's a million other people that we have to, you know, work with and have aligned roadmaps 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, and surfacing them anytime that you're sharing a doc or presenting your roadmap or rationalizing while you're working on one thing and that's a priority zero versus another thing that is a priority one. I think it's just even that simple.

**[45:56]** It's just this relentless focus on the most important things for the company. Because, ultimately, you're going to be the one of the broadest support functions in your business. And so it's as important or more important for you to be the champion of those things than anything else. I agree. And I'm going back to something we mentioned in 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.

## 46:30 — Closing: lean means intentional

**[46:30]** 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 up top of mind and show 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 think you're doing things in a really modern way, intentional way and thoughtful way.

**[46:58]** You know, the way rev ops 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 under resourced. Lean means intentional about who's doing what and structured and 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.

**[47:37]** 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 appreciate you joining. Really excited to follow everything you're doing at owner.com and follow your career.

**[48:20]** 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 yeah, we'll definitely talk again soon. Thank you, Steve.