Janis Zech: Hello, and welcome to another episode of the RevOps Lab. We are here with Mollie from Engine, I think. Great to meet you, Mollie.

Mollie Bodensteiner: Yeah. Nice to be here. Thanks for having me today.

Janis Zech: Yeah. Good word. Exactly. It's like a very complicated name, so I just wanna double check. No. I mean, great to have you. Super excited about the conversation. We'll talk about RevOps, org design, and hiring best practices today. But before we dive in, who are you? What do you do?

Mollie Bodensteiner: Yeah. Absolutely. So Mollie Bodensteiner. I am the SVP of operations at Engine but have been in the revenue operations space, I like to say, before it was cool. So mostly my entire career in one way, shape, or form, coming up through more of, like, the marketing automation world and have led RevOps teams in some capacity at the last six companies I've been with. So excited to be here and really excited to talk about org design and hiring practices.

Janis Zech: Yeah. So we could probably spend a lot of time about your background. We'll dive right into the topic. So you hired a bunch of folks this year, you mentioned in our prep talk. And I think you currently run a team of forty people. So I thought we'd start off with what's the current org structure? How do you organize? It's obviously such an important topic, especially if you grow a team of that size. So, yeah, curious how you organize yourself.

Mollie Bodensteiner: Yeah. Absolutely. So our team at Engine is a little over forty, and we've hired twenty five of those people in the last six months, so just in this year. So very much a rapidly growing team. And, you know, one of the things that I think is really important when you're looking at RevOps org design at any phase of company is, you know, what is the purpose of RevOps in your organization? Every company I've been at has been slightly different. So when you think about centralized versus decentralized operating models, that really starts to drive how you're structuring your team. So it's always the, where does marketing ops sit? Does it sit in RevOps? Does it sit in marketing? And so before you're thinking about what is the ultimate org design, I think you've got to think about what your operating model is. So are you running more of — and it's okay to say — I'm going to say a back office RevOps team that is going to be more reactive and like helped us to get focused and lean more on like the systems where the actual operation — I'm going to use air quotes — of operations are happening, centralized within the function. Or are you going to run a team that is more business partner focused? Right. And so like at Engine, we run a pod based business partner structure where we have all of operations sitting within revenue operations. We have enablement also within revenue operations. I think a lot of times you see organizations putting enablement outside of that. What we found is enablement's always the last to know and really the first ones who should know because they're the ones who really have to get this change management through the organization. And so by bringing them into RevOps, we created better collaboration. Right? Better coordination, better alignment. And then we also have our process and systems team, which also tend to be some of the last to know and the ones who actually have to do the build. So within that, our org structure, we run a pod, right? So we have new business, existing business, different lines of business, all have kind of their point business partner, which is the sales operations kind of leader, manager, whatever level goes into that. But they have a dedicated enablement as well as systems person. So they're all sitting in the same rooms. They're all talking and they're all on aligned roadmaps as well. So I think when you're thinking about the hiring and the org design, where is the maturity of your RevOps org and the purpose of that? Because what I just mentioned might not work if you're a fifteen person company versus a thousand person company. So coming up to, like, where are you and where are you going will help you make those right hires and set that right org structure up.

Janis Zech: Yeah. I think maybe helpful for our listeners just to give a bit more context about exactly this part. So how big is — what is the ratio? Sort of like how would you describe the current day status of the business? I think that would be helpful, you know, just to have that context.

Mollie Bodensteiner: Yeah. Absolutely. That's a great call out. So Engine is — we are a B2B travel management company. We are — so a couple of things that I think are important to note. We are contractless. So this is — and I'm gonna laugh because like first time in my career, don't have to do a deal desk. Right? As part of sales ops, which like highly recommend not having a CPQ or a deal desk. Like, woah. Life changing. But with that, right, like, you get the nuances of like forecasting is very different when you don't have contracts and you're consumption based. But that's a whole other conversation we can have. We have had roughly seventy percent year over year growth for the last, I think, four years. So have been rapidly growing as an organization and are continuing to grow actually like our sales headcount really aggressively this year. I think it's a 3X growth. So with that, our ratio is a lot higher in terms of like RevOps to sales or go to market function because we are scaling in advance of continuing to hire, I think one hundred and fifty more sales reps this year. So what I've learned the hard way, right, is like getting ops after those hires or enablement after those hires, not great. Right? So we're doing that in the front end, which is where we front loaded a lot of those hires this year. We're about a thousand employees, though.

