Building RevOps Like an Engineer

James Geyer: Hello again. We are back for our latest boardroom RevOps episode where we’re bringing you valuable tips from RevOps experts so you can make to the C-suite. I’m James, co-founder of AccountAim, the RevOps BI platform. Uh, gonna be a great one. Today, I have Oscar Armas-Luy, the VP of RevOps at Garner Health.

Joining me today, Oscar, welcome. Thanks for joining me.

Oscar Armas-Luy: Yeah, happy to be here.

James Geyer: Oscar, we’ve chatted, uh, a little bit about some of your tactics within RevOps at Garner and before, um, and it was kind of clear to me that you really bring like an engineering mindset to the job. And so we’re gonna dive into that as kind of our main topic today, which will be really fun and interesting.

Um, but before we do, like, do you wanna just share your quick background for folks?

Oscar Armas-Luy: Sure. So, I mean, starting there, right. So academically I studied finance in undergrad, then I got my MBA in innovation management. And while I loved all the product, um, and management principles that I learned there, I wanted to get.

A little bit more technical. So then I went back and got my master’s in computer science where I really focused on some of the theoretical aspects and I just fell in love with it. It totally changed the way I approached the world, and I approached my role professionally. I’ve led RevOps at Fortune 500, private equity owned, and then VC backed startups most recently.

And now I’m at Garner Health, where I’m really leading our RevOps function.

James Geyer: Awesome. Thanks for that. So let’s just jump right into it then. Talk about kind of like this engineering mindset, how it applies to RevOps. Like to set the table. Do you have kind of like an overarching mental model or kind of framework for those?

Oscar Armas-Luy: So I always use a framework that was attributed to Elon Musk in, uh, Walter Isaacson’s biography. It doesn’t really have a name. I have some people call it the Musk algorithm, but essentially it’s five steps for when you get a project. It’s question every requirement, delete any part of the process that doesn’t add value.

Simplify and optimize, accelerate cycle time, and then automate. And so I’m constantly running through this in my mind. In fact, I even have it written on my whiteboard 24 7, uh, and this is what I use.

James Geyer: Great. I think if it worked for the founder of like a couple trillion dollar companies, it’s probably good enough for RevOps.

So I, I think it’s, it’s a great framework. Let’s maybe jump through it, kind of like step by step and just, uh, maybe unpack this a little bit, kind of how it translates to like, being on the job in RevOps and I, I think it’s awesome because I think anyone can do it from individual contributor, individual contributor, all the way up to like VP of the team.

So question every requirement, I guess, like. You know, I, I think done poorly. This could lead to maybe someone thinking that you’re kind of like standoffish or not willing to do the job. So like, tell me like, you know, how you think about this. Like, what should folks be questioning? How should they do it?

Oscar Armas-Luy: Yeah, so question every requirement is a really interesting one. So in organizations, a lot of requirements get introduced just because, right? So what do I mean by that? I mean, if you’re in a smaller company, the CEO will say, you know, we really need to do X while having his or her morning coffee. And then you got 50 people that are repeating the requirement verbatim, like it’s, you know, in a bigger company it might be the CRO, the SVP, whatever, they’ll kind of just say something and then everybody runs with it.

What question every requirement is about is really making sure is the requirement truly going to get you to the outcome? And is that truly what we want to do? Or is it perhaps something that people are taking to literally, is it something that we’ve done historically that’s no longer relevant? Is it a requirement that was introduced by somebody that doesn’t really understand the process or the outcome?

And so when you think about it that way, I think the key to sort of questioning requirements is to do it from a space of curiosity. So when I get requirements, I try to ask, well, why does it work this way? Or Why have you seen it done this way? Or in your experience, is this the way to do it? And so by approaching it from a standpoint of curiosity, I think people are willing to be a lot more open to you and, and see it as less confrontational.

And then, you know, I always look out for the flag in an organization where people say, so and so, right? SVP, CEO, or whatever, wants it done this way. Then I always say, well, let’s figure out why, or let’s try to guess why, and let’s try to really understand it. Because typically that senior leader is not involved in the day-to-day of the process.

