E46: The RevOps Mind Behind Owner.com's Billion-Dollar Valuation: Steve Dinner

Hello and welcome to the Revenue Leadership Podcast by Topline. I'm your host, Kyle Norton, CRO at Owner.com, and every Wednesday we dive deep into the strategies and tactics being used to drive success by the best revenue leaders in the world. So join me as I sit down with revenue operators to discuss actionable frameworks that you can implement in your business today with no fluff, no sales pitches, and no platitudes.

If you're measured on pipeline, win rates, and forecast accuracy, listen up. When your product doesn't show up until the second or third sales call, you lose momentum and deals. Walnut fixes that. Gives your reps interactive demos they can personalize and use early so every buyer sees a consistent story every time. The result? Faster cycles, higher conversion from demo to op, and better forecasting based on real product engagement. Measurement, not guesswork. You ramp reps faster and close more without adding SE headcount. Go to walnut.io and hit the Get Started button to see how you can turn revenue targets into reality with the team you already have.

Today's guest is the one and only, the man, the myth, the legend, Steve Dinner, who is my VP of RevOps here at Owner. And I've actually avoided doing this episode for a little while because I didn't want it to feel like such shameless owner self-promotion, but a bunch of people have actually specifically requested me to do this episode and get Steve on as a guest because I tend to get so many questions about infrastructure and tech stack and RevOps, given what I talk about a lot publicly. So I'm excited for this one. We're going to unpack what we've done differently at Owner, how Steve has built the RevOps team in a very unique and I think impactful way. And so it'll be fun. And Steve and I have worked together for almost a decade. He was a rep when I hired him to be a BDR manager because I interviewed him and he just thought in systems and programmatically. And I was like, dude, you should just come here and be a BDR manager. So he was a BDR manager for me at League, then BDR director. Then we gave him RevOps and he's become a world-class RevOps practitioner and has had stops at Shopify and is now being an owner for over 2 years and owns a pretty broad portfolio and owner, which we'll, uh, which we'll dig into. So excited for this one, my man, and welcome to the show officially.

This is fun. Really excited. Long time listener.

Yeah, thanks. All right. So we're going to talk about how to set up a RevOps team for maximum success and get into everything from your mindset as a revenue leader, which I think is unique and valuable to how you've built the team, to how you think about building infrastructure in a, in a modern way. And if we have some time, we'll talk about vendor selection and, and how RevOps leaders and CROs can be thinking about AI adoption and tooling there. But the core conversation is really around how to, how to set up a team for maximum success because I do think how you've operated is, is really different. So we'll start there and you spend a bunch of time with RevOps leaders. People reach out to me and want to talk about RevOps stuff and I send them to you and I always get messages back being like, wow, like this guy's, this guy's different. I learned so much. So maybe in a, in a couple lines. What have you done most different in setting up the RevOps function from how you operate as a leader to, to how you built the team? Then we'll, we'll start unpacking.

Well, I think what's particularly, maybe like not unique, a lot of people go through this type of a path, I think, where they're starting out as an IC or a manager. Like you might be like a BDR manager or an AE manager who has, uh, sort of just like a, a knack for operations and you, you end up taking on an operations role. I don't think that that is particularly rare. But as you mentioned in the, in the intro there, owning both the BDR function and RevOps function at the same time really forced me, I think, to remain or like keep one foot super firmly grounded in being a revenue leader. Not seeing RevOps as something that is materially, materially all that different from, you know, sales pipeline generation, anything like that. And so that I think allows you to be fairly unconstrained in your thinking in terms of solution design, in terms of how you understand and contribute and prioritize. And for a long time, up until about a year ago, I think that I really just relied on those instincts. But more recently I found a lot of freedom through org design and process that has really taken this to the next level. So it's only been about a year since we went from sort of more of like an ad hoc, ad hoc management system of, of our RevOps team into the right level of maturity in Agile and really committing to it. And I think it really helps, it really helps clarify what's important and what the day-to-day is. And it allows RevOps to stay in that seat at the table type of position within the business because you aren't always feeling like you're running around putting out fires. You're instructing to the rest of the business how you should be worked with and how you should be communicated with. And I think that it's a really challenging set of skills to kind of organically come by. But that is the root, I think, of where this comes from, uh, is not just being somebody who's been obsessed with the technology and building, although that is definitely true, but remaining like really rooted in what we're actually trying to accomplish here, which is having a really strong basis in being a sales leader on a team. That's really where it comes from, I think.

And how do you maintain that? So now, now that you are farther from that dual role, what do you do to stay entrenched in the business and, and operate from that mindset first?

I think if you were to look at my calendar, there's a lot of things that maybe I'm not at every time, but I make a pretty big effort to, and probably 30 to 40% of my scheduled week is going to be being in those different functional rituals and understanding from the rep, mostly at the, the frontline manager level, what, what the top challenges are and exactly how they're thinking about solving them. It's a really important time investment to, to be there. And also you kind of gotta love it. Like me personally, I know it charges my battery and here and there I'll have conversations that are wildly outside of the scope of my role around what we're trying to do. And because this is typically done with folks that I think are really interesting and are really great at what they do, like I find that to be a battery charger for me. And so I do just put in the work really. I try to be around for the small and the large and have like a pulse on what's happening. Throughout the business because it can also get lonely over in RevOps if you're not doing that, right? Like you can get really lost in the technical projects and that's how you lose sight of the difference between what you're building and the outcome that you're trying to achieve. I think you've got to have a really strongly founded belief that you're not trying to coerce people to do what you want to do. You're trying to build something where when you give it to them, what they want to do is the thing that is going to propel the business forward. And you can't really do that without understanding them.

And I think a related idea there is you are just trying to solve business problems. Like the, the second line leaders in the FLMs, the frontline managers come to you to solve problems that are outside of RevOps, can be coaching related or a business process or sales process. Related. And I think what you've done a smart job at is not solving everything with RevOps and trying to have a light touch with technology and, and only putting in a validation field when it's absolutely required, or, or adding more business process when it's, when it's needed. Maybe, maybe just talk about how you think about solutioning and what's different there than maybe some of the other RevOps folks that that people are familiar with.

Yeah, like maybe not different from other folks, but like something that's certainly hard to achieve because of the, of the, you have to have a certain amount of, or you have to have earned a certain amount of respect and you have to have earned the ability to take any conversation and say like, okay, I believe what you're asking for is a technical requirement or like a functional requirement. Let's jump this up one level. You're telling me what you want. Tell me what you're trying to achieve and what happens if it doesn't get done. And like anything, you really just want to tease away until you can get to the core of a problem. So that's, that's like a big part of it. I don't think that that's particularly unique, although it's hard to execute on really well. But additionally, there's solving every problem with technology can feel like what you're supposed to do. An automation for everything, a validation for everything. It can always, like, that is always an answer. Like, that makes everything look like a nail, right?

Yeah.