Janis Zech: Yeah. I mean, obviously, this is always in context of size and maturity of the business and type of the business. Right? Like, you just alluded to a bunch of those things. I mean, wanna dive a bit deeper into the pod structure itself. Obviously, a pod structure, it's a cross functional team that supports specific purposes. I love that personally. I think it's great. How are the reporting lines? Is enablement reporting a dotted line into the enablement leader or are they having a dotted line into the pod structure leader? How do you organize that?

Mollie Bodensteiner: Yep. So enablement reports into enablement. But then it's that kind of dotted line, more matrix organization in terms of like, I wouldn't say, hey, enablement, you report to, you know, the pod leader, but you're collaborating with them. You're aligned with them. Right? Like, it's more of a team structure than, like, the hard reporting line.

Janis Zech: And then you're the SVP who they report to? Like, what are your direct reports?

Mollie Bodensteiner: Yep. So I have a VP of revenue operations and enablement. And then I also oversee all of our customer operations. So our member services, our operational excellence teams, as well as, like, workforce management for, like, our post sales support. And then I have information technology, business operations, and procurement and digital transformation. So I have leaders of all of those functions.

Janis Zech: So got a pretty good initial scope. So these are like single folks. Right? Like the last four you mentioned? Or is that — yeah — teams?

Mollie Bodensteiner: Yeah. Yeah. Teams.

Janis Zech: Okay. And then, basically, out of those teams, you form the pods, and how are they formed? And, like, how do you decide who they support?

Mollie Bodensteiner: Yep. So our pod structure really focuses more on the go to market. So as the head of operations, I have revenue operations, so go to market function. And then I have more of like the back office administrative operations like IT, procurement, etcetera. And so on the go to market side, you have our VP of new business. And so VP of new business has a dedicated business partner, which is the sales operations manager focused on new business. That sales operations manager focused on new business now has this pod. So they have somebody who is on enablement. So enablement program manager. We also have an onboarding program as well. So they have the onboarding manager too, because so much of that cross function with hiring a hundred more AEs plus onboarding matters. Then we have the dedicated go to market systems person. And one thing to note there is that our systems teams are fluid. So it's not as like a Salesforce admin, you only work on new business or you only work on existing business, but it's that point person that can be kind of that conduit back to the systems team. They're reading the BRDs. They're working on requirements. They're then translating that to the developers if we need something that is more code or integration based. And then you have your analysts as well. So when you form that pod together, let's say we're redoing our commissions — that's probably a bad example — but we're redoing our commissions process. We're redoing quotas. How do you get those right people in the room to build that project plan, to understand the roles and responsibilities and are all on the same page as you work through that. And obviously in that example, you'd have finance and HR and some other people in there, but you've got kinda like your key RACI altogether. And so then our pods are meeting once. And the other piece of this is think about like meeting structure. And so without a pod structure, it's like, okay, that VP of revenue or his directors or her directors are like now going and being like, okay, gotta go meet with enablement. I gotta go meet over here. I gotta go meet over here. I gotta meet over here. Like we've now centralized that — like, you're not sitting in twelve meetings a week with the same audience. Right? Like, you're sitting in one meeting a week. You're going through what needs to get done and, like, you're being really purposeful with your time.

Janis Zech: And was this like a learning that you just, you know, basically had to kinda, like, experience when you were scaling that team? Because forty people — I mean, that's quite a lot of people. Right? That's like for some people, that's basically the entire company. And that's already, like, where your headaches can start with, like, transferring information, like, sharing information, creating, like, a culture of transparency. So I'm just curious, like, you know, how did that structure evolve over time and what were some of the lessons learned?

