Considerations for building a RevOps team with Alex Miller, Director of RevOps at Medallion

Considerations for building a RevOps team with Alex Miller, Director of RevOps at Medallion

Related Content

Never miss new content

Subscribe to keep up with the latest news from AccountAim.

Should you hire generalists or specialists to your RevOps team? This episode with Alex Miller, Director of RevOps at Medallion, is packed with tactical advice for operators building a RevOps team at fast-growing companies. Alex has led RevOps at several high-growth startups, often as the first hire. In this conversation, he shares why building and managing a clear backlog is critical — not just for prioritization, but for earning trust, driving headcount decisions, and keeping your team aligned as the company scales. He also breaks down why early RevOps teams should stay generalist for as long as possible, and how to avoid the common pitfalls of over-specializing too soon. If you’re building RevOps at a growth-stage company, this one’s for you. In this episode, we cover:

  • How to build and use a RevOps backlog to drive alignment and resourcing
  • Why early RevOps teams should hire generalists, not specialists
  • When to scale the team and what skills to prioritize
  • How to navigate reporting lines (CRO? COO? CEO?)
  • The biggest mistakes RevOps teams make as they scale

Take a listen and let us know what you think.

Full transcript:

 Hello again. It is time for another episode of Boardroom RevOps, where we are breaking down strategic, operational and career related best practices with RevOps leaders we admire. Again, I’m James, co-founder of AccountAim, the next gen analytics solution for RevOps teams. I’m excited to be joined by an old colleague of mine from Sendoso today, Alex Miller.

Thanks for joining me, Alex. Yeah, good to see you again, James. Aside from being a great colleague, Alex has led RevOps in a number of buzzy tech companies, often joining the team in the earliest days, and he’s currently the director of RevOps at Medallion and is also pretty plugged into the sales tech landscape, serving as advisor to a couple RevOps focused startups.

Before I steal all your thunder, Alex, do you wanna share your background a bit more detail? Sure. First job at college was a BDR. Best way you can, fun level startup called Yammer got pulled up into a big beast called Microsoft. Got to see how startups work big and small and drifted into the back office running RevOps teams.

I was an AE and was more fascinated about building the plumbing and had an opportunity, really early stage company to be the AE and the BDR and everything and go build up your tech stack and have more of a knack towards, again, like building out the plumbing versus being someone who’s working through it.

And 12 years later here we are. Haven’t looked back since, since. James hit it. Most recently at sendo was at mucks and then most recently, for the last, almost two years now at Medallion leading the RevOps teams here. So it’s been a good time. I’m sure we’ll talk more through it. I always forget that you started actually selling, do you think that gives you like, a different perspective than other Revs folks?

Totally. Yeah. I actually, about half my team today is former sellers and I think, I think from a RevOps angle, like having the empathy of understanding what the people you’re serving, are going through and what it feels like to be stressful and have a quota, I think makes you a better operator just because again you hope and you hope.

The other side of that coin is like sellers look at you and they’re like, okay, Alex knows what we’re going through and therefore we know that they’re working in our best interest. But yeah, I think there’s not enough former sellers in RevOps, but I think one day I hope to change that. Yeah, I’m sure this is partly just your personality, but I was impressed by just the rapport you had with the sales team at, Sendoso.

I imagine that’s not always the case for a RevOps team. But it seemed like pretty, yeah, oftentimes it means like if you can hang with them at a bar past midnight, that usually gets a lot of the kudos there. Yeah, no kidding. I ask every guest we have, how do you define RevOps? It’s a bit of a nebulous term.

Yeah. Yeah. I always think of RevOps maybe it’s funny ’cause I wanna be a doctor one day, but I wanted to be a doctor one day. I don’t plan on being a doctor from here, but, it’s like the nervous system of your go-to-market engine. I think, you can think of a connected tissue if you want, nervous system, that central team, right?

That is responsible for all the moving appendages. Again, I work at a healthcare company moving appendages of the whole team. I think it’s like the brain, right? It’s a really like a cliche way of saying it, but I think it’s very true when you get into the nuts and bolts of it. Yeah. I appreciate the healthcare metaphor for sure.