I think there's a lot of opportunity that goes really unexplored in diving deep on how you can get like an 80% solution. Because ultimately, if you're thinking about rep experience and if you're thinking about company and business outcomes, you're as a RevOps leader, like knowing what is possible. There are so many things that could come across your desk at any given time, and you are going to hate and be ashamed of about 80% of like all the little ticky tacky things that, you know, aren't at the level that they could be. So you really got to be relentless about winning big in the right places and losing small in the right places. And when it comes to having like empathy for your end users and really believing that if they have what they need, you're going to get the outcome because you hire great people and you know that they want to succeed as well. Then sometimes, you know, an imperfect solution that can be done very quickly and take a little bit of the strain off of them is superior to kind of like derailing something that needs to be a giant success. And. It's easy to think like you, you have to have it one way or the other. Like either you can do every little thing or you can only focus on the big strategic goals, but having a bit more of a fluid mindset on how exactly you are going to get to the solution that's going to alleviate the pain is really critical and buys a lot more trust from the organization because it shows that you're actually listening. It shows that your focus is on the outcome and that your belief is in the people.

I'm going to come back to the belief in the people thing because it's a really good point that I want to unpack. But can you give an example of being relentless about winning big in the right places and losing small? What does that mean in reality?

I mean, in reality, it can mean that, you know, that there are, well, I mean, if you want to talk about owner, like there was most certainly a time where the number one focus that we had was on proving our outbound motion, getting our sales team to a point where we could prove sustainable growth at a certain rate. And this kind of like follows my journey at Owner, which was initially just working with sales and marketing and then taking on implementation and then all the way through the customer journey. The way that you look at what you could be doing or what feels broken from a technology or process perspective, and you balance that against what the business needs, is really critical. So I mean, like we spent all of our effort, you know, when I first started on sales, we spent all of our effort when we start first started working with implementation on that. And then for the past 12 months, it's been 100% on, uh, our, our CSM and customer support side. I, a big goal of, of this year, which I think we've achieved, especially in, in this back half, has been to not need to be so single-threaded on those big wins and be able to achieve multiple at the same time, which I think we've done a fairly good job of. But really, like, there have been things where, like, if I was only focused on sales over the past 8 months, you know, I would consider certain aspects of what we have here to be completely, you know, below where I want them. And like, I'd be a little bit embarrassed of, but if I look at the company goals and the outcomes that we need to see that the sales team is able to hit, and you can kind of keep them in a position where they're getting the improvements that they need, quality of life improvements to continue on that trajectory, but focus on another metric within the business that's like so important that it's an absolute can't miss. That's the kind of area where like I'm going to lose small in a function that's already doing what it needs to do in order to win big in an area where we need to shore up our defenses. I think that's like really what it comes down to.

Yeah. I think the other thing here is not getting lost in the little stuff and the noise. And this takes a while to build. And I think it's rooted in, in your experience as a BDR leader, being able to discern between— this is a KD thing— volume versus volume. Is this a high volume of stuff that's always going wrong or is this just like one high-volume individual that's making a lot of noise, but it's actually not something that is felt all that much across a broader audience. And I think like the, a lot of it, I think a lot of your success has come back to trust. You've mentioned that a few times, being able to think about the business first, really smartly partner with the functional leaders and find good compromises for stuff and explain things. I think like one of the challenges you made a comment before we started recording, either becoming a yes person or a no person, but like building nuance, finding a place to say, I hear what you want and I know that's important. And here's the other things that are more important than that, that we have to focus on before this. Like, does that make sense? Do you understand? Are you, are you aligned with that? I think that's the other piece that's missing with a lot of RevOps leaders is they don't have that dialogue. Because they don't feel like maybe they owe it to those functional leaders to really sit down and go through it. Because, you know, it can be this more, um, combative relationship where like the business wants all this stuff and then RevOps is just like saying yes or no. And, and as opposed to having like an upfront collaboration and making all stakeholders feel like they're part of the process.

Yeah. Definitely. I think like one of the things I've enjoyed most about this type of a role has been, you know, you're right, like I'm right there with you as a CRO in terms of scope. That is something that particularly really gets me going, but it allows you then to really be somebody who's dropping in on different parts. Of the team and really ensuring that it's well understood what we're doing and trying to get everybody pulling the same rope. Because I think a lot of folks is like, the instinct would be that like, oh, if I tell sales that I'm doing something for implementation instead of for them, the instinct might be that, you know, that's not going to be a conversation that goes very well. But again, like the same way that you need to trust every individual contributor, you have to be able to trust the people around you, your peers, and the people that you support because they're inherently reasonable. And if, again, if you're hiring well, these are people who are focused on the company outcome and how they can play their part best. And I, I have trust in everybody that I work with that that's the case. And so sometimes it, it's, it's on you as RevOps to connect the dots for people and to, make sure that the context is shared laterally where typically I think there might be like a bit of an avoidance because you don't want to go tell somebody that their thing is getting deprioritized or that you're not as worried about their function as they are. There is a difference between like prioritization within a function and prioritization within, you know, RevOps as a whole. And I try to be able to explain that and I try to be able to if I find myself explaining that too many times in a row, then that's a signal to me that I have to change something about how my team's capacity is growing and how my org is structured.

I also see this pattern in RevOps leaders who struggle or CROs that complain to me about their RevOps leaders is I find sometimes those individuals see that as an impediment to their job as opposed to like a core responsibility, having difficult conversations, sharing context, being able to connect the dots. It's like, oh man, like, you know, I told you no, like I don't want to have to have an hour-long conversation about why, but that's oftentimes where RevOps leaders really struggle is they feel like that's in their way. Like it's a frustration. It's like, no, that's not in your way. That is One of the most important things that you can do, especially if you're dealing with a functional leader, explain to sales like why they're not as important as CS right now. As a company, the priorities are X, Y, and Z, and be able to have those conversations. I think you do a good job leaning into that and inviting it as part of the role, as opposed to like avoiding it and finding it as a frustration. I want to double-click on this thing that you, you just said though, like people are inherently reasonable. And one of the things that I think you've done successfully is to prioritize the rep experience and to think about the rep first and then zoom out from there. But just talk about those two things, like this assumption that people want to do well and are smart and capable and how you think about rep experience and building for them.

