You Need a Smaller Team to Have a Bigger Impact with Joe Gelata

As your revenue scales, so does the workload shouldered by this team. More work requires more people to keep up with the growth. “We need more people,” Rev Ops leaders cry!

However, this session with Joe Gelata, Head of Revenue Operations at OTTO Motors, will challenge this conventional thinking and show how a larger team may actually dilute your impact on the business.

[Transcript] You Need a Smaller Team to Have a Bigger Impact

Although transcriptions are generally very accurate, just a friendly reminder that they could sometimes be incomplete or contain errors due to unclear audio or transcription inaccuracies.

Joe Aicher

Nearing the end, I’ve got a couple of presentations left, so I’d like to bring Joe Gelata on, who is going to join us with his presentation here shortly. Joe, welcome. Thanks for joining us.

Joe Gelata

My pleasure; thanks a lot, Joe.

Joe Aicher

Definitely, let’s pull up your slides; as usual, I’ll jump out and let you get going, then join back in about 10 minutes or so.

Joe Gelata

Perfect, thank you very much. 

All right, I’m here to talk today about why you need a smaller team to have a bigger, more strategic impact on your organization. As mentioned, my name is Joe Gelata, I’m Head of Revenue Operations at OTTO Motors, which is a division of Clearpath, and we’re a fast-growing autonomous robot provider. So we’ve got smart robots that are running around factory floors delivering boxes and parts to assembly lines and things like that, so it’s a pretty cool space to be in. 

Fun fact: I’m a former DJ, at University that was kind of my hobby/job; fun for two reasons, one I noticed Rosalyn’s background in the last presentation was quite fitting, and then I also found that DJing was kind of a combination of Art and Science, which is exactly what I think RevOps is and probably why I love it so much.

So let’s jump in! First off, the challenge that a lot of Revenue Operations teams are facing is, if you’re in a high-growth company, your company is expanding, and there are more demands put on your RevOps team. The easy solution is to hire more people to do more work, but I find even when that happens, you’re still running into the situation where you’re doing more work, but you’re not providing the strategic value that you’re hoping to get out of RevOps.

So you’re getting stuff done but not necessarily the good stuff. The reason for that kind of starts with the ‘Pareto Principle,’ where 20% of your inputs generally lead to 80% of your outputs. So you can think of it as 20% of the projects that you choose to do are going to provide 80% of the value to your organization. 

If you’ve got a larger growing team, what tends to happen is it’s easier to say yes because you’ve got the capacity and the bandwidth to take on those projects, but you don’t necessarily look at the output or the value that they’re providing so you start to get into situations of diminishing returns; the more things you do, the less value you get out of them and you’re wasting a lot of resources on these low-value projects.

So one thing that tends to trap, that people tend to get stuck in, is dealing with a lot of urgent processing tasks. You know, this data needs a quick fix, or we need to approve these deals, and things like that tend to bog you down with all those urgent things, and you also get a lot of cosmetic improvement projects; Wouldn’t it be nice to have this feature in the CRM? or something like that.

Those are the kinds of things that come in and start to take up all RevOps time. I heard it a few times, CEOs say, ‘I don’t understand why we could do this when we were so much smaller, but now we’re struggling to close deals and grow like we used to,’ and part of that is because of growing complexity. 

As your business scales and gets larger, it never really becomes more complex, but also, because of poor focus, you’re busy but focused on the wrong things. 

So the answer is really to run lean; you have a small functional team but not an overly large one and use that capacity restraint as a forcing function to keep you focused on the highest value activities. So that’s kind of the premise of having a smaller team to provide more value, so I’ll jump into exactly how that can be done.

The first thing I like to do is when you’ve got a bunch of projects on your roadmap, you know, whether it’s 10 or 100, map them out on what’s called the ‘Eisenhower Matrix,’ and this is really about mapping your projects based on the urgency and the value they provide, so you can kind of see how that lays out.