So we talked about your background. You’ve been in a lot of like growth stage software companies, call it, if memory serves like series A, series B, series C. I think getting the RevOps Foundation in many places and scaling the team as you move along a bit. So maybe we can take the conversation from that growth stage.

So I think you’ve been like the first RevOps person, one, two, maybe three times, like putting yourself back in that spot, what should the priorities be for a new RevOps lead at a company like that? Yeah, so it’s always interesting, like I feel fortunate to have not been in the RevOps seat of one for quite some years, but.

Those are always the most formable years. And I think as an operator, that’s where you really implement your own playbook and then as you build off there, others follow and adopt that playbook. So it’s a really unique opportunity whenever those come around. The thing I would always say is and this is acutely the case for a single RevOps operator, but is also applicable to anybody joining a RevOps team even is just to come in and survey what’s going on in the business.

That’s not just come in and say, Hey, gimme the backlog that’s been building up, that has been waiting for the seat to get filled. It’s coming in and saying what are OKRs this quarter? What is the company trying to do? Irrespective of where RevOps reports, whether it’s into a CRO, a COO, a CEO, I think it’s always great to say, Hey, Mr./Mrs. executive, like you own RevOps just as much as I do. What are your priorities that you want to make sure that we’re going against? And aligning with those ASAP. ’cause I think what’s fun about being early in RevOps is most people are like, I’ve been waiting for you for so long to join this company and have someone here to finally help us do these things that we wouldn’t be able to do up to now.

And so I think when you align to those high level executive objectives, like even the small wins put so much wind in the RevOps team sails, even as an individual we’re like. You can come in and people are like, holy crap. You just adjusted this little thing that only you probably know how to do because you can live in the back end of the systems and such.

But like we’ve been waiting for someone to do for so long, you’re like, yeah, it took me 10 minutes. But you don’t have to tell ’em that, just let it be perceived as a big win. But I think so much of coming into a new role and like building rapport, it’s just like trying to come in and frankly just be like transparent about Hey, what are we here for?

We’re not here to push buttons in Salesforce. We’re here to close more revenue and. Storm into new markets and be successful like at a high level. And aligning to those objectives early on just I think separates the tactical, operators from the strategic and I think just starts everyone on finger foot.

Yeah, I think that’s so well put. And a common theme, from some of the best revs leaders that we talk to, align yourself to the executives biggest goals. Make sure everything you’re doing is in, pursuit of those. So with that said, and maybe that’s the bulk of the answer, but like how do you prioritize when you’re in this seat of one?

You made a comment, like there’s probably already a big backlog. I hear you on the goal setting, but there’s probably still a ton of things to do. Totally. So how do you kind prioritize everything you have to get done? Yeah, I think like the same comment I said before, it’s important for all RevOps folks, I’m about to say, but it’s even that much more important for a single RevOps operator as a team of one is to set a backlog, having Asana board, have a spreadsheet, have something that’s here are our priorities. And as new stuff comes in, you add it to the bottom of that so you’re tracking it. But then continuously go back to that leader and be like, all right, here’s what I’m tracking as priorities. Can you make sure that my top 10 are aligned to what you believe to be the top 10?

And that backlog becomes like your secret weapon over time, because whether you’re asking for more headcount later on to help grow a team, or even just trying to quantify like what you’ve done about Hey, 90 days in being able to look back and say, here’s everything that we did. But at the same time too, taking in, you know what I’m sure is a backlog that’s just waiting for you when you join and merging that against, yeah, there’s probably some tactical stuff we gotta go clean up, but at the same time there’s a bunch of bigger ticket things.

And what you also start to see is I, I guess luckily or unluckily have, is a lot of them kind of daisy chain together, right? There’s a lot of stuff that you can’t unlock the strategic thing without, unblocking on the tactical side. Totally. At the same time, like inverse is also true.

Like you just don’t want to go do tactics without a strategy. So I think once you have that backlog pulled together, and there’s, you should, ideally do that on your first day. If anything, it just brings as you start to put your fingerprints on the org, people just have confidence.

They’re like, Hey, James is organized look at him, he’s got his backlog he’s rolling. I feel heard because when I asked it on that backlog somewhere, even if it maybe at the bottom and people just were like, all right, cool. We’re in good hands. And I think that’s, you can’t do that soon enough when you come into new org.