Yeah. I mean, obviously I think that pretty much actually every situation I've really worked in. I've seen this actually work out. Obviously, if you don't feel like this can apply, then that's a challenging situation to be in. But I have the utmost confidence in the culture of excellence that we hire for. And I think if you're going to, if you're really going to be excellent at RevOps, you have to recognize that there's only a certain point that you can take That you can only, it'll only take you so far to try and just use your will and bend reality to your will. And with that, I mean, like one of the most powerful experiences that I ever had was actually before I even had RevOps, but I kind of had just done my Salesforce Admin 201 course. So I'm leading BDR teams and I walk over to our RevOps guy and I'm like, hey man, I'm going to make, can I make a custom field? First thing I ever did. And I put this custom field on a dashboard and this was to solve for a business outcome. If you maybe remember, I'm celebrating cuz my BDR team's hitting the SLO number. You're looking at me and being like, hey man, all this stuff's getting stuck at the middle of the funnel and turning into nothing. So like, you don't win if we all don't win. And so, you know, we had tiers and we would go in. And so I went in and I just put on the dashboard what percent of everyone's calls went into tier 1 accounts. And I didn't say anything to a single team member. I just put it on the dashboard. It stack ranks by number of calls. Here it is. And day 1, you know, 40, 45% of calls going into tier 1 accounts. By day 2, 70%. By day 8 or day 3, 80%. And that was a really powerful experience because it just showed me that people inherently, especially if you're hiring well for the correct roles, you got the right people in the right spot, they want to do well. I think it's a really natural tendency. The further you get away from the phone and the customer, the further you get away, the more you start to distrust, the more you look at something that's not performing. You're looking at a report and the easier it is to just slip into this thought process that like, They must not be working hard. They must not be, you know, I've got to do this, this, and this to force compliance.

You're dehumanized.

It's, it, you become a metric on a dashboard and not a person easily, easily. And I think that that'll resonate with a lot of, of, of reps listening. But RevOps people, I think, uh, if you're honest with yourself, you'll find yourself slipping into that mindset if you're not careful. And it's really important to believe. That if you give them the right workflow and if it's something that actually solves for the challenge that prevents them from doing the, the next best action, the revenue generating activity versus the administrative activity, if it can just reduce cognitive load, if you're solving for those things, if you're, and like building through that lens, you're going to get the result that you're looking for. Because you believe that by making this clearer, easier, less, you know, less taxing on a huge group of people, that the incremental value is going to be where you see the major gains. And I think it's easy to like stuff a lot of effort into attempting to force compliance, or like I said, kind of like bend things to your will, but you really get a lot further with empathy.

Yeah, it's, it's one of the most important I think design philosophies that we have as a business that, that you pull through to RevOps is it's this assumption that people want to do well and they're smart and capable. Because if you assume, no, we need guardrails and, and validation fields and this, that, and the other, people, in my experience, people will adopt that mindset if that's the way you treat them. Like if you make it seem like you don't trust them, then they will act in an untrustworthy manner. If you need like 100 validation fields to stop some, stop a rep from doing anything wrong, then you end up, this is like learned helplessness a little bit. And you take away their sense of agency. And once you take away somebody's sense of agency, then everything starts to fall apart versus, you know, it's difficult to approach it this way, but But so important. So maybe talk a little bit about the ride along you just did. So under, under this theme of having empathy for the IC and staying connected to the business and maintaining that humanity and building things for people who want to do well, talk about the, the ride along that you recently did, why you did it, why it was important and ride alongs in general.

Yeah. Well, I've been probably a couple in the last 2 or 3 months, particularly with our BDR org. It's an area that's obviously near and dear to my heart and in such a high volume business that is very heavy on the phone. I think it's really a critical area where incremental gains really add up. And most recently I was doing an audit of our inbound lead follow-up process. And I think, you know, it was really interesting. I went in, I spoke to the BDR director and a couple of the managers and we did some whiteboarding on, you know, what they think could be better because I knew that I would be able to make some workflow tweaks right there in real time. And then I literally pulled up a chair beside a rep who'd been here for less than 2 months and introduced myself and said, hey, listen, don't be nervous, but I'm rolling with you today. Like we're calling your list and I'm going to watch everything you do and I'm going to have questions for you. And it really, what it, what a lot of it would have uncovered were just that there were certain elements of our process that I should have been more thorough with enabling our frontline managers. And I should have closer understanding of what our onboarding, what our onboarding content looks like for these type of roles.

Mm-hmm.

And that there were just definitely things that could be done to make it easier to standardize exactly how the job is being done. I'm a really huge believer in standardization in, in the front end of a process and then allowing someone to flourish with whatever their natural talents are in the back half of a process. So whether that's like anything from the cold call days, saying like, you know, this is the opener that works and that's what lets you be you. You don't have to be an artist, don't have to change it every single time. Just to like it being the best way to prospect cold or the best way to work an inbound process. I think the, the repetitive proven steps are what gives you the time and in a quoted role, especially like a monthly quoted role, the breathing room to kind of flourish and use your own natural talents.

So freedom within a framework, baby.

Yeah, exactly. So I've done that a couple times in the last few months and though it's challenging to kind of go into a sales office on a normal day and say either be in 6 hours of meetings or lose your deep work time cuz this is the type of stuff you're doing. If you can, similar to like Katie's concept of going dark for an entire week, like certainly possible to take a day and be like, this is a context gathering day. I will learn what needs to be built over weeks and months, and I will on the fly see things that can change that rep experience and change those outcomes. And, you know, I think if you approach it right and you're, and you humanize kind of yourself in the process, it's really helpful.

Yeah. How often do you think RevOps leaders should be doing ride-alongs? Every quarter, every month, every year?

Yeah, I mean, I guess it depends on how, like how process-driven you are, but yeah, for me, I think any time that I've gone more than a month or two without doing it has been detrimental. So once a month in our environment feels right. If you are a little bit bigger, more enterprise, perhaps that could be more like every other month, once a quarter. But you have to have all the right information to make decisions. It's amazing how easy it is to come on and come onto a, you know, a SLT meeting and be like, oh yeah, this is how something's happening. Like they're good. And then not know that really that process that you thought was amazing has atrophied to the point where people are no longer using it. That happens all the time and you can't just get annoyed by that. You have to then come back to your principle of believing that they're going to do the thing that is best and that it's on you to make that choice that they make the most effective path forward. That means that like, there is no like battle of wills in this. You could, you could try it. It'll take a ton of your effort and it will not build the bridge that you need built. And so I, I Only I do not do that unless it is a really critical situation.

Yeah. The ride-alongs are such an important empathy-building exercise. And one of the things that I think it highlights is friction. You know, like it can be easy to be like, oh, why aren't people doing this? Or what's going on here? But then you sit down beside a rep and you watch them work. They're like, oh, they're not doing that because it's a total pain in the butt and it would slow them down tremendously. And it's going to get in their way of doing their job. And I think this is like, this is nudge theory and sort of classic behavioral economics. What are the things that are, what are the things that are easy to do and how do we make our golden path the lowest friction path and how do we add friction to the places where you don't want people to go? Too much of the time, it's all about introducing more friction to the things people you, you don't want people doing validation fields, more rules in Salesforce, all that versus I think like something that we spend a lot of time talking about is the optimal path. How do we make that super easy? How do we get Momentum to fill out that field and pull the information out of a call? How do we have Salesforce update that field for us and, and trigger the workflow and push the information to somebody? In Slack as opposed to, you know, forcing somebody to find that information. It's that friction finding is so critical and the ride-along is the perfect place to do it.