And so oftentimes, you know, if you can really see sort of where that came from or what they’re after, you can, uh, tweak the requirement a little bit.

James Geyer: I think that’s really, um, comprehensive and well put. And I think like the biggest unlock for me in my career is actually realizing that, uh, the C-Suite are just people as well, and they actually are not in the weeds of everything day to day like you are.

And so I, that’s. Really well put. I think it’s probably obvious based on what you described, but just to be totally clear, like why is this helpful? Like what impact are you seeking with this? Like as the leader of the RevOps team?

Oscar Armas-Luy: Yeah. So the fewer requirements you have, essentially the less work that you have to do to deliver something, right?

And so of course you want the right set of requirements or else you’re not gonna meet the need or solve the problem. But any of these kind of extraneous requirements that don’t really move you towards the outcome. They’re just gonna create a lot more work, a lot more room for error, and then a lot more, um, room for debate when you go to actually introduce the thing.

James Geyer: Yeah, I, my mind immediately goes to like the 80 20 rule too, where it’s like maybe the executive or the outcome doesn’t call for that last 20% of perfection either. And it’s like that’s where you spend 80% of the time. And so I think being able to understand where you don’t need that is actually huge.

Oscar Armas-Luy: I love that

James Geyer: second step, delete any part or a process that doesn’t add value. I love this step. How can you kind of do this from a RevOps perspective? How do you think about this step?

Oscar Armas-Luy: I think this step is probably the hardest one for two reasons. Number one, I think when we think of innovation, our mind immediately goes to addition, meaning add more steps, add more views, do more things when a lot of innovation happens from subtraction, meaning remove things that don’t add value.

The second reason I think it’s hard, not just that it’s counterintuitive, is that. It is very difficult to remove something from a process unless you understand the process really clearly. So I think that it all starts with documenting your process. It doesn’t have to be pretty, it doesn’t have to be rep facing, but really understand step by step for something.

Here is what we do, here’s how we do it, here’s what we use. And then what I try to do is, okay, I have my eight, my 12, my 15 steps written out. Then just follow the thing. I think you’ll find, you know, if it’s a 15 step process for say, producing a deck or producing a forecast, you’ll often find that if you follow the process step by step to the letter of the law, in your mind, you start seeing like, oh, I can skip this, or I can do this different thing, and then suddenly the steps start to melt away.

But you only notice those opportunities if you have the process really structured in the first place.

James Geyer: Yeah, that’s that’s great. I love that. General feedback or advice to like document your processes too. I think just the exercise of doing it is so helpful. Curious if you agree. I’ve also found that just like chatting with reps has been really effective at this too, because so often reps don’t see the value in something RevOps pulled together and because maybe they have, you know, context being in the seat and so you can actually, you know, think again, actually go back to question the requirement.

Like, do we actually need this stuff that’s not helping the reps?

Oscar Armas-Luy: Yeah. I think you’re spot on. Right. And I would just say not even just the reps, but really any of your stakeholders. So I think a lot of times we do things that we would like as RevOps people or that we find valuable, but then you get to your stakeholders and no one’s using it.

So what value are you really adding?

James Geyer: Yeah, totally. Awesome. Super helpful. Step three, simplify and optimize. How do you think about this? I, I kind of, my mind goes to like monitoring processes, QA metrics, is that how you think about this? Or do you have kind of a different framework?

Oscar Armas-Luy: I think in terms of optimize, right, like you always optimize to something and it’s really hard to optimize for a metric if you don’t have it.

So like the way I think about it is everything you do needs to have some type of quality metric associated with it. And the two major buckets of quality metrics that I see are like timeliness and then defect rate. So like whatever concept you have, like is it happening on time with an SLA? And then what do you consider a defect?

Like what rate of defects are you getting? And so once you have that conceptually, um, for, for whatever you’re working on, okay, then you can figure out what tweaks you need to either reduce the defect rate or increase the timeliness.

James Geyer: That’s great. Um, how do you kind of double click into the improvement aspect of, it’s one thing to measure, right?

And like how do you, I’m sure it’s very contextual based on the process you’re monitoring, but curious how you’ve typically tackled that.