It’s such a tactical thing, like the Asana border of whichever, project management tool you want to use. There’s a lot of wisdom in there because in terms of showing ROI for the things you did that helped move the needle, having people feel heard that the thing they just requested is on the list and then using it as a mechanism for trading on priorities, it actually makes like a ton of difference in like managing stakeholders.

Totally. And it’s a great way to I’ve been in situations that I’m sure many operators have where you’re like, Hey, I need to go tell someone way above me. No, and I think it’s a really good. Like insurance policy in a way where like you could go to the, your CRO and say, Hey, I need you to help me tell our CMO that this needs to wait until maybe next month instead of this month, just because it’s brick in brick out on things and we’re working on this thing today.

We need to get that done first. And it just, again, shows a level of organization. I like to think of it almost a scrum master would with an engineering team. It’s like your job is to protect focus at all times. Make sure that work is structured and it’s consistent and there’s no lull in work, and that you’re not over committing to things.

It works the same way. And I think, teams of one, this is like what keeps your head on straight is if you can just make sure that everything you’re doing is organized and clean and that it’s defensible to the people that inevitably you need to tell no to a hundred percent. Side question here.

You made a comment earlier about, whether RevOps reports to the CRO, the COO or the CEO. What’s your take on where RevOps should report. Yeah, it’s funny, I reported to everybody over the course of, even in the last five years, here at Medallion I report to our CRO, our head of sales.

I did report it through our finance org for quite a bit. at Mux I reported into A COO, which had a centralized BizOps RevOps analytics function, which I think was a really unique setup. So we’ve seen it all. I think what it, what is, I think as you get more mature in your RevOps career.

It’s like it doesn’t matter where you report to. If the remit is to own everything between marketing ops, top of funnel DS ops, you throw BDR ops in there too. There’s always Deal Desk components where you’re heavily involved with finance. I think as long as it lives somewhere where someone respects it and wants to own it and is saying, I’m gonna go fight to make sure, or at least respect them and say Hey, RevOps is a strategic unlock to me as a leader.

Then that’s where you wanna be. And like that could be a COO, it could be a CRO, it could be a CEO. You just need to be underneath someone who like wants to own that and is gonna respect it and go fight for resources for you. If I had a preference, I really don’t like, I think rolling up into finance, or the COO is great because you have.

That decentralized view where you can be that truth teller without feeling or at least having a perception from the outside that you are biased towards one or the other. But at the same time, like I can also just acknowledge that if you roll up into say, a revenue function, so much of what it falls underneath, the RevOps umbrella is geared heavily towards revenue.

And that’s not just like your traditional hey, you’re doing sales ops of running forecasting. It’s also comp commissions the old ask. It’s like kind of the long tail of things. And I think, a revenue leader probably has a little bit more skin in the game to make sure that is. Like literally cash on the line to make sure that RevOps is supporting those initiatives.

You can’t go wrong. Like I said, what you just need as a leader who like understands it and owns it and feels like it’s not just the Salesforce admin team, because if you do that, then you might as well just outsource it honestly. Yeah, that’s a great perspective. One more question on the solo early RevOps hire here, and we can take it any direction you want, but what’s, do you have a checklist of things that would be on your mind or you would recommend someone look into joining a company like this?

This could be CRM foundation, things need to be in place. This could be core go to market tech stack, core processes. Like what do you think is most important tactically for folks to be thinking about? Yeah, I think, you can never kind of start investing in a data infrastructure early enough. I think a lot of what you want to do strategically when you get into a new org is probably blocked by some element of tactical, whether it’s tooling or process.

So much of, and I can say every new org I’ve started in, like you spend a good chunk of your first time there either implementing a new or validating your sales process. I think so much of what you learn. As an early org, even as a mature org is can be measured based more or less on like your sales stages and adherence to sales stages and understanding like how deals move through your funnel, but also really clean like data.

So I think it’s especially for any org that’s like doing heavy outbound prospecting or even just frankly wants to have like cleaner insights as to what your TAM is like having a good data vendor for account data just to size up your market and a really easy project is to say, all right, let’s go build what we believe to be our total addressable market through any type of data tool and go mirror those in Salesforce and assign those accounts out to reps.