Yeah. I'm always astounded at how little I hear people think about the cognitive load of critical tasks when you have 10, 20, 50, 100 people doing the same thing. Like it's all well and good to have a system that's designed in a way where you can do a thing, but it's an entirely other thing to really get into the psychology of the people that you're working with and saying, hey, if I was doing that and I've, and I know that, you know, let's say if you're an onboarding specialist, you know, super hard to juggle all these cases, resolve all these issues. Okay. People are missing meetings and So you've got all of these things on your plate and if you're sitting down and you don't have the workflow resources to be able to zero in and do one task that needs to be done 10 times in a row, be in that headspace or group things. Like it's a lot about grouping into—

Yeah, batching and flow.

Clusters that become— and then being able to order that according to like, what's the next best action? What's the highest level priority that I can do? I think that's, there's like an epidemic of this in the BDR world. Unbelievable how much coaching goes on there.

Yeah. Yeah. I'm doing a follow-up. I'm helping a post-sales customer because they couldn't get support. I'm now running a demo. Now I'm on a follow-up. It is so difficult to get into a flow state with any of these things. And we talk about that a bunch. And again, it goes back to the point of it's not all tech. It's not all RevOps process building. Going back to your ride-along, I think the interesting observation is like, oh, these reps didn't even know there's this other list that we wanted them to be following up with. So no wonder our time to first touch wasn't good. Like they didn't know they existed and we don't need to change anything. But the, I think that's one of the important things about good versus not good RevOps teams is they have enough business context and they're deep enough to be able to say, hey, this is something we need to fix with enablement. This is a coaching opportunity. We don't need to tech this thing.

I think more often than not, when you're sitting there and you're looking at the dashboard, the report, and you're seeing something you don't want to see, the amount of times that when you investigate it, It's because somebody is being lazy, doing the wrong thing intentionally is so minimal. Of course they happen here and there, but if your default is to go and say like, I'm not putting the right information in front of this person so that they can make the best decision possible. I mean, everybody, it also just like strengthens you. I think your standing within a team. You gotta just, I mean, I picked up the phone and called a little bit a couple months ago and as you know, that your pitch skills depreciate faster than driving a car off the lot. But so I knew I was about to get crushed there, but even just sitting down and looking at the call button, at the start call button and like registering the the feelings and the emotions that you have going through your head. Like, I should be better at this than I've ever been. I got nothing to prove. I got no quota. I know everything I need to know. Like, I should be better at this than I've ever been. But that's that feeling of like, okay, do I know enough about this? Oh, I guess I should research this a little bit more. It's enough to rekindle the empathy for how challenging the job is. That it, it really kind of like lights that fire and has you going, okay, how do I make this so that those cognitive stressors can be dampened as much as possible so that these people can win? And how do I present it in a way that makes it clear that I'm not taking away their creativity and their individuality? I'm actually making more room for it. And that's always like the first day that we or sorry, early on in our journey when we were a very early Salesloft customer. And so like the cadence concept was fairly, fairly new. The ability at the rep level to have scheduled emails and things like that go out. The, the first conversation was, I hate this. Why do you even need me? You can schedule these emails. You can make them dynamic, dynamically personalized. Like they're, they felt they had their backs up to it. And Similarly, there's a lot of artistry, I like to call it, within particular sales reps in particular. I actually do things kind of different. A lot of reps are saying that, and, or this is actually my process. And I think it takes a lot of, it takes a lot of doing, a lot of trust building to teach people that there's no point in not consolidating around the parts of a process that you know are inherently valuable. And that can increase your volume, can increase your success rate in order to let you do what I actually hired you to do, which is have these conversations, you know, be persuasive and an excellent advocate for our product. Like you will have more conversations if you follow this process. So all your artistry kind of like can actually happen in the situation you want it to be happening. I can't, I can't maximize for that unless I can maximize for, you getting you on that connected call. And so really like bringing the reps into that process is in that specific example was what kind of turned the corner. Okay, let's come up with one that we all like. We're gonna whiteboard this together. I'm gonna crowdsource some of the campaign information. Uh, we're all gonna agree that we're gonna do it this way and we're gonna do it this way because, uh, if you give me 30 days of data, then I will know whether this worked or not. And if you kind of fall off and stop following this process, well, I'm going to not really understand whether it worked or not. So then I'm going to be back in this same position, bothering you again next month, trying to find something that does work. So can we all commit to this? And if the data shows that it doesn't work, okay, what were you instinctively going to do instead? Like, is there any part of what you're looking at that Like, is there any part of what drew you away from what we agreed upon that might be valuable that we should test as a team? So it's creating that like a bit more of a team environment and really convincing people that it's not about taking their autonomy away because it's not like, I really don't believe that.

Yeah, it's empathy. It's curiosity. It's, it's collaboration with your stakeholders at its core.

Are you ready to level up your go-to-market strategy for 2026? Then don't miss GTM 2025. The only B2B tech conference exclusively for go-to-market executives. Join 1,000 other revenue leaders this September 23rd to 25th in Washington, D.C. for an exclusive executive-only experience. This 3-day event is hyper-focused on connection, strategy, and execution. Expect hands-on workshops, in-depth strategy sessions, and curated opportunities to build relationships with VPs, CXOs, and founders facing the same challenges you are. You'll stress test your GTM approach, align your team, and leave with actionable insights from top-performing leaders. Don't miss the must-attend conference designed to help you boost your go-to-market results in 2026. Visit attendgtm.com. That's attendgtm.com to secure your spot today. And don't forget to use code TOPLINE for 10% off your GA ticket.

Okay, I want to move us Let's move on to another topic because we've gone through like one of the 8 things I wanted to hit with you. Um, when was the right time? Talk about the Agile transformation and like what it meant for the RevOps team. Like what is an Agile RevOps framework? And like, when was, how did you know it was the right time?

Yeah, I think, uh, so explain it for folks first. Sure. The transition we made was just very much a, it, it was centered around, you know, a key company transformation from, you know, the point where it was you and I and a couple other people that were sort of on the leadership team to really getting a strong head of function in every area that we support. And so during that transition and, you know, shortly after a raise, I had been really used to doing as much as I could, asking for as little as possible, and mostly focused on really what was directly in front of our faces rather than deep planning, because that's what you do when you're kind of Series A, Series B. And it became evident that in order to be able to plan for the long term and roll with the punches in terms of like things that just come up that the, that kind of a process really wasn't gonna work for us anymore. And so for, for us, we needed to staff up the team very quickly. I, if I could do it again, would've recognized, I think that I was understaffed a little faster. But in that process, you know, that, that also takes time. And so we ended up bringing in a, a consulting group and initially the, the body of work that they were going to do was to help us deliver on a couple of really large projects for, for the CS team. But What ended up being infinitely more valuable was the day that they asked us, what's your project management philosophy? And I kind of said, I'm not proud enough of it to take the time to explain it to you. And this gentleman in particular was like, okay, so can we do Agile? And I'm like, we are doing Agile right now, all in, jumping in with both feet.