Oscar Armas-Luy: Yeah, it’s always about really tying back to the outcome, right? So maybe there’s like an implicit like step zero in the, in the algorithm that’s understand the outcome or understand the problem, but in terms of improvement, right?

If you have the outcome front and center. Then there’s two ways that you improve, right? You either get more of whatever outcome you’re trying to drive, or you get the outcome more efficiently or cheaper, right? And so once you understand the two buckets, then you know which side you wanna optimize, and you can get ideas for what you do.

James Geyer: That’s great. How do you think about like your own RevOps cadence for optimization and improvement? Like, I’m thinking to, you know, some of the, one of the biggest challenges in my opinion in RevOps is like the change management, changing things, rolling it out to reps, uh, getting adoption. Like I’m, I’m kind of assuming that this part of the algorithm requires continuous change management.

Maybe you can tell me I’m wrong there, but how do you handle like this piece without, you know, uh, overburdening reps or, or the RevOps team?

Oscar Armas-Luy: I think this is where, you know the famous quote, I think it’s from Drucker culture Eats strategy for breakfast. Maybe it’s some other management thinker. It really is about the culture that you’re instilling within your revenue organization.

So every revenue organization is going to be in change constantly. Whether it be things that are RevOps driven, market driven, organizational driven, and so you really have to create a culture and a cadence of continuous improvement, continuous development, and then continuous adoption. And so I know it sounds like kind of like a boring answer, but if you can establish that culture where reps know they’re expected to stay on top of things, they’re expected to embrace the new change.

But then also give them the support and the enablement architecture to make that feasible. That’s ultimately how you nail this. If you don’t have this culture in an organization, then you end up just changing a bunch of things and making a mess.

James Geyer: Yeah. Any advice or lessons learned on developing, iterating that culture?

Like I know it’s very top down driven and sometimes if you don’t have the support from top down, like you’re kind of out of luck. But I’m curious if you’ve seen something that like RevOps leaders can do to, to play a part in that.

Oscar Armas-Luy: I think it’s, it’s really about putting the data behind the directive. So for example, you can have a CEO, a CRO, a CFO that says all reps should be certified on X, Y, Z, no later than next date.

But if you’re not tracking who’s actually, you know, made progress on the certification late and all these things, like, it doesn’t really mean much. So I draw a lot of inspiration from like IT organizations. They have to do the, like the InfoSec training every year. And you see they are on top of people, like the managers, the reports and all that stuff.

That’s how I try to be, to add a little bit, um, of data behind the directive from management.

James Geyer: Great. As the co-founder of a RevOps BI platform, any answer that’s based on data is, is something that I love to hear, so that’s great. Step four, accelerate cycle time. Tell me about this. I have to admit, this is the one where I’m like, oh, this feels more like product management or like manufacturing line.

Like how, how does this correlate or, uh, work within RevOps?

Oscar Armas-Luy: Yeah, so I, I think, you know, probably this is to your point, probably the least relevant one, but it’s all about how do you complete the cycle end to end faster. I think here is the insight that’s lost. Usually in a manufacturing line, you accelerate cycle time by doing steps in parallel, right?

If you’re able to do steps in parallel and then eliminate some of the bottlenecks or reduce them, you get faster cycle time. So I always try to think about if we have a revenue cadence or a process, is there anything that we could do in parallel? And then are there any major, major bottlenecks where we have to wait on something that holds everything else up?

And if I can address those, I make pretty good progress.

James Geyer: I love that. I’m thinking of like, you know, we’re recording this with the end of the quarter coming up of like the board deck or like final reporting or something, or even like a financial close for folks that are familiar with it. If there’s one or two metrics that always takes so long to get, it’s like, can we invest in solving that and like speed this up so people can get back to their, like, day to day versus, you know, pointing out this board deck.

So I think it’s actually like a really good example. Again, breaking down like component pieces and, and the bottleneck and the slow aspect of it.

Oscar Armas-Luy: And I love you brought it up, right? Because you know, you could accelerate cycle time in terms of like if you use a BI platform, you can pull a bunch of metrics in parallel.