It’s a bit of a V one territory plan, but what that does is it, I. It means that as you’ll start to materialize at these companies, what the company is, like what do they do? Like where are they, every business is so different of course, but you have just the right metadata about this company where you can start to drive feedback loops around, Hey, are we seeing traction in this one area of something that’s a surprise and maybe you do wanna go double down there.

That’s always interesting. But I think just like early days is just do the simple things. Make sure your CRM is set up so that people are, having sales conversations that are related to accounts, contacts and opportunities, right? What you can get from that in a very quick time is like, where are we having good conversations?

Where are we having bad conversations? Then you can start to see where do we win, where do we lose, like early on, I think so much of the checklist to do is just to enable those things to happen and yeah, there’s a ton of tactics that go into that behind the scenes, like making sure. Stages get gated correctly so that you know that when you can open Salesforce and hopefully you don’t have a dozen stages, hopefully you have four or five, six where you can look at them and have confidence that like deals are progressing through it.

But, I’m a huge proponent of just keep it simple. There’s, if you go into a new org and that there’s 15 sales stages, like you should just either leave or just say, Hey, stop. Let’s revisit this because. There’s no way that sales reps are putting, deals through 15 stages.

Yeah. It becomes garbage and garbage out by trying to over. Totally. So I think the biggest thing just to summarize early on is just like you as a RevOps person own the instrumentation of how you measure, the go to market effectiveness. So you just have to make sure that instrument is set up correctly such that you can do that.

And that’s a really umbrella term of course, but. If there’s a early on, it’s like it doesn’t take that much, right? It’s like clean data. Just make it simple such that reps can buy into doing that and start to do some basic reporting on the feedback loops so you can go back to your leadership and show that.

Say, hey. The instrument is working and we’re measuring things and we’re baselining things, and then here’s where we have leverage to go make things better. Yeah. And that’s where strategic value comes in too. So a lot of what you said is tactical, but if you’re actually getting the instrumentation right and it’s useful and it’s not over-engineered, you can start to present the data that prompts strategic questions of where should we double down?

Where should we expand our tam, et cetera. And I think that’s where executives start ops. Yeah. Just the operating principle, it’s this seems forecasting for example, it’s like. The tactical thing is go implement Clari, and then you check the box and say it’s done. The strategic thing is to say, Hey, we wanna increase our forecast accuracy by 5%.

And Clari is just a tool to help us get there. But like implementing Clari and signing off from the implementation plan is not done. That’s the beginning of the process, arguably. So I think as a practitioner, it’s anchor to what the outcome is. Same thing I did, I said you, you’re,

reassess sales stages and velocity. It’s a difference of saying okay, we’re gonna implement new stages, versus, Hey, if you want to be able to reliably measure our funnel and either increase our win rate or sales velocity by x percent, quarter over quarter, and those are things executives care about.

Executives like don’t care about Clari. They care about their forecast, they don’t care about the sales stages, implement they care about. How does this implement the leverage that we have in our business to make things faster, bigger, more repeatable, et cetera. Yeah, a hundred percent spoken like a real sales person talking about the problem and not the features or the solution.

Yeah. I lied. One more question. This one’s career related. So let’s just do a hypothetical. Someone has four years RevOps experience. They’re thinking about going and being the first RevOps hire at a series A company, or they could go be the third hire or whatever on a bigger team, a slightly more skilled company.

How would you counsel this person to consider the two options? I think a big thing is just like looking at the business itself. I think, you have to like what the company’s doing. I think it’s easy to go size up a RevOps opportunity because fortunately there’s a lot of them out there.

I think this discipline is one that doesn’t have, it’s always joke. You don’t go to school to be a RevOps person. Like you accidentally find yourself in it and scale from there. So you have to like the company and like you have to believe in this mission and you have to like really want to say, hey.

These jobs aren’t easy and I’m ready to go solve hard and tackle hard problems that maybe involve some, extra effort, extra hours to go solve. But I do think, in assessing that company, you can assess like, all right, is this something where you’re aligning yourself to a really super early go-to market team that’s still trying to find its product market fit, et cetera.