Mollie Bodensteiner: Absolutely. So structure evolved — like, we really, I'd say, started this in January, probably perfected it in March as the team continued to grow. So, like, it did take some, like, iterations of, like, do we have the right people? Are we thinking about the right cadence? The other thing that we stood up were — and this is gonna sound so, like, simple, but, like, a Slack channel. Right? So like each pod has this like working Slack channel and like for us — like, we continue to grow at a rapid pace — like getting things out of threads, like just transparent communication was so key. Because a lot of times what would happen is somebody would go — you know, sales ops would go to like enablement and they'd be having the sidebar conversation without even realizing like, hey, I'm now not looping systems in. And it wasn't intentional by any means. It was just like, you're just like working through things. You're moving quick. So like moving everything out of like just one to one or like non channel based communications has also helped to accelerate that. We also realigned all of our Asana boards the right way. So instead of working off of like — because our systems team works in sprints, which is great. Highly recommend work in sprints. But like knowing what was coming and like managing their cadence — like instead of being on marketing ops has their board, sales ops has their board, enablement has their board, which they still do — we've now created like a centralized board that they join based on like the business pod unit too, which also gives visibility back to the VP. Right. So like the ultimate, like kind of decision maker of what is going on. You know, salespeople — every day I wake up and they have something else they want done and like, hey, this is urgent. Let's go launch this. Let's go do this. Right? Like being able to come back and say like at the beginning of the week, hey, here's your priorities. Right? Here's what you said were priorities. This is what we aligned to as priorities. Are we changing these? If you're changing these, here's the downstream impact of that change. So like, are you okay with forcing that trade off? Right? Like, I remember at one point I had — before we moved into the Asana — like I had this like Google sheet that had like a hundred and fifty projects on it. And I was like, you know, for me it was like, okay, like here's everything you've randomly Slacked me that you've said is a priority. Let's go through this together. Right? And like, I think when you get to the point that like, you're like, we're really good at doing five. When we go to six, we start to suck. Right? Because like we just — and it's like we're even better if we only have three. And so when you think about like — and we're elite when we only have one. Right? So like really thinking about — and I like to talk about chopping trees, right? Like I can take an axe. I can take a swing at every tree in the forest. I'm never gonna get one down. Right? But if there's one that I'm really focused on and like I chop that one down and then I go to the next, like I'm getting better outcomes and getting it actually a lot faster.

Janis Zech: Yeah. Absolutely. Like so I think what were some of the traits that you were looking for when you were building that team? Because I think it requires, like, some specific — I guess, specifically soft skills — to be able to operate in that structure. So was there something specific that you looked out for when you, you know, were hunting those people or, you know, when they applied?

Mollie Bodensteiner: Yeah. Absolutely. And I think specifically, like, on our operating partners, which are either, you know, our marketing operations or sales operations managers, like there's huge soft skills that go into that, right? Like as much as like you have business context and you have technical proficiency and you have that, like you also have to be just a really good — I'm gonna call it influencer, right? Like being able to influence without authority, being able to properly articulate trade offs. And like, I love cat herding, right? You're doing this different level of like cat herding, which is probably also known as like coordination and project management. But I think just, it's a lot of those like soft influence skills that you need to be able to like really rally people together, but also force those like hard trade offs. Like I just talked about, right? Like being able to have those conversations and manage up through those because like your ultimate stakeholder, right? It's not your peer, right? It's actually senior leadership that you're working with. And so having that confidence to be able to push back and articulate and like force those trade offs, especially in as big of an org as we are — like, you've gotta be able to command that environment the right way too. Right? Because it's not just the VP, right? There's directors, there's managers, there's individual contributors and there's salespeople are needy. Right. And sometimes just a pain in the butt. We all know this. Right. One things their way. So like being able to be tough, but also fair. So I think I look at like a lot of — one of my favorite interview questions is like, what's an exception versus a rule? And so, my initial thought on that is always when it comes to compensation because like every comp cycle, somebody is like, well, you know, this person should get that versus this. Like, you know, we talk people, process, data, technology, but like the thing that's missing in there is policy a lot. And a lot of what we do in revenue operations and operations in general is adherence to policy, which isn't always fun. So it's understanding — are rules meant to be broken? And if you're breaking the rules, were they actually rules or should they have been rules to begin with? And so looking at how people handle like those types of situations and identify like, when is it a rule versus like, when should it have never been a rule to start with?