And And you can name, you can share, this is Asellus is the consulting company.

Yes, it sure is.

And John, what's John's last name?

Good friend, John Collins.

John Collins.

Shout out.

He's been great. So if you need consulting help, you can go tell him Steve sent you.

Yep. Blow John up for sure. Yeah. One of the, so one of the greatest things about that partnership was that we rebuilt the team and Under 6 weeks probably. And so that changed my whole perspective on what I needed and how to ask for it. It changed how I interfaced with the business. It changed the level of throughput, professionalism, and quality that we could deliver. And so I take one person that I've got who's got a knack for this type of stuff. He becomes the project manager. I have another person who handles compensation, interface with HR ops, and we run an IT-style help desk. And then I go to you. I do in the business and I say, I want to hire 4 product owners, one for marketing, sales, launch, and NCS. And so in moving to that framework, I really top-end loaded the team with people who I thought, you know, if I stretch this org from the top right corner, this becomes a sales ops organization. This becomes a CS ops organization. These are the right people to do that. The people who have the technical understanding and also, you know, I think the ability to be really excellent at interfacing with our stakeholders. And then—

Explain what Agile is like as an operating methodology.

Yeah, as a framework, I think a lot of people know the words, like you talk about going, doing a sprint, you talk about, you know, tickets and that type of thing. But really Agile is whatever you need it to be. In, as long as you are sitting down with the entire team that you're working with and effectively writing a working contract, that's step number 1. And you can use the templated versions, but you're deciding on the length of time that your sprint is going to be. You're deciding on the rituals. You're deciding on what are all the different stages before something is considered done. If you're in an Agile workshop, you can spend 2 hours on the definition of done. You can spend another 2 hours on the definition of ready. These points can seem fairly semantic. Gigantic or like something that you could come through or like rip through very, very quickly. But in reality, getting down to that level of detail is, is critical because it takes everything that could slip between the cracks and every unknown and it turns it into a known. So it's, it's really a process that is designed to take all variables and have a, a container for them to go into that is interconnected with the rest of your systems.

The intake process, the comms process, the intake, the sprint prioritization.

Yep. And as, as important as anything else is, is the retro. So after every sprint, we get the team together. We have a whole, like, not anonymous, but like hidden card system where you have, you know, category 1, what went well, what didn't go so well, what do we wish we had kind of thing. And we make. That's not just us going through the motions. That's one of the, the best calls that we have every 2 weeks. And typically what we end up with are 5 to 15 different things that go onto our RevOps improvement board that are enhancements that we think are going to make us more efficient, put out higher quality work, and generally just improve the quality of life of the team. Because the way that the team is structured, the 4 POs are the ones that are interfacing with the different business units. They are the ones that are writing really detailed, high-quality user stories or tickets. And then the project manager is working with a team of contractors that we have and they every 2 weeks pick up their, you know, 30 story points worth of tickets. And as a team, you know, this is the most challenging part, but as a team, like we try to say like that our culture is that we don't overload people with with tickets and we get everything done. And that becomes really challenging to maintain some, and really frequently you have to level set and come back to your agile working contract and refresh it in order to do that. But it allows you to provide a really clear understanding to the business what you're working on, what's still in scoping, and when they can expect to see it delivered, when it's planned to be delivered. And also critically important, it gives you some ability to forecast to the, the other functions that you need to be working with when you're going to make a change that might impact them. So the handoff to enablement, critically important. The handoff or concurrent work with your data engineering team, if you're going to be changing something that will materially impact the way that you report on the business. Without that, it's super easy for those things to fall through the cracks.

How did you know it was the right time to do Agile and how would you advise somebody to think about whether or not it's right for them? Is Agile right for every RevOps team? Like, should they, should this be the standard in your opinion?

Yeah, because it's a maturity model. Like I could go, like, I think if you have 2 or 3 people, any, like, as soon as you have 2 or 3 people, then yes, it is time. Because you can do it by stripping out as many things as you need to strip out and start operating on these principles that are going to serve you well as you grow. Like, like anything, like there's so much of Agile, like that by the book we don't do, like we're project managing in Notion, which like we can do, you know, reasonably well by buying an excellent template, but like It's far from providing the capabilities that you'd have with, you know, some blue chip software to be able to manage your projects. And, and there are all sorts of elements of it that we really don't get into. It's about right-sizing it. It's about figuring out where you are on the maturity model. And then for me, I want to always be looking at where do I want to skip a rung on that maturity ladder? Where? Do I just want to be half a step ahead? And so the smaller you are, the more that you're going to have a bunch of people wearing a bunch of different hats, hats, and the larger you are, the more matrix and the more role definition that you're going to see. And so if that's going to be everyone's growth journey, I think that's like fairly standard to say, then you benefit a lot by starting out from a position where even if people are wearing a bunch of hats, you can see how they would break off into distinct, you know, rules and, or like, uh, roles and responsibilities. Like even in my system now, it's like, all right, there will be a time fairly soon where like we want a dedicated QA cuz like devs peer QAing and the project manager doing it creates a bottleneck. There will be a time where more advanced or dedicated DevOps is absolutely needed, which is just like being able to manage your deployments because we are already at the point where we have to be super careful. You can be deploying two things that two different people worked on that conflicted. You really gotta take the lessons from product development teams, but, but really like look critically at what you are doing, who you have, how much you need to deploy on a regular basis and say, okay, like where on this maturity ladder do I need to be? And a lot of the time you're either avoiding something that you, you know, a small problem that you see that could have become a big problem and you're saying, okay, like let's get ahead of that now. Or a large problem where you look at it and you say, there was no SOP for that. We did a data backfill and did not consider that it would trigger this email and this automation rule. Okay. Instead of just diagnosing exactly what happened, let's diagnose all the different situations that put us at risk of this happening again in the future, and then implement something that's going to be a standardized procedure.

A nice part of the retro.

Absolutely.

Yeah.

Got it. The whole process is turning variables into constants and every time a new variable comes up, you turn it into a constant. This is like the— I, I like, I twist the, the, the— I saw like a, in a Bezos interview, he's talking about, uh, the concept of the paper cut teams. So you're always going to have these, like, if you're a product team, these, uh, customer experience things that are just not quite good enough, but they're never big enough rocks to get, you know, the whole org behind. So he talks about the concept of having a paper cut team that's solely dedicated to dealing with that. I like to just mentally organize the way that I operate like that. Category— or like categorize paper cuts. Imagine all the different places that this, this could happen, and then really quickly take that and figure out how you're going to make sure that anything that sort of is in the same category can be dealt with in a standardized way so that These are, these aren't things that I have to deal with anymore. It can only ha— it can happen once and then we can go write an SOP for exactly how we're gonna treat all situations that fall into this category and everybody's clear. It's just turning variables in into constants everywhere you turn.

Basically it's the Dalio thing.

Yeah.

Making it some something. Another one of those.