Or is this to say, Hey, I want to come in and slot in to maybe start growing a team or be like the second hire on a team, or the third hire on a team that’s got a lot of the early stuff figured out and then you’re trying to go solve problems that aren’t like the early stage blocking and tackling.

And then things get arguably more strategic in the later half. So I’d say like you almost can’t do the second one. Actually, the inverse is also true. It’s a good experience to have both angles on it. I think if you’re early in your career, if you can go slot into being behind a leader who can really teach you the ropes.

’cause so much of this, again, is learned either from peers or from the team you happen to join. I’d say if you join the later stage team, you’re probably setting yourself up to lead one of those teams eventually, where you would then leave maybe that current company for being there for quite a bit and be that first hire and then be responsible for growing up a team from there.

So I think neither is a bad path by any stretch. And I’d always coach people like, try to assess the business as best you can because ultimately, if you don’t love what the company’s doing and the people you’re working with you probably won’t be there very long anyway.

Yeah. And you’ll probably, if you’re whatever camp you join, you might, and it doesn’t fit, you’re probably gonna leave and join the other camp anyway. So it just comes down to assessing like the business. ’cause again we put in. Job’s not easy and you really gotta enjoy what you’re doing and who you’re doing it with to, to do it well.

📍 Yeah. Put. Okay. Moving on to growing the team now. So when should a RevOps leader, let’s just say a single RevOps hire at the moment, think about growing the team, what are the signs you look for, the resource constraints, et cetera? Yeah good question. I think like as soon as, and again, this going back to what we said at the beginning of this conversation about having a backlog, this is where, this is your secret weapon.

But I’d say like you need to have those discussions about growing the team, like as soon as, or arguably a little bit before the output of the RevOps team becomes a hindrance to the growth of the rest of the org, right? If the RevOps team becomes a bottleneck and it’s purely a resourcing thing, that’s actually a fairly straightforward and hopefully easy equation of a conversation to solve for.

But I am, I, I used to have the mindset, which was like, Hey, more bodies to the RevOps team was always a great thing. I know like the last couple years have convinced us that’s not always the right way to grow. And I’m a huge proponent now of like smaller, more agile, more generalist RevOps teams that could be dangerous on a lot of fronts.

So that is part of the scale equation is like looking in your current team and understanding where are the weaknesses or like where is the seal gaps? And sometimes that’s still gap and actually be like somewhat more senior. Like it’s very common where you might come in as a RevOps manager and.

You threw your hand up and say I think we need a director here, like to offset maybe the leader part that person earlier in their career has. But I think, like I always say is you should be looking at hiring or growing your team, like as soon as it’s probably financially feasible.

What I mean by that is obviously like making sustainable, good investments in the headcount, the team. But like I said, that project backlog becomes a huge asset. ’cause if it’s like, hey, you can think like a scru master building sprint plans, you’re like. I can do this much units of work per week.

And one extra person immediately might be able to do half the output that maybe I am. But all of a sudden then we’ve got, one, one and a half times the amount of output through the team, which means we’re getting through our backlog faster, which means we’re doing more strategic things or we’re less bogged down in certain areas.

So I think that’s a huge, like I said, asset that again, you thank yourself as soon you, you probably hate it when you first start and be like, man, this is so much metal work to do this backlog thing. But it pays dividends later on as you have the opportunity to make the case for more resources.

Yeah. In your experience making the case for more resources and let’s say using the backlog as a tool, do you find that the conversation is often framed around like the benefits you’re getting from those tasks in the backlog, or is it really more of a just sheer volume of work cost driven equation?

It’s a bit of both. And what I mean by that is there’s like a throughput of work that’s important, but there’s also like sizing up the opportunity costs of spending time on some of the necessary blocking and tackling that then takes away from doing more strategic items. So part of the, you’ve even asking for resource.

It doesn’t necessarily need to be an FTE hire. Sometimes that’s Hey, can we go partner with the Salesforce agency to build a bunch of flows for us so that, I have more time to align with executive leadership on their initiatives. But yet this work still gets done. I think, like I said, it’s a bit of both.

And I think ultimately at the end of the day, like you need to size up like, okay, if I can’t do everything that needs to be done in a reasonable amount of time, like there needs to be some flex, and it’s either we’re gonna start doing less or we’re gonna start pulling additional resources to say they’re gonna go low, I’m gonna go high and together we’re gonna get all everything done.