Janis Zech: For sure. I think there are lots of those. So one thing that I — first of all, fully agree, and I really like how you talk about it. You know, one thing that I always find helpful is to think about it a way that — so, like, for example, like a Salesforce admin. Right? Like, what's kind of, like, the mindset, like, a Salesforce admin should kind of, like, bring to the job, similarly for, like, an operations person. So Salesforce admin. Right? Like, you know, don't think about your job as someone who, you know, like, has read, like, the Salesforce manual and then knows every rule in that. That's, I don't think, like, necessarily the job. I think it's more like think about Salesforce as a product that you are continuously developing for the organization that you're working for. So it's more like an engineering mindset that you have. Similarly, I think, like, you know, when you work in operations, it's not, you know, checking off items from a, like, a to do list or a task list. It's like, influencing people, operating more like a, maybe like a product manager, like a product leader, who's understanding priorities, impact of priorities, is able to soft influence people. And so, yeah, I think this is, like, just generally, right, like, a healthy mindset to have. Like, Salesforce admin doesn't mean that you have to behave like the IT admin of the nineteen nineties. Right? I think those times are over. So, like, you know, get into that more modern mindset because I think that's what you are doing. Right? I think this structure that you're talking about is a very modern structure. You know, it's very forward thinking. So you need to have people who also think that way. And I'm sure you found them.

Mollie Bodensteiner: So definitely — I love what you said there though, because we talk a lot about running revenue operations like a product and engineering org. And I think you just nailed that. Because at the end of the day, that is what we're doing. We really are managing — as much as product and engineering is handling the external product — you are doing the internal product. So you have your product operations, you have your engineers, you have your product managers. And I think the other thing that I found is when I am working with my product and engineering stakeholders, being able to drive like that type of correlation of like, hey, Bob over here is like, he's my engineer. He's like your engineer. Right? Like he works this way. He gets a BRD. He gets requirements. He's doing QA. Like he's running those similar cycles. The other thing that I think it helps with is like the planning and setting expectations. Right? So like when you go to product and you're like, hey, go build this cool feature. Right? They go, okay, here's our process. Here's how it gets in our timeline. Here's how it goes from like a sprint perspective. So when you do the same thing with like sales ops and it's like, hey, go build this cool feature in Salesforce. It's like, okay, great. Like, here's the process. Here's how it works. Right? It might be a little faster. Maybe, maybe not. But like, it's still setting that like similar expectation with stakeholders that it's like we work kinda the same way.

Janis Zech: I mean, I also love the cross functionality of the team because I think what you're alluding to is the conversations in the channel, in the board. You basically start sharing the information with the right stakeholders. If the stakeholders don't even know what you're working on, how should they know what the priority is? It's essentially really good for stakeholder management. Obviously, one challenge for the pod structures, especially on the systems architecture side, right? Because if every pod just pushes stuff in, how do you architect the system? How do you deal with that?

Mollie Bodensteiner: Yeah. And that's where a lot of like the sprint planning does come into place. And again, it's, you know, these people have to become kind of the representative and the conduit back. Right. So like, if I'm going in and we're saying, hey, we're gonna do this — like it needs to then go back into the systems team and they're like planning reviews, right? Like how does this impact? What does this look like? Same thing on the enablement side, right? Like, oh man, we now have twelve trainings this month, right? Like how do we need to prioritize? How do we take that back? And like, they become kind of not the messenger, but a little bit of like that messenger dialogue between the teams. And again, that's where that sprint planning, road mapping becomes super critical too, especially when you think about resource allocation. Because if I've got ten huge projects that all require, let's call it like custom API builds and a bunch of like custom development, like, and I have four developers — we now have cross functional trade offs that we have to force because I now don't have the right downstream resources. So then it's still working holistically across the organization, which gets really fun because we have multiple product lines in these pods. So like our core travel business versus like our partnerships versus like our groups and supply all have different priorities, but we're, again, a centralized team. So like we still have shared resources. So it's really managing that too at the top level, which is where it gets really fun for myself and the VP of RevOps to really work through.