Another one of those is my favorite piece. Like, that's like the one thing out of principles that like I will never shake. It's just, you see something and honestly, like the more that it frustrates you or the more that it, the more that it like knocks you out of your groove, like you, whatever you had planned for that day, that week, the more that you look at it and you go like, I never wanna be unprepared for that again. Like I have to turn that into another one of those. Mm-hmm. And you know, you can take that all the way down to building for scale. Every time that you design something, you look at it and you go like, all right, if someone was gonna ask me to change something about this, like what would it be? And how do I make it so that's an easy yes rather than a huge, long, prolonged, drawn-out process?

Yeah. I, I'm gonna move us to a slightly different topic 'cause I wanna make sure we hit this. So a bunch of CROs are listening. And going like, man, I want a Steve. Where do I get a Steve? How should CROs be thinking about finding a RevOps leader? Because I think it's a more difficult role for us to hire because it's not our core skillset. Like it's pretty easy for me to see good and bad sales leadership. Now I have a good sense for good and bad RevOps, but I've managed it for like, I don't know, 8, 9 years now. But most people might be like hiring their first head of RevOps. They're like a first-time CRO. How should folks think about like, what are you looking for? Where do I find them? How would you advise an early-stage CRO to find their first RevOps leader?

I think, yeah, I think it's hard for a good reason. RevOps can mean so many things at so many different places and people can come really highly recommended to you, but like, for instance, in our environment, we have wisely, I believe, invested really heavily in data engineering and data ops as its own function. And so there are a lot of people who are like me, but then also own that. So it really depends on what you're looking for and what you need, but at the end of the day, you need to—

Yeah, I want to double-click on that because I think that's one of the Super critical point, being really clear about the jobs to be done. Because in our environment where we, where we have hundreds of thousands of accounts and we make thousands of dials a day, high velocity, high transaction volume, we're closing hundreds and hundreds of customers a month. What you need in an organization, the jobs to be done is like very specific, which has meant RevOps is so much more about business strategy, workflow optimization, infrastructure, being really cutting edge. And we need different expertise because the business is so data-centric. It's hard for a RevOps leader to be highly proficient at both of those things. Our data analytics stuff is pure data science, but in an, in an enterprise environment, that wouldn't be the case. If you only had a few hundred accounts and these are very long sales cycles and you don't have the repeatability and measurement then you can have a RevOps leader also own most of the core reporting because it's very simple. You're not running sophisticated regression analyses and doing A/B testing the way that we are in a high-velocity environment. So I think being really clear, right? Yeah. Yeah.

And a completely, in a completely different environment, I was building in the CRM and associated tools probably at like 20 or 30% the capacity I am now and spending orders of magnitude more time getting into the details around reporting and analytics because that was where like the value that I could provide was. It wasn't that we needed, you know, I think something I've been saying a lot is how much I really enjoy at owner, the constraints that are put upon us in that independent restaurants inherently, you know, it's very SMB and there's not much of a mid-market and there enterprise, like that's not our goal. And so the constraint is we have to be perfect or as close to perfect in so many places across the funnel. There's no huge deal that's gonna come save the month, the quarter, the year. Like you have to be great everywhere. And that challenges us to be operationally and from a data perspective, so proficient that we create the teams and the systems and the operating models that we need. And so I guess for the advice to a, to a, a CRO, it would be to, to sit down and define the constraints that your business has, because it's going to tell you exactly what kind of leader you need. And in terms of like the recruiting process, I think it, it's almost hard for me because we have such a, a tight understanding and like tightly tied beliefs around how we want to operate. It's hard for me to imagine, you know, obviously like building that rapport from scratch. However, I think that there does need to be this really implicit trust and this camaraderie between the CRO and RevOps in that. There are gonna be very few people that have the same purview as you as a CRO. Like it's gonna be, you know, if it's gonna be your revenue enablement, it's gonna be your RevOps, you know, it might be your talent partner. Like there's very few people. And when it comes to, you know, realizing your vision, I think one of the things that you've said to me the first time that we ever met was like, we see the world the same way. And I think when you're, when you're Speaking to RevOps candidates, you're going to get a fairly decent sense for their technical proficiency. You're going to do all your due diligence around, and you're going to be able to find people who have done impressive things. Where you're going to maximize the output of somebody is if you're able to get to that level where you have that implicit trust that they know with 70, 80, 90% certainty what it is that you value so that when they're out in the world interacting with the rest of your team members, that becomes an extension of the philosophy that you're setting for this team as a CRO. Like that's, that's what makes it work really well with us is because I can say with like a fair amount of confidence what it is that you're going to value over something else or just assume the answer for the question that's being brought.

Because there's a lot of times that I'm MIA, not on Slack in 8 hours of meetings, and if people need a decision, they come to you because they accurately assume that you can say what I would answer and feel empowered to just give them the answer and their marching orders. And that philosophical alignment, I think, is so much of this decision-making process. And where CROs go wrong here is going back to your previous point, what is the thing that you're solving for? What are the jobs to be done of this individual and how do you want this function to be built? And I think CROs have to take more ownership over RevOps than they do today. Oftentimes it's like, I don't really know anything about this tech stuff or infrastructure. Like I don't wanna think about reporting. I want somebody to come do that for me. And I think that is oftentimes a path to pain. Because then you just have incongruence and it's hard to be super hard to be successful in your role if I didn't have specific answers about how like I want to do things. And that congruence, one of the things I'm like seeing a pattern of more in this part of my career as I've managed much bigger teams and now I'm separated from the frontline by more and more people. Is the importance of like leadership alignment and philosophical alignment with you and TA and my second line leaders and, and other functions, because you can't be everywhere all at one time. And so I think if I was going to give advice to CROs, it'd be like, be really clear on what you need this person to be. Are they a super data analytics person? Because that might not be found in the same person who is the workflow expert or the business strategy guy or the, former AE director, now made RevOps leader, and to think hard about what you're optimizing for. And, you know, I say this a bunch, but, you know, you're trying to build a basketball team and you can't get everything in one person. You can't have a 7-foot center with crazy handles that shoots a 3 and like has great vision. Like that, that person doesn't exist. Maybe we, maybe it's Wemby out of like the millions of people that have ever played basketball. Ball, but you have to think about, okay, like we need this heavy operational data science person and you have a partner in Jonathan that is like brings all of that in like crazy depth. And then there's other people that do this and other people that do that. But the business leader needs to be thoughtful about what you are optimizing for because this is like building your player in NBA 2K. You only have 100 points to allocate. So like what's the thing about our sport?