Your Y-axis is all about your importance, so the higher up it is, the more value it’s going to provide to the organization & the lower, the less value, and your X-axis is really around your urgency. So is there a hard deadline again for this project, or is it more of a ‘we’ll do it when we get to it,’ but no one’s going to die if we don’t do it today?

So those two things are very different. 

I think a lot of the time, urgency tends to be thought of as important, but really that you really want to look at the timeline and the value separately. This chart will tell you exactly where, based on where you’re mapping these projects, what you should do. If it’s of low importance, either delete or delegate it; don’t waste your time on that stuff, and if you don’t have the resources to do it, then you’re forced not to waste your time on that, which is a good thing.

High-important stuff, it’s also urgent, is pretty easy to do as a RevOps person. You probably face tons of fires that come up every day because those deadlines are immediate, and it’s easy to keep your focus on those things.

What I find the hardest is the high-importance but low-urgency items, and these are generally the most valuable to the organization because this is where the scalability of your company is generally built. So it could be projects like fixing a process that you know it’s been broken for a year, and if it’s broken for another year, you’ll survive, but if it were fixed, it would really allow your business to switch gears and level up a little bit.

When you start to do more of those projects, you really build a scalable organization which ultimately is what RevOps is trying to accomplish, so the question becomes, ‘How do you accomplish those high-value but low-urgency tasks that are so important?’ 

What I like to use is OKRs.

Bullet point number two here is to use an OKR. Whatever that project is that you’re choosing to do, the OKR is basically going to give you a deadline for it. It’s going to make it urgent, even when it’s actually not. That urgency can be stated just within your team, or you can talk about it more widely within the organization, but you’re setting a goal to have that particular project or part of it done by a certain date. 

My team right now tends to run on months, so we’ll set OKRs for a particular month, and in our minds, even though that project’s not urgent, now, it is, and it’s just as urgent as a request that comes from the CEO or something like that, maybe not the CEO, we always take his first, but you kind of get the idea. You’re creating that urgency to get those important things done.

Number three, another thing you can do is divide the right responsibilities. So if you do have a team that’s large enough, more than one person, you can have a person focused more on those urgent tasks, which tend to be more processing tasks. 

Maybe it’s cleaning the data, maybe it’s approving deals, or helping refs enter information in the CRM. Whatever that might be. Generally urgent, but not as valuable, but have somebody focused on taking those over and then have a separate person focused on those improvement projects that aren’t urgent but are important. 

If you’ve got that division of labor, that just helps kind of isolate both of those so that the person who’s doing those improvement projects is not constantly getting pulled into fire drills.

So that’s one thing that works really well; another thing is to say no with transparency. 

Somebody comes to you–whatever their ask is, it’s generally going to be urgent in their mind and important in their mind, but what you can do is just be transparent about what the RevOps team is working on. 

If you actually publish a list of the 5, 10, 20,100 projects that you have in your queue, and they’re already mapped on this Eisenhower Matrix–so you can actually see what the urgency and the importance of each one is–that person that comes in thinking that they’re high-urgency high-importance task, should be done right now; but then when they start to compare it against your list it kind of forces them to see what other things are going on in the organization and with your team, and they might take a different view after that.

So, If you do say no, then at least they understand why you’re saying no. It makes it a little bit easier, and generally, you’re not saying no; you’re just saying not yet, so you know, here we’ll put you at this point in the queue you can both agree on the actual level of importance of that request, and then everyone’s, maybe not happy because the thing’s not getting done, but at least everyone has a mutual understanding of where the things should be.

I talked a lot about using scarce resources as a kind of forcing function for this kind of radical prioritization, or ruthless prioritization, as I call it sometimes. Obviously, that’s a good thing if used properly, but you have to be reasonable. If you’re a billion-dollar company, you can’t necessarily scale your RevOps team down to one person because that’s clearly not going to work. 

They’re going to get overrun with those urgent tasks, and then RevOps doesn’t get to provide any strategic value because you just simply don’t have the resources to do it. 