Janis Zech: Yeah. Yeah. I can imagine. I mean, I think the company that has probably done that the best on the engineering part is actually Facebook. Right? Facebook basically rolled out this central platform with APIs. And so pretty much you had small engineering teams being able to build huge tests on the core platform, shipping and testing with millions of users still at the very late stage without actually breaking the core experience. And I think this is just a more mature version of this, where you have a centralized infrastructure and then specific areas that people opt into. And this is obviously engineering, but I think it's very much similar — so, like, hub and spoke, right? Where it's like you can pull off those shared services the right way. I mean, it's really hard to achieve. I think we all know this. It is really hard to achieve, but it's something I think I find very inspiring because I'm a big fan, I believe, of small cross functional teams because I think when a company grows — because you just move faster. You move so much faster. You're not basically going through meeting to meeting to meeting to meeting. It's draining everybody down. All the high potential people are just frustrated because they don't get stuff done. It's really frustrating. So if you have these pods, you basically come up with an idea and you say, well, it's not on the roadmap, but we can just execute it because it's an XS story and we just go for it. And then there's obviously the belonging of a team where you have all the capabilities to execute on those things. So, totally love this model. I want to switch gears a bit. You hired a lot of people. The world of RevOps and the roles are changing. I think go to market engineering is all over LinkedIn. People still don't know what it is. We're also vibing now. I still don't know what vibing means. That was the word of the day this week, I think.

Mollie Bodensteiner: Yeah, exactly.

Janis Zech: But no, with all seriousness, how do you find amazing talent? How do you attract talent? What are you looking for? Right? Like what are some of these learnings on the hiring side?

Mollie Bodensteiner: Yeah, absolutely. So from a hiring perspective, right, I love not getting direct candidates. Anything I can get word of mouth reference wise through network is always something I look at first if I can. Right? And it could be any level of org. It could be, you know, my specialized junior Salesforce admin. Like I would ten times take a referral than somebody cold. And it's not to say like, again, like the people — we have hired great people from cold applicants. There's just — you just move a lot faster when you already have that like reference and trust and like credibility of somebody who's worked with somebody. Like we're all on LinkedIn. We all know this. Like we all have benches. Right? We have people that we've worked with who knows somebody who knows somebody in the seven degrees of Kevin Bacon. So to me, I love referral references. I also love, hey, I know this great person. I don't know if you have a role open, but you should talk to them. I'm a big believer of like, get the right people on your bus and then find them a seat. And like, to me, I think there's so much always changing in RevOps and like your best people are not going to always be your specialized people. They're going to be the ones who want to learn and want to grow and be cross functional. And like looking at my career, like I've done sales ops, I've done marketing ops, I've been a data engineer, I've done Salesforce architecture. The one that I haven't touched is enablement because that's still a scary place for me. But I've managed it. So I think finding the people who want to cross train and be cross functional — those become your next level leaders too. And so always kind of looking for that attitude, that mindset of like, who's the person who like wants to get on the bus. They're hungry. They're eager to learn. They're coachable. I'd take that all day long over the person who sat in like a sales ops role for the last ten years and wants to come in and like run their playbook again. Right. I think to me it's like skills over experience and like experience still matters. Don't get me wrong, but like just really like somebody who's got that, like how hard can it be mindset and like just wants to dig in, especially with how much is changing. Right. Like, we've brought in, I'm going to say like five, but it's probably closer to like ten new tools this year. Right? Like just additional solutions that are helping us move faster on automation and integration. And so bringing people in who are like, let's go versus like, oh, man. I gotta learn a new tool or a new system or, like, how does this come together? Like, attitude is everything. Right?

Janis Zech: So how is the recruiting process? Right? So, I mean, what do you do to interview folks for skillset? I mean, how's the process? How do you run it?