’cause all you do is what go and go to your dashboard versus having to manually run them. But then the bottleneck, you know what I find? I don’t know about you. Is that come board time? You know, you have a CFO or someone that has 52 different slides to review and so you’re just kind of waiting for them to get to yours.

And so figuring out, hey, is there a delegate that can take a first pass for something to, to reduce that bottleneck?

James Geyer: You just gave me serious PTSD as someone who, uh, started an investment bank and we’re always waiting on the, the partners to review slides and so late into the night. So that’s a, a really good example too.

Okay, last step here. Automate, um. Couple questions here. One, just like, you know, the previous steps. I’d love to hear just your, your general kind of thinking behind this step, but also I’m curious like timing, when do you decide it is the time to optimize and automate when a process is kind of like rubber stamped?

Good to go?

Oscar Armas-Luy: Yeah. I think people often jump to automate way too quickly.

James Geyer: Agreed.

Oscar Armas-Luy: So two things, right? Number one, to your point, the process has to be really, really tight and good before you’ve automated. And I think the only way to know that a process is tight is to get a decent number of iterations under your belt of doing it manually.

So it’s gonna be context dependent, what a decent number is, but probably more than you think you need of manual iterations. And you have to get it working very smoothly on a manual basis. That’s step one. Then step two, you got to think about what is the error rate of the process. So typically processes that are very error prone, you want to automate sooner.

Why? Because it’s kind of a trade off, right? The sooner you automate, the more likely it is that you’re gonna have to change or refactor the automation because of a process change. The trade off is if it’s a highly error prone process, okay, you take on a little bit of that, but you eliminate your error rate or you drive it near to zero.

So I think the more error prone it is, the sooner you can do it.

James Geyer: That’s a really awesome framework. I love it. Um, anything else to add on this process That was super insightful in my opinion, and I’m actually gonna take a lot of this into kind of my own founder kind of ops work here. Did I miss anything question wise or do you feel like it’s pretty well covered?

Oscar Armas-Luy: You know what? I think you made me realize this, really we should add the step zero, which is the problem definition. Right? So I think in RevOps, a lot of times we get asked for solutions, but as you know, right. Really taking the time to understand and dig deep into the problem statement makes it a lot easier to implement all five of these steps.

James Geyer: Totally. What are we solving for is like the question that I, I like to start with and it’s hugely helpful.

Oscar Armas-Luy: Yep.

James Geyer: Cool. All right. We talked a little bit theoretically in terms of how we think about this. Let’s maybe break this down into some specific examples from like your work experience. I know we’ve chatted previously about some of these examples.

I’m happy to bring one up if you want, or if you have one kind of like top of mind. Maybe we can just dig into kind of putting the, the theory or the framework like to the test.

Oscar Armas-Luy: Yeah, so I have one, you know, that I’ve been talking to a lot of folks about recently, which is forecasting. So. I think the way many B2B sales organizations do forecasting is they essentially have a target or a number to hit for their, for their quarter, and they essentially work backwards and say, okay, how am I gonna build up to my number?

What deals am I gonna get? What’s my back fill? What’s each rep gonna contribute? And I think this is a little bit of an odd way to do it. You know what I really espouse is going from first principles. So forget your quota, forget your target. Like what are the first principles that are really going to drive your results, and what are the inputs to get there?

So what I’ve done in my career is really map out for each rep, for each team, what are the inputs within their control? They’re basic things you can think of, right? Things like how many meetings are you taking, how many demos are you getting? How much are you prospecting if you have reps doing their own prospecting, or what are they getting from the different channels?

And once you understand what all those inputs are, we create an architecture for tracking those inputs and attributing them to the rep. Then you could do a little bit of math or data analysis to say, okay, within some level of reliability and using my historical data, how do these inputs actually translate to a result?

And then you roll that up. Right, and I think doing this type of forecasting, number one, I think it’s a lot simpler. I think it’s a lot less subjective. Number two, it’s something that you can almost entirely automate it once you’ve gotten it defined. And number three, it gives you the true forecast from the things you can control of what are you gonna get versus trying to back out from a number, which is where folks often run into trouble.