Yeah. Like if you can't see this person as somebody who you're going to give a seat at the table, if you can't see this person as, you know, your right hand, if you don't think that they can kind of like lean into those sides of the business, then I think you're, you're, then you're, then you're still looking. Ultimately, um, the, the tool stack The experience, those type of things you're going to find a lot of, but you have to define the constraints that your business is under. Imagine your war room when something goes wrong. Imagine, you know, who you'd like to be able to stand in for you in, in, at times where you can't be in a room for certain things. Like if you see those qualities in this person, then ultimately, like if you're a growth company and you're hiring your first RevOps person who's going to build this team, like there are ways to fill technical gaps. There's not really an easy way to fill, you know, a revenue leadership capacity gap. Like even from the first day I started, like I had offshore contractor, the guy who set up the CRM, like, like I'll know my limits. Like I'm very happy to admit my limits when it comes to, to actually hands on the keyboard being technical. But I'll double down, triple down on my ability to kind of see, see the road ahead and, and know the direction that we need to go into and how to get there without making a huge mess. And as the team grows, then you just get to add in more and more specialized capabilities. And it kind of goes back to like hiring for the things that, that are harder to teach.

So what else would, what other advice would you give to CROs looking for a RevOps leader? So know what you're looking for, be clear about the jobs to be done, philosophical alignment in the people you talk to that are great. What are the other things people should, the, the CRO should be looking for?

Yeah. I mean, like if you're CRO hiring first RevOps, like, is this typically like, if you're, are you like a RevOps leader, like getting started?

No, not the first RevOps person. Not like I need a Salesforce admin, somebody who's like a manager level, but like I am a $15 million ARR, $10 million ARR SaaS startup. I'm growing pretty good. I need like a legit head of RevOps, like a director VP level person to build the team.

Yeah. I mean, might be biased, but I do think that, you know, a more diverse work backgrounds that has ended up with a significant tenure leading in RevOps prior to hiring them for that role is really helpful. I think I imagine how hard it would be to do what I do well without knowing really what it means to be staring at the dial button without really owning what it means to manage you know, 8, 10 people who are all quoted reps. I think it's really hard to develop that empathy without having done that. And I think most of the people that I have met that I really think are excellent in RevOps have that sort of a background, but, and it doesn't even necessarily need to be in there, but I think it's just like a diverse experience tends to, tends to make the, the great RevOps hires. Because they're people who are obsessed with building and they're people who are obsessed, who don't have blinders. That's the one thing that I knew about myself is like the first day that I ever, I spent like 6 months as an AE and in an office environment and like the best AEs are the ones who go, I don't hear anything around me. I don't care what's going on around me. I'm going to focus on what I care about. And you need to find these people who are, obsessed with incremental changes adding up. Yeah, I do. It is a very hard prospect because it is such a tightly knit organization, like a group. And I think if you were going to look at one role that is very typically following a CRO or a sales leader from company to company, like it is very typically RevOps because there is just such this like fit aspect to it. So I'm afraid like in terms of like tangible frameworks, that's like as far as I can go. It's really challenging because you don't go to school for it and it's so different everywhere. You can find 10 people with 10 RevOps titles that are exactly the same, that have wildly different experiences and wildly different skills and wildly different, um, job descriptions. Yeah. I will. That's why it's so worth it to find the right one.

Yeah. If you got a good one, keep them close. That's clearly what I've done. And you've seen it even when Bobby Morrison came in as the CRO at Shopify. What's the first thing he did? Bring in his RevOps leader who sounds like she's a beast and like they, they have that relationship. And I think that's their third stop together. And, and you see this a bunch. Uh, I just got off with another CRO. Last week who's coming on the podcast and she's done the exact same thing. Her first thing was going and convincing her former partner to come over with her. It's, it's, um, that, that unity is so critical.

Um, Bobby, Bobby got Rukmani to join and they were a Salesforce shop and I believe they were using Dynamics at their last place. So like that says something.

Yeah.

It's about the vision and the alignment. And also the, how important the inverse is, like how important it is for me to be aligned with you and how much better my professional quality of life is knowing that we have that, that shared vision of how things should be done.

Last question before we get into rapid fire. What, what advice would you give to CROs to work best with their RevOps leaders? When you have your RevOps leader buddies, grumbling to you about the way that their CROs operate? Like, what are the, what are the biggest things you'd tell CROs to do well?

Yeah, I think, I think you have to demonstrate, not just say that you have trust. Like there are, like whenever you and I disagree, like one of us ends up being like, okay, I trust your decision on this. We'll go with it. You have to really demonstrate that there are, that there is a collaborative nature to this and you have to make an effort. One of the things that you do really well is you make sure that I'm in every room that I should be in, in order to do my job well. That prevents the, the situation where you turn into the yes or the no RevOps leader because you're in the room having the discussion, you have the, the, the early warning, you're able to caveat, say what you can do, say what would be out of scope. That makes all the difference in the world. And so another thing that I think I see that CROs have an opportunity to do better would be understanding that everybody, anything that every, anybody wants to do in revenue or that kind of flows through revenue is going to hit RevOps and the more that you can go to the executive team and say, as a business, this is a stack-ranked list of company initiatives that are can't-miss items, and we're going to use this as our framework to say yes, no, or later to projects. The more that you can make that clear so that it doesn't have to be simply just like, the gut inference of the RevOps leader to do that, um, the, the more that you'll get out of them. And so I think that one of the things that I see as my job is to free you up to go and be an executive. Because as a CRO, one of the most challenging things that you have going on is that you are both an executive and somebody who needs to be so accountable to every level of the revenue team down and like has, you have to be able to have the answer to that or at least have the confidence to say like, if Steve says this is how it's happening, then like I trust that that's how it's happening. And so the more that I can free you up and, and give you that confidence, the more that when I come and ask you for something, which is like, I need clarity on whether this takes priority over this, or just generally once a quarter, I need you to go to the exec team and like lay out the priorities and how they've changed. The more that you have the ability to go do that for me.

Yeah. The other piece of advice I would give to CROs is invest in this team way earlier than you think you need, because what ultimately happens is by the time you think you need it, you're like, 3 or 6 months behind and you're just playing catch-up. And so bring in somebody good early. You started full-time with us when we were like $5 million ARR, I'm pretty sure. And we started staffing up your team at like 7 or 8. And now we have a team of 4 POs, PM, comp, and all that stuff.

Yeah.

Yeah. Now adding a head of architecture, it's 7 people and we're $50 million ARR. That, that for a lot of people would be like, wow, that's such a huge RevOps investment. It's so expensive. But actually what's expensive is having 100 frontline go-to-market reps that are 2%, 5%, 20% less efficient than they should be. It's, I think that's probably the single biggest mistake I see. Revenue leaders make is they don't invest in it early. They don't prioritize it.

You gotta be able to sit down and have that maturity model conversation. Okay. What is the least, what is like crazy enterprise level maturity? Where are we and what are kind of like the gates to move from one stage to the other? And how do we make sure that we don't miss one?

And explaining trade-offs.

Yeah.