Mollie Bodensteiner: Yeah. Yeah. So, I mean, I'd say we run, like, the process — I mean, this is one process that I hate running, but, like, I get in trouble with HR because, like, I'm one of those builders, let's go. And if we know we wanna hire the person, like, let's get them in the door. But HR tends to like to follow process. So we do the traditional, you know, you're gonna have the screenings. You're gonna talk to the hiring manager, other team members. We always do a case study regardless of role. Like key thing that I will push to hiring managers is if you don't do your own case study, you are missing a mark. So like every — we know this — everyone goes out and like ChatGPT is their case study, right? Like go write me a case study for Salesforce admin. Great. If you're going to go do that — if you don't sit and do it yourself though, you don't know what you're like interviewing for. You don't go through that same thought process and you don't have good questions. Right? So like, even if I'm not — I'm going to say like, not the person who would like do the work and like go through the whole thing — but I need to at least go through the exercise so that when I'm interviewing, I can be like, how'd you think about this step? Where did you get stuck? Because like, here's the other thing. The candidate's going to do the exact same thing with your case study. They're going to take your case study. They're going to put it in ChatGPT. They're going to put it in Claude and be like, help me put this together. But what you're really looking for is can they actually figure out where it's wrong and how to adjust it and where are those different decision points and what are the questions? It's less about the — I actually want them to go use AI to do this. I want them to be more efficient. I want them to move through kind of the minutiae in the right way, but then really put their time, energy, and effort on the critical thinking skills and the outcomes that they're driving. And like, that's what you're really looking for. Like if I'm like, go put together this like pretty Figma and they're spending ten hours in like a Figma drawing something versus accelerating that — that to me is telling me they're not efficient with their time. So I want them to be efficient with their time and then I want them to be effective with their outcomes. And so going through that process on the cases themselves yourself, you understand where those points are and can ask those right questions, right? Like if somebody is doing manual data analysis and what year is it? Twenty twenty five — and spending all the time doing that, like probably not the person I wanna hire.

Janis Zech: Yep. Yep. And also, to be fair, like, you ask ChatGPT questions about Salesforce, in my personal experience, chances are it's not gonna get it right multiple times. So —

Mollie Bodensteiner: Correct.

Janis Zech: Very, very frustrating, actually. Same for Claude. Not that good at Salesforce yet. That's definitely something that needs to catch up on. We're a big Salesforce shop, but sometimes Salesforce's AI is not good at Salesforce. But I'm sure Mark's working on that. I have one more follow-up question on that part. I'm just curious about, like, the separation on how you continuously develop Salesforce. So, like, the separation between admins, developers, and sort of, like, the people who, you know, write, like, the acceptance criteria, do the testing, and so on. I'm just, you know, curious about that part specifically because you, you know, touched on it in the case studies. And now, you know, just when I dig a bit deeper into that area — because I you know, running it as a product — but I'm just curious, like, how you set that up.

Mollie Bodensteiner: Yeah. So we have three branches in our process and systems team. Like, the first branch is what I'd call like more like your admins. Right. And like it's go to market system administrators. Like they should be able to do Salesforce, Outreach, like just different tools in the tech stack and are doing most — are technical enough to go to like a flow level detail in Salesforce. Like, I think that's — you've gotta be at this point. And so that's like our administrative branch. Then we have what I'd call like our engineering branch, which are more of like our developers or engineers. Like they're doing like true like product level integrations, API, like highly technical. And then they're led by an architect too. So like, that's where like more of like that architectural design and like QA is coming through. And then we have what I call like our BA type component, which is more of like, okay, like we're reviewing the PRDs. We're looking at our test cases. Like they're — I'm going to say — a lot less technical because they're still pretty technical, but they're not the hands on keyboard builder. They're more like, okay, let me look at like the PRD. How does this fit with our existing process? Like how do we want to write like the QA components of this for testing? And then also helping translate some of this back into enablement and into the business, where it makes sense. They also oversee reporting adjustments. So if you're coming in and we're saying, hey, we're changing our sales methodology and we're going to go from MEDDIC to SNAP — they're the ones who really know where does this break? What's in our system today? And where do I know I need to make these dashboard reports, these changes? They're kinda like that downstream — I'm gonna call it audit group — and help to facilitate that.

Janis Zech: Yeah. Great. I love that. I think it's so good, you know, that you are going for, like, an internal knowledge — you know, like, a team that has internal knowledge is able to continuously develop it because, like, you know, at Weflow, like, when we do integrations — like I mean, not a problem. Right? If a customer works with, like, a Salesforce agency, right, like, no criticism whatsoever. Sometimes it's very hard to build that up internally, but I think the benefits that you get from it, they are huge. Right? So they are so big. Like, they actually enable you to do, like, things that your competitors can't quickly do. They enable you to move fast. Right? If you outsource, like, some of the IT management — I mean, it's almost like you build a product, but you outsource your engineers, right? Like, I mean —