It’s really about using those resource constraints to kind of put yourself in that Goldilocks Zone, where you don’t have so many resources and so much capacity that you can just do anything and waste time, but also not so little that you can’t accomplish what actually needs to get done to take your company to where it needs to go.

A quote I’ll leave you with. This isn’t mine, but I’ve heard it before, but I always thought it was a good one, “Companies are successful not necessarily because of what they do, but because of what they choose NOT to do.” So make sure you choose wisely.

So I’ll bring Joe back on here, and we can jump into the Q&A.

Joe Aicher

Yeah, Let’s see if anybody has a question. Feel free to post it, but until then, I was super excited about this topic because I think a lot of us are actually dealing with restraints, right? So for me, a little bit is not so much, I have too many resources, but it’s ‘How do I, how do I focus my time and my energy and the tasks that I do in a way that’s transparent to the rest of the business?’

And I think what you outlined with this Matrix really helps.

I’m curious how you share and distribute those sorts of priorities within the rest of the organization. Are these cross-functional meetings happening regularly, where you’re going through your tasks lists or you’re explaining things? How do you approach that to make sure that everybody else understands how RevOps needs to operate?

Joe Gelata

Yeah, I have two steps there. So one is we use a project management tool called ‘Wrike’ internally within the RevOps team so that we can keep track of our tasks and projects and everything in there. So that’s a kind of a great first step internally, and then the next step is we have a company-wide Wiki. 

So our team has our own little section and page there, and we publish a dashboard in real-time where people can just go and see what that list of projects is. 

We divide it up by, ‘Here are the active projects that we’re working on,’ ‘Here are the projects that are in the queue,’ and we actually have a third section that we don’t publish, but it’s kind of the ideas which are the ones that haven’t really made it up to actually being road mapped or scheduled. 

That’s always available so anybody can go and see it, and if there’s ever a dispute of why someone’s request isn’t as important as they think it is, then we can say, here’s the list, and let’s kind of chat about why it should fit where we think it should, and remove it up if that’s the case, whatever it might be.

Joe Aicher

For sure, and is there a sweet spot for you guys? In terms of the distribution of those urgent tasks and those kind of bigger priority projects? I’m sure you’re not immune to being pulled into urgent tasks at times, right? 

But is there a kind of a division of percentage of time or effort if you’re in that kind of more broad vision, broad goal type of position within the RevOps team that you want to still be maybe investing some time with those urgent tasks and really know what’s kind of going on at that nitty-gritty level?

Joe Gelata

I’d say it would change based on the lifecycle, where the company is in their lifecycle. If it’s a really early-stage company, I feel like a lot of those ‘improvement projects’ that you do end up getting thrown in the garbage because things are changing so quickly, and you really don’t know your business yet. So I think I’m trying to avoid codifying anything that’s going to process or something like that; it’s good because you have to focus on the urgent stuff to really learn first. 

As you start getting into a scaling point, then you probably want to over-invest in the scale side, so obviously, you have to keep the lights on doing the urgent things, but maybe a 50/50 or even higher ratio towards the scalability and improvement projects is good, and then you know once you have a really repeatable engine, then it kind of turns into more maintenance. You know, you might be a billion-dollar company at that point, I don’t think everyone, anyone ever, feels like they reached that point.

Joe Aicher

That’s such a good point about early-stage companies trying to build these things and not spending too much time codifying a process that’s going to be scrapped in three months anyways because you hired five new reps, and everything needs to change or a new product gets launched, right? 

So I think that’s a really good takeaway; well, it looks like we’re getting close to time, Joe, I appreciate you sharing this information. Great presentation. If anybody needs to connect with you, I’m sure they can do it on LinkedIn, and if they have any follow-up questions. Once again, thanks again, and best of luck this summer. Looking forward to talking soon.

Joe Gelata

My pleasure; thanks, Joe.