James Geyer: This is great. I feel like this also just gets you so much more early visibility so you can course correct like in month one of the quarter and not the second to last week of the quarter, right?

Oscar Armas-Luy: Absolutely, absolutely. And this is especially true, right? Like you know, a lot of B2B companies, they’ll have year long 18 month sales cycles.

And this is true for them too, but probably less so. But when you have. More mid-market organizations where you’re opening and closing deals within quarter. It’s really important to think about it this way.

James Geyer: Yeah, definitely love it. Um, you also mentioned a separate example last time we spoke around like an indicator system that you, you kind of have like, tell me more about that and how this kind of like sits in with, with what we talked about today.

Oscar Armas-Luy: So, um, one thing I’ve seen right and I’ve struggled with is we’ll prepare dashboards for reps. And the dashboards really tell you outcomes. So, for example, you’ll have a dashboard that shows each rep’s pipeline coverage or their percentage of late stage pipeline or things like this that are really outcomes, right?

Why do I say their outcomes? Well, because a rep can’t wake up and decide to increase their pipeline, they could decide to go prospect, but they can’t decide to get opportunities. And so what do we do about this? A dashboard like that can be useful, but what I think is more useful is how do we create indicator lights for our reps that actually tell them to go do some action?

So what is it? What is the key for an indicator? I think it’s two things. One, an indicator has to indicate something which is a metric you actually care about. And then two, an indicator has to be a hundred percent within the rep’s control or the person reading it. Uh, reading its control. So for an example, an indicator might be number of meetings that do not have follow up, right, according to whatever follow up your organization prescribes.

And so what you do is you want to create these indicators, and that’s what we’ve done. And then you can encourage a culture amongst your reps of always get your indicators down to zero. So whatever they are, the eight or the 10 of them, your reps know, these should always be zero or close to zero. And then that’s a very simple way to manage it.

And it’s also very easy to see where things are going wrong because you can look and say, oh, a rep has a 20 in this indicator. Like, what’s going?

James Geyer: Great. And it really ties into some of like the change management we talked about earlier. So I assume the answer is gonna be similar, but like how do you get buy-in from reps on that?

Like, I think one example of an indicator I, I start to think about just like activity and I know there’s a lot more that you guys are doing than just like activity tracking, but I also know that a lot of reps, particularly good ones, don’t love to be told they need more activity or that that’s the way they’d hit their number.

And I’m curious if you’ve experienced this or how you kind of got around things like that.

Oscar Armas-Luy: I always start with, I think your first set of indicators should be things that are common mistakes, right? So for example, a common mistake is not following up on a discovery call, for example. I don’t think there’s any rep that would argue with you that you don’t need to follow up on a discovery call.

If not, they just make them. If they argue that they’re just making themselves look a little silly. And so I start with a batch of common mistakes and say, look, we’re serving as a second set of eyes here to to help you. Avoid some of these common errors that we know will impact your results. And so I think that’s a way to get a lot of buy-in.

The reps tend to find it useful to stay on top of things. The managers, of course find it useful so that they’re not surprised or called out if something goes wrong. And then after you’ve established a good footing in that you could start to expand to some of the more, I guess, non-mistake based ones.

More of the like, you should do these things.

James Geyer: That’s great. I love it. And I think always leading with data, to your point earlier, is so helpful too. And if you can show that the best reps are doing it, yada, yada, yada.

Oscar Armas-Luy: Agreed. A long way.

James Geyer: Cool. Oscar, this is really helpful. A lot of good examples, sadly, we’re just about at time.

Anything again that I missed? Any other examples that come to mind or do you feel like we’ve, we’ve covered the topic?

Oscar Armas-Luy: No, I think this was a very, uh, helpful conversation. I took away a thing or two from it as well. I’m, uh, really glad that you had me on.

James Geyer: Perfect. Really glad to have you, Oscar. The pleasure is all mine.

Anyone listening, if you have any questions about this, feel free to send them my way. I can kind of track them down with Oscar on your behalf. Oscar, again, thanks so much. This was fun.

Oscar Armas-Luy: Thank you.