Yeah. And then other, you made an interesting comment and other than just like the macro environment, people needing to do more with less, I totally understand that. What else has driven you to moving more towards this like generalist business athlete concept on your team versus, I’ll put words in your mouth, a deal desk person, a comp person, et cetera.

There’s still definitely value in those roles. I think there’s a certain part of scale where that does become a thing. Probably like when you get to like series D, series E type companies, and you’re just, hey, you’ve got 30, 40 reps. You just need to have someone who can run point and own certain parts of the business.

But like I believe strongly in just like that generalist, just because early on in these startups, like the business shifts a lot. And I think if you find yourself in some specialist role. The business shifts, like you need to be able to adapt to whatever comes next. And I also think that if you have a small team largely comprised of generalists, if there’s a large problem or large challenge, like you can have, all right, we’re gonna go put two people on this problem and go solve it.

Maybe pull someone away who’s usually doing some other discipline somewhere else within the team and saying, cool, we can double up and team up and go after this particular task. It just makes everybody far more agile. Yeah. I think versus coming in and even just saying you’re gonna be our marketing ops person, and you’re gonna be our sales ops person, and you’re gonna be our CS ops person and you’re gonna own tech stack stuff.

You start to put these just like swim lanes within the team that make even a small team that’s supposed to be agile, like fairly rigid. And what also means is that, as requests come in, you may find that the distribution of kind of work to be done isn’t necessarily uniform across the team.

And that can lead to, as a leader of a team that leads to people getting burnout and challenging and frankly, just like it’s a. It’s not a bottleneck within the team. And I think the more kind of general you can be and roll with punch of the business and distribute work evenly across a larger group of the team, like that seems to be, at least in my opinion, a much better recipe for success.

That scales arguably, in most cases, a lot further than folks would even think. Like you can stay in that system for, 2, 3, 4 years depending on the rate that the business is growing. Without needing to necessarily start thinking about more special roles. Yeah, I actually think it’s more interesting for, it’s my opinion for the team members too.

To keep it a little bit more fresh, learn a little bit more. Yeah. And I think it’s a good opportunity for, retention and all that good stuff. This is what we want. Like again, as a RevOps person, it’s like you didn’t go to school for this. So you’re learning from your peers and I think if you have good peers that are working off on projects and wanna bring you off the ride and they’re willing to share how they’re thinking about things, then.

Everybody wins in that case. Yeah. So we talked about solo RevOps person. We talked about the first few hires. Tell me about the next phase, and we can keep it amorphous, but just like scaling beyond that. What should RevOps folks be thinking about when they’re saying moving into a mature business or coming up on a mature business?

And I hear you on maybe don’t need to cover like head count as much, but just like from a rev scope perspective, what should people be thinking about? Yeah. Yeah. And this is where I’ll admit like. I spend most of my time, like in most of the small and medium sized businesses. I think once you get into these scales, then all of a sudden you have like specialist RevOps teams that are like responsible for the Americas versus Europe.

Yeah. Things just tend to get a little more siloed and I think that what’s ironic about that is you just have the same team you probably have in a smaller company. You just clone it and then they run their own little franchisees elsewhere within the business. Which I think is a fun setup, obviously, like there’s challenges that come with getting everyone on the same page from there, but it does definitely come with more specialization.

I think. Like you can’t have kind of this generalist mindset for like I said, if you have a hundred reps who do you know, a dozen deals per quarter, they’re like, you probably need someone who can just be narrowly focused on deal desk. And I think you definitely need to shift from away from a generalist mentality once you reach that critical growth point.

I think, those are unique challenges where I come back to the original kind of statement, which is as long as you’re aligning to what like the highest level of initiatives are and cleaving off the stuff that you think is probably not the best use of time, like a lot of scale of companies, it’s like Salesforce is owned by it.

I think that’s a crazy idea, but that’s just the reality and that’s a huge, or you have a business systems team that is responsible for a lot of those things. You, your RevOps team, if you’re like, not worried necessarily about tech Stack, like you’re spending a lot more time on. Forecasting and territory planning and tam, and if there’s a, commission structure that we can implement to drive different strategic deal structures.