Like, hey, you want X, Y, and Z the way the team is staffed and resourced today. You're going to get like items 1 to 3. If you want to get item like item 7, this is what the team should look like. And so let's have the business conversation. Is it worth enough in terms of money, burn rate, the LTV CAC, because we roll, like we do LTV CAC on a fully loaded basis. Is it worth that? Is it worth that, that, that business metrics impact to get items 7 faster than, than we have at Revout. Okay. Last question. Uh, I just want you to explain how you think about avoiding becoming like the yes team or the no team and like what, what you meant.

Yeah, I think, well, like if you were to think about like the sales meme pages, like what is Revout there? They're the no team. They're the team that is completely disconnected from the reality. And of course this is comedic, but they're disconnected from the reality of the rep experience. They're disconnected from the business and they've been able to carve out a corner of territory, set their roadmap, not really talk to other people and just say no. And I think that that is like probably a function of just, you know, maturity model staffing, like being overwhelmed, but not being enough part of the business to be able to communicate needs, not being plugged in enough and figure out how to carve out times to do quality of life improvements and, and ride-alongs in order to, to get there. So those are the people who I think are probably overwhelmed, understaffed, and have the gravitas to, to like hold up and be able to, and say no to everything. And then there's the other side of the coin who are the people who so desperately want to provide impact that they turn themselves into a ticket taker, into a service type of operation. And there's no collaboration on exact, on the type of solution design. You end up with things that are meant to solve very niche business problems. You're not asking whether it will have long-term impact, whether you should be building for this to be a permanent part of the process, whether this is a test. You're not going, you're receive functional requirements and you build functional solutions. You don't take that up to the business requirement layer and deeply understand exactly what kind of impact you're trying to achieve here and what it means and why it should be done instead of something else. Those are the people who similarly, I think, get run off of their feet trying to handle everything for everybody and be people pleasers rather than, I think, business business impact drivers. And so again, it's about like both examples are people who allow themselves to get into a situation where they're not contributing at the same level and being offered the same ability to contribute as somebody who has set up their organization in a way where it can communicate with the business how they should be working with you and freeing up the time for you to be able to to go in and gain a deeper level of understanding.

Yeah. Okay. Rapid fire. We've already covered what separates a good RevOps leader from a great one, I think. But what's the most common advice you give to new heads of RevOps? It's there, they're in a Series B company. It's the first time they're calling the shots. What's the advice you give to those people?

I am mostly giving the advice that would be unsurprising based off this conversation, which is around like, building that gravitas within the business by showing them that you can think in systems, both in how you design the outputs that end up in the, in the team's hands, but also in how you construct the relationships that you're going to have. It's as important to build your function and put as much work into building your function as it is into the solutions that you're going to build. I think that's like the main one. That I have for, for RevOps teams. And then I also find myself frequently giving the advice of like figuring out how to exploit your specific superpower within your environment and be able to identify and admit and then go out and figure out how to solve for the things that you're not as great at. I think that's like a really important thing. It's really easy to start feeling like the wizard and like the person who can handle anything and everything, it's really hard to look around the corner and be like, wow, we are heading in that direction. That is really scary. We should go get somebody who's amazing at this. And I should go tell, I should be able to go tell the business why. Yeah.

And build, when you say put in the work to build your function, you're talking about having a project management framework, agile, like a systematic way to engage with the rest of the business. That's what you mean by function building.

Yeah, exactly. Yeah. I think there's a point if you start out like I did as RevOps hire number one, there were excellent people that were kind of like pitching in prior to me joining, but you start out and you are, you go from being somebody who's a practitioner, who's delivering value personally, and then there's a point where you have to recognize that your job changes from delivering value directly to building a machine that is going to deliver value consistently and finding the right moment to understand that it's time to start building that machine is like the critical piece.

What is that moment?

That moment is where you realize that if you were to, you know, need to be on leave for any specific period of time that like there would be big trouble. And that if there's too much flowing through you, there's too much where you're using effort and willpower to make it through. I think you need, like, you're never going to be at a place of equilibrium. Like I said, like you're always going to hate like half of your processes because you know how good they could be if you could spend infinite time on them. But if you are solely using your own willpower and effort to get by, then that's a signal that like you have to find some time to work on systems and converting a bunch of those things into things that can be done by other people or by the system.

Yeah. Cool.

You're not going to convince anybody to get a bunch of hires unless you have like a pretty solid system either, right? Like if you're going to go to the business, you've got to come correct with like Here's where they fit in, here's what they do, and here's how it's going to get you the impact you want.

What's the hardest lesson you've had to learn in leadership?

Yeah, in leadership, I think it was mostly about kind of my own self, I would say. Definitely like learning the difference between like emotional intensity and like practical intensity or like results-driven intensity. There's like, this might just be a function of, you know, being younger in your career, but like, it's really easy to think that getting emotionally wound up and doing stuff is the way forward. And I think it took me a while and it was a really hard lesson to learn. But as soon as I got on the other side of learning how to like use practical intensity in terms of like making sure your intensity is calm, action-based, but still, you know, you're pushing things at a high velocity that made for a wildly more enjoyable and rewarding professional life where I feel better every single day about the way that I impact other people at my job and the type of work that I do. And so it's just, I guess, changing the way that you care within your professional setting and investing less emotional energy into those problems. Yeah. Like we are, we're a stoic we're a stoicism shop here.

Yeah.

And I think that that was the hardest lesson to learn. Like, I remember early in my career getting like stress alopecia and like having my hair falling out because I was so emotionally wrapped up in the way that I wanted things to be. And I felt that that was what intensity was that got results. But really intensity is something entirely different. It's like methodically and calmly and like with a sober mind, kind of like looking at the problems and making sure that you're being fast and that you're being decisive, but without just that like torrent of emotional energy wrapped up in it.

Nice. What's the last question? What's the best thing that you've read in the last 12 months? Doesn't have to be business related. I know you have eclectic tastes.

What do you mean? Business one for RevOps folks and for CROs. I don't know if it's been mentioned on the pod, but you asked me to read Working Backwards a little while ago. And that one is definitely the best, like very different from, you know, reading a founder, a founder book. This is like the operators inside of Amazon who made these things, these wonderful things happen. That's a really fantastic book for framing how you think. I like to read a bunch of weird stuff. The other cool one that I've read recently was The Hour Between Dog and Wolf, which is a very interesting book about, written by a guy who is a neuroscientist who spent a bunch of time on Wall Street and analyzed the way that people's brains work and how you can get results and what stress does to your brain in terms of performance.

It's very interesting. Hmm. We haven't talked about this. I got questions about this book. I'll just read it. Well, this was awesome. We meandered through a lot of stuff and I think teased out a bunch of really great things that hopefully is useful for both RevOps leaders and CROs. This is a very challenging relationship, I think, for many. So appreciate you sharing and this was a blast. Glad we did it.

Definitely. Yeah, I'm honored. This has been a lot of fun.

Thank you for listening to the Revenue Leadership Podcast. If you enjoyed it, don't forget to subscribe, and you can find a link in the show notes. And be sure to leave a 5-star review, share it with your network, and please join me next Wednesday for another great conversation.