Like all of those things where you’re just like, you’re not as burdened, by some of the more tactical items. Yeah. It sounds like if I were preparing for that stage is based on what you described, data infrastructure findings to be the next level. Since you’re going a lot deeper into all these processes and just you need to be able to get into the next layer of granularities and continue to optimize and break down those silos as you mentioned.

Totally cool. We’re nearly out of time here. One last question I have for you. Any big pitfalls come to mind and kind of the levels of scale or growth that you’ve seen in your career that we didn’t cover today that folks should be thinking about? Yeah, and I said it earlier a bit, but just perfect.

is the enemy of done, like we work in startups, like it’s, they’re imperfect companies and it’s a feature, not a bug there. I’ve seen so many times that. You keep something behind the curtain because you wanna make it perfect and you, it takes more time to do that. And when you finally roll it out, the business shifts And a lot of that work will have been for naught. So my biggest pitfall that I’ve seen I’ve been guilty of it myself, is keep things simple. Stay agile. Perfect is the enemy of done. And what you wanna avoid is like you’ve over invested in something and then the business goes left and the tool or the process you built was intended to go right?

And all of a sudden now you’re back to the drawing board and you wasted two months of production that maybe you would’ve had elsewhere. Simple is better. And that’s like the one thing I even challenge my own team internally to say, Hey, can we do this with half the level of complexity?

Just because we want to be looking a couple steps ahead and where we’re at today. Maybe a couple steps ahead is a different path than maybe where we think we’re going today. Yeah. I’m getting essence of Elon Musk and his tendency to simplify there, but I think it’s great advice. I think it’s heartbreaking from ops perspective to invest all this time in a beautiful compliance process.

Yeah. But that goes back to also being able to tell folks no, which is Hey, this big thing you wanna invest in maybe sounds great today. That’s where you need to be like the truth tell, which is, I don’t think that this is something that’s going to be a long term or even, medium term fit for where we’re at our business today and.

Here’s where we think a compromise may exist and that’s where, things usually get done much smoother if you can. If you can have those hard discussions. Yeah. Good advice. We finish with a quick rapid fire. So first couple words, first sentence that comes to mind on a couple of these questions.

Biggest myth about RevOps, The biggest myth about RevOps is that the best RevOps hires come from outside of your company. Say more about that Actually. So like I, kicked out this conversation. I started my career as A BDR. I think some of the best hires that I’ve made and teams that I’ve worked on have been like, go find that BDR, who knows what a pivot table is, and keep ’em close and help ’em work on some projects with you.

And finding other folks within the company who you know, they know the company, they know the business, and know processes. Maybe they’ve even been someone who’s been living in those processes as an ic. Those are great people to say, Hey, I want to jump to the other side of the table and help build this infrastructure.

And help run the data and be an operator. And I’ve had a ton of success and I know a lot of people that I’ve worked with started that way where they’re like, Hey, I just worked on a side project with the RevOps team, and 10 years later they’re still doing it. And I think those hires usually have a much higher hit rate, than say, hiring someone externally who has so much to learn on day one about both the business and the operational parts of the team.

So I think it’s often overlooked. Everyone thinks they need to hire someone from outside the company, but. More often than not, you just want someone who understands data and tools and process I love and those oftentimes are already at the company. That’s a win-win. Good answer. Okay. If you could fix one challenge in RevOps, what would it be?

Snap your fingers. It disappears. Slack. Slack, okay. Yeah. Yeah. I’m a huge proponent just protecting your focus and like Slack is like the anti focus. It is an absolute critical tool. I’d say like our business would be lost without it, but. I think I struggle with it. My team struggles with it, which is like you don’t have to answer every slack immediately.

And if you need to remain focused to go heads down and get something done, like ignore slack. I know it’s hard to do, especially in remote work and stuff, but yeah, there’s gotta be a better solution out there somewhere. Someday we’ll find out. Last one here. Someday. How would you describe a great RevOps leader in three words?

I’ll cheat. I think it’s actually four. And it’s first in last out. Great. I think it’s a great place to cap it. Alex, thanks so much for spending some time with me. It was great to catch up again. Yeah, thanks James. This was great. Appreciate you having me.

Ready